Ship a Mobile App to a Real App Store

Proof required

Submit a GitHub repository plus a screen recording (minimum 60 seconds) of the app running on a real physical device (not the simulator). The recording must show all 3+ screens, navigation between them, and at least one device capability in use.

What gets checked

• Screen recording shows a real device (visible device chrome, real pixel density) — a simulator recording does not satisfy this milestone
• Navigation between 3+ screens is visible in the recording — the app is not a single-page form
• At least one device capability is used and visible in the recording — not just implemented in code

Common mistakes

• Building an app that works only in the simulator but not on a real device — real devices have different performance characteristics, permissions, and OS behaviours
• An app with 3 screens that are all variations of the same thing (3 list screens with no action) — the screens should represent meaningfully different user actions
• Using a device capability that never actually runs (camera permission requested but never used in the recording)

Resources

What a verifier looks for

• Watch the screen recording in full — a simulator recording has different visual characteristics (no device chrome, perfectly smooth animations, no real push notifications); a real device recording is unmistakable
• Ask the submitter what happened when they first ran the app on a real device that was different from the simulator — genuine device deployment always reveals at least one difference
• Confirm the device capability is genuinely working — ask the submitter to demonstrate it live if the session is video
• Ask the submitter to describe the hardest platform-specific bug they encountered — real device development always reveals at least one

You'll sign in first, then come straight back here.

Proof required

Submit a screenshot of the app listing in App Store Connect or Google Play Console showing the submission status (submitted for review, in review, or published), plus a PDF or Notion document covering: store listing (screenshots + description), the release build configuration, and any rejection reason + fix if applicable.

What gets checked

• Screenshot shows the actual submission status in the developer console — a locally-built .ipa or .apk file alone does not prove submission
• Store assets are complete and professional: screenshots show the actual app (not placeholder images), description is written for a real user (not 'this is my app for the milestone')
• Privacy policy is present and hosted at a real URL — App Store and Play Store both require a real privacy policy URL; a note saying 'I will add one later' is a rejection reason

Common mistakes

• Submitting a test app with placeholder content — the submission must be a real app with real screenshots and a real description that a stranger could understand
• Missing the privacy policy step — this is the most common first-submission rejection; the policy must be hosted at a real URL before submission
• Code signing issues on iOS that prevent building a release binary — this is the hardest platform-specific challenge and often requires careful provisioning profile management

Resources

What a verifier looks for

• Ask the submitter to show the developer console in real time — the submission status screenshot can be verified by checking the app's status in the live console
• Ask the submitter what the most unexpected part of the submission process was — genuine app store submissions always surface a specific platform requirement that was not anticipated
• If the app was rejected, confirm the submitter documented the specific rejection reason and the change they made — rejection is educational, not disqualifying
• Check the store listing: are the screenshots real screenshots of the app (not mockups), and is the description written for a real user who does not know the submitter?

You'll sign in first, then come straight back here.

Proof required

Submit the GitHub repository, the store listing URL (or App Store Connect screenshot), and the reviewer's written assessment: the architecture question and your response, the platform question and your response, the live demo observation notes, and their sign-off confirming their role and a live session.

What gets checked

• Architecture response includes specific patterns (state management library choice, navigation architecture) not just general principles
• Platform question response demonstrates awareness of the specific platform constraint (iOS background app refresh limits, Android Doze mode) not general mobile knowledge
• Reviewer sign-off confirms 4+ shipped mobile apps or 4+ years of mobile development in industry

Common mistakes

• A reviewer who has built web apps but has limited specific experience with native mobile or React Native / Flutter specifics
• Architecture response that describes what you would theoretically do without referencing specific tradeoffs in your current implementation
• Live demo that avoids the real edge cases — submitter always demoes the happy path; reviewer should probe for error states and permission denials

Resources

What a verifier looks for

• Read the GitHub repository before the session — the architecture question should be about a specific decision you saw in the code, not a generic 'how would you scale this?'
• Ask the platform question for the specific platform the app was submitted to — iOS and Android have meaningfully different constraints that require platform-specific answers
• During the live demo, ask to see an error state or an empty state — these are the screens most often missing or broken in first mobile apps
• Reviewer minimum qualification: 4+ shipped apps in the App Store or Play Store, OR 4+ years of mobile development at a company with production mobile products

You'll sign in first, then come straight back here.