1. The Capstone Brief
Before store submission, confirm the capstone app itself genuinely touches at least five of the following, spanning multiple phases of this course:
- Real navigation with go_router, including at least one auth-gated redirect (Week 5).
- App-wide state management with Riverpod (Week 8).
- A real backend integration with loading/error states (Week 9), ideally with offline-first caching (Week 10).
- At least one device API — camera, location, or a platform channel (Weeks 11–13).
- Real animation and polish (Weeks 14–15).
- Unit, widget, and at least one integration test (Weeks 16–17).
If the app built across the last several weeks doesn't yet hit five, this is the week to close that gap before moving to submission — a smaller app that genuinely exercises five different phases end to end is a stronger capstone than an ambitious one that only shallowly touches each.
2. App Store Connect
An App Store Connect listing needs, at minimum: an app name, a bundle identifier matching your signed build, a support URL and privacy policy URL, a content rating questionnaire, and at least one screenshot set per required device size.
flutter build ipa --flavor production -t lib/main_production.dart
# then upload build/ios/ipa/*.ipa via Transporter, Xcode, or fastlane deliver
From upload, the build appears under TestFlight first — shareable with internal testers before ever being submitted for full App Store review. Providing reviewer notes with a working demo login (if the app requires sign-in) heads off a large share of first-round rejections.
3. Google Play Console
Google Play requires passing through at least one testing track (internal, closed, or open) before production is unlocked at all, plus a completed Data Safety form describing exactly what data the app collects — the Week 9 network calls, any Week 12 location reads, and any auth token storage all count.
flutter build appbundle --flavor production -t lib/main_production.dart
# upload build/app/outputs/bundle/productionRelease/*.aab to Play Console
A store listing needs a short and full description, a feature graphic, at least two screenshots, and a privacy policy URL — inaccuracies in the Data Safety form are a common source of rejection independent of the app's actual functionality.
4. Ship It
Common first-submission rejection reasons on both stores, worth checking against before submitting: broken core functionality a reviewer hits directly, a sign-in wall with no demo credentials provided, placeholder/Lorem Ipsum content still visible anywhere, and screenshots or descriptions depicting functionality the submitted build doesn't actually have.
That's the full 20-week Flutter curriculum. From flutter create in
Week 1 to a signed build submitted to both app stores here in Week 20 —
congratulations on shipping a real, published app.
5. Hands-on Exercise
Submit the capstone to both stores
Get a real, signed build from Week 19 through each store's submission flow.
Requirements:
- Confirm the capstone app genuinely exercises at least five phases of this course per the brief above, closing any gaps first.
- A complete App Store Connect record: app name, bundle ID, support and privacy policy URLs, content rating, and at least one screenshot set.
- A completed Data Safety form and Play Console listing (short/full description, feature graphic, screenshots).
- Submit the production build to TestFlight (iOS) and an internal testing track (Android), with reviewer notes including a working demo login if the app requires sign-in.
- A short README documenting what the app does, which course phases it exercises and how, and how to run it locally with the correct build flavor.
You do not need a paid Apple Developer or Google Play Console account to complete most of this exercise — prepare all the metadata, screenshots, and Data Safety form you can, and treat the actual store upload as something to run once you (or your organization) has the relevant developer account; the configuration and preparation work is identical either way, and is the part that actually demonstrates the skill.
6. Knowledge Check
Four quick questions. Expand each to check your answer.
Q1
Why does the capstone brief require touching at least five phases of the course rather than going deep on just one or two?
Why does the capstone brief require touching at least five phases of the course rather than going deep on just one or two?
The capstone's purpose is demonstrating the pieces genuinely compose — navigation, state, a device API, a backend, testing, all working together in one real app — which is a different, more realistic skill than mastering any single piece in isolation. A narrow, single-phase project wouldn't exercise that integration at all, the same reasoning behind this exact requirement in this site's Go and React Native capstones.
Q2
Why does providing reviewer notes with a demo login reduce first-round rejections specifically for an app with a sign-in wall?
Why does providing reviewer notes with a demo login reduce first-round rejections specifically for an app with a sign-in wall?
A reviewer with no way past a login screen cannot verify the app's actual functionality, which is grounds for rejection on its own — working demo credentials (and a short note on what to test) let the reviewer evaluate the real app instead of stopping at the login screen.
Q3
Why does Google Play require passing through a testing track before production is unlocked, rather than allowing a direct-to-production submission?
Why does Google Play require passing through a testing track before production is unlocked, rather than allowing a direct-to-production submission?
Testing tracks act as a lower-stakes staging area — a place to catch obvious problems (crashes, broken core flows) with a small, controlled group before the app reaches either a reviewer or the general public. It's also simply required infrastructure on Google Play specifically: production is unlocked only after passing through at least one testing track first.
Q4
Why does a screenshot or description depicting functionality the submitted build doesn't actually have count as a rejection reason, separate from the app simply working correctly?
Why does a screenshot or description depicting functionality the submitted build doesn't actually have count as a rejection reason, separate from the app simply working correctly?
Store review evaluates whether the listing accurately represents what a user will actually get — a mismatch between marketing material and the real build's functionality is a trust and accuracy problem independent of whether the app itself is bug-free, which is why both stores treat metadata/screenshot mismatches as their own distinct rejection category rather than folding it into general functionality review.