Milestone map
Milestone map
3 milestones
Ship a Mobile App to a Real Device
6–10 weeks (depending on prior experience)
Build and install a working mobile application on a real physical device — not just the simulator. The app must solve a real problem and must have at least 3 screens with navigation between them. Stack options: React Native + Expo (easiest deployment path), Flutter, Swift + SwiftUI (iOS), or Kotlin + Jetpack Compose (Android). The app must use device capabilities beyond the screen: camera, GPS, push notifications, biometric authentication, or local storage for offline data — pick at least one.
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
Foundationstart here
Depthgo deeper
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.
Submit an App to a Real App Store
3–5 weeks (5–10 hrs for submission process alone)
Take your M1 app (or a new app) through the complete app store submission process: Apple App Store, Google Play Store, or both. This includes: setting up a developer account, preparing store assets (screenshots, description, icon, privacy policy), configuring code signing and provisioning, building a release binary, and submitting for review. The app does not need to be accepted on the first attempt — the proof requires the submission, not approval. If rejected, document the rejection reason and what you changed to address it.
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
Foundationstart here
Depthgo deeper
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.
Present Your App to a Senior Mobile Developer
1–2 weeks (60–90 min session)
Walk a qualified reviewer through your M1 app and M2 submission: a senior iOS developer, senior Android developer, or senior React Native / Flutter engineer with 4+ years of shipped mobile apps. The reviewer reads your GitHub repository before the session and prepares questions about specific implementation decisions. During the session: one architecture challenge (how would you structure this differently if the app needed to scale to 100k users?), one platform-specific question (how are you handling background refresh / push notification delivery guarantees?), and a live demo walk-through where the reviewer may ask you to show a specific flow.
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
Powstik Guide
A senior reviewer's written assessment of your app.
Steps
- Find someone with years of relevant work.
- Send your work beforehand.
- Let them pick what to challenge.
- Answer live, then get it in writing.
- Note what you'll change.
Template
Reviewer: Role: Years: Challenge raised: My response: Their assessment: What I'll change:
What gets sent back
- Reviewer without relevant experience.
- Verbal feedback only.
- No challenge recorded.
Resources
Foundationstart here
Depthgo deeper
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.