Claude Code + Flutter: From Generated Code to Store Release

Flutter is a natural partner for a coding agent: one language, one widget tree, and a strong static analyzer that turns vague "looks fine" into concrete warnings. The risk is that a generated Flutter app feels finished long before it is releasable. This article focuses on the gap between those two states and how to close it with Claude Code doing most of the work.

Set quality gates before features

Agents respond to whatever signal you give them. In Flutter, the cheapest and strongest signals are the analyzer and tests. Before building features, establish:

• A strict lint set. Start from flutter_lints or a stricter community set in analysis_options.yaml, and require flutter analyze to report zero issues.
• Formatting. dart format on every change so diffs stay readable.
• Tests as done criteria. flutter test for unit and widget tests; integration tests for sign-up, purchase and other critical flows.
• One state management approach. Riverpod, Bloc or Provider – pick one and name it in CLAUDE.md. Mixed approaches are a typical sign of prompt-by-prompt development.

Write these as rules: "A task is only complete when flutter analyze reports no issues and flutter test passes."

Weak spots in generated Flutter code

How to prompt for Flutter features

The difference between a usable and an unusable generated feature is often the prompt. A structure that works well with Claude Code:

1. Context: "We use Riverpod, go_router and Dio; follow the pattern in lib/features/orders."
2. Outcome: what the user can do when the feature is finished, including empty, loading and error states.
3. Boundaries: which folders may change, and that no new packages may be added without asking.
4. Proof: which widget tests must exist and that flutter analyze must be clean.
5. Plan first: ask for a short plan, approve it, then let the agent implement.

Referring to an existing feature as the pattern is especially effective: the agent copies your conventions instead of inventing new ones, and the codebase stays consistent as it grows.

Flavors and environments

Most apps need at least a development and a production configuration with different API endpoints, app names and possibly bundle identifiers. Flutter supports this with flavors (Android product flavors and iOS schemes) and with --dart-define or --dart-define-from-file for configuration values. Ask Claude Code to set up flavors early – retrofitting them into a mature project touches many native files. Never put real secrets into dart-defines that ship in the binary; anything in the app can be extracted.

The release build commands

1. Bump the version in pubspec.yaml (1.2.0+15: name plus build number). Both stores require a higher build number for every upload.
2. Android: flutter build appbundle --release --flavor production creates the AAB for Google Play. Signing reads from a key.properties file or environment variables that are not in Git.
3. iOS: flutter build ipa --release --flavor production on a Mac with Xcode produces an archive and IPA. Signing uses your Apple team and profiles, ideally managed via Fastlane or Xcode automatic signing.
4. Optional hardening: --obfuscate --split-debug-info=build/symbols, and keep the symbol files so crash reports stay readable.
5. Upload: Transporter or Fastlane for TestFlight; the Play Console or Fastlane supply for Google Play tracks.

Claude Code can wire all of this into scripts and a CI workflow; see mobile CI/CD for Claude Code projects for the Fastlane side.

Pre-release audit checklist

Ask the agent to produce a report against this list, then verify it yourself on physical devices:

• Every permission has a clear purpose string on iOS and is declared intentionally on Android.
• The iOS privacy manifest covers required-reason APIs used by your code and plugins.
• Account deletion exists in the app if users can register.
• The app looks right on the smallest supported phone, with large text settings, and in dark mode.
• Release builds work offline or fail gracefully, and no debug banners, test endpoints or logging of personal data remain.
• Android targetSdk meets the current Google Play requirement.
• Data safety and App Privacy answers match what your plugins actually collect.

Rejection patterns and their fixes are listed in the most common App Store rejection reasons. On Google Play, new personal accounts also need a closed test with 12 testers for 14 days, explained in the 12-tester rule. For the JavaScript alternative, see Claude Code + Expo.

Getting it over the line

The coding part is where Claude Code shines; signing, store forms and reviewer communication are where first-time publishers lose weeks. appsubmitter.io combines AI assistance with experienced people to set up your CI/CD, submit signed iOS and Android builds in your own accounts and work through rejections with you. If you prefer to book a free intro call first, bring your current build and the list above.