A useful guide does not promise certainty. It gives you better questions, a shared vocabulary and a clear place to start.
Store submission
Metadata, screenshots, privacy declarations, account deletion route and subscription terms — the four most common rejection causes.
Observability
Crash reporting, funnel events and day-seven retention wired up before launch, not after the first month is lost.
Release safety
Staged rollout, over-the-air update path and a rehearsed rollback for the release that goes wrong.
States and edge cases
Offline, permission-denied, empty and error states reviewed on a real mid-range device.
Run this in the fortnight before submission, on a mid-range Android device, on mobile data, with office wifi turned off.
- In-app account deletion route present and reachable in three taps
- Privacy declarations match what the app actually collects
- Subscription price, term and renewal stated before purchase
- Screenshots current for every required device size
- Crash reporting live with symbols or source maps uploaded
- Events instrumented for signup, first value and the core job
- Retention cohorts defined before launch, not after
- Phased rollout enabled, starting below 10% of users
- Rollback or kill-switch tested rather than assumed
- Signing credentials held by the company, not one laptop
- Airplane mode mid-upload behaves correctly
- Session expiry, denied permissions and empty accounts all reviewed
12 items · no email required
Where teams go wrong with this
Four failure patterns we have watched play out often enough to name. None of them is caused by a lack of effort; all of them are caused by sequencing.
Testing only on the newest phone
The flagship in your pocket hides the performance and layout problems most of your users will meet. Test on a mid-range Android device, on mobile data, with office wifi off.
Analytics wired up after launch
Retention is a comparison, so the first cohort is the most valuable one you will ever have. Instrument the funnel and day-seven retention before submission, not after the first month is lost.
No rehearsed rollback
Staged rollout without a practised way back is a plan with one branch. Rehearse the rollback on a release that does not matter, so the first time is not the bad time.
Privacy declarations written from memory
Declarations that do not match what the app actually collects are among the most common rejection causes, and the fix costs a review cycle you will not have spare.
Questions this guide raises
In our experience: missing in-app account deletion, privacy declarations that do not match observed behaviour, subscription terms not stated before purchase, and screenshots that no longer reflect the app. All four are checkable in an afternoon.
Plan for a week even though it is often quicker, and never schedule a launch campaign against an unreviewed build. If a date genuinely cannot move, submit a fortnight early with the release paused.
Usually not for a first release. Launching one platform first halves the surface area for the fortnight where you learn the most, and the second launch is meaningfully better for it.
- Website Redesign Planning GuideThe questions to settle before design starts.
- E-commerce Migration ChecklistHow to replatform without losing orders, URLs or rankings.
- Web Accessibility Audit TemplateA clear, team-friendly way to turn WCAG findings into action.