Mobile App Launch Checklist: 14 Things to Do Before You Hit Publish

App store rejections, one-star reviews on launch day, and a week-one hotfix sprint. These are all symptoms of the same problem: shipping without checking the things that matter. We've launched enough mobile apps to know which checklist items actually save you, and which ones are cargo cult busy-work.

This is the list we run through before every App Store and Play Store submission.

Before submission

1. Run on real devices, not just simulators

The simulator lies. Gestures behave differently, memory pressure is absent, and network conditions are idealised. Run your release build on at least one physical iPhone and one physical Android device. Ideally the oldest devices you intend to support.

2. Test on your minimum supported OS

If you support iOS 16+, test on an iOS 16 device, not just iOS 17. API availability differs, and so does rendering behaviour. The same applies to Android. A Pixel on Android 12 will surface issues your Android 14 test device hides.

3. Visual regression check across screen sizes

Small iPhone SE, large iPhone Pro Max, small Android, large Android tablet. Your layout assumptions from the design file will be wrong for at least one of these. Automated visual testing across your device matrix is the only way to catch all of them efficiently.

4. Handle no network gracefully

Turn off WiFi, turn off cellular, then use your app. Every screen that makes a network request should show a meaningful error state, not a blank screen or an unhandled exception. Bonus: test on 2G throttling in developer settings reveals every unoptimised API call.

5. Handle session expiry

Let your auth token expire (or force-expire it from the backend). The app should redirect to login gracefully, not crash or get stuck in a loading spinner. This hits users who haven't opened the app in weeks. A common pattern.

6. Push notifications end-to-end

Tap a notification from a cold start. Tap one while the app is backgrounded. Tap one while the app is foregrounded. All three flows have different handling and all three can break independently.

7. Deep links

Test every deep link your app is supposed to handle. Universal links on iOS and App Links on Android need server-side verification files. Confirm they're deployed before submission. A deep link that 404s silently does nothing. The user just doesn't land where you intended.

8. Permissions flow

Request each permission you need (camera, location, notifications, contacts) and test: user grants it, user denies it, user grants then revokes it in Settings. The "denied then revoked" path is the one that causes crashes.

9. Accessibility audit

Run your critical screens through the iOS Accessibility Inspector and Android's Accessibility Scanner. Missing content labels, insufficient contrast, and untappable small targets are common, and they're blocking issues for some users.

10. Performance profile

Check your main screen's render time in Instruments (iOS) or Android Profiler. Dropped frames on scroll, slow initial load, and memory spikes under normal usage are findable and fixable before launch. They're much harder to debug after.

App store assets

11. Screenshots for every required device size

Apple requires screenshots in specific sizes. Google Play has its own requirements. Generate them on actual devices (not designed mockups) where possible. The App Store review team has rejected apps for screenshots that don't match the actual UI.

12. Privacy manifest (iOS 17+)

Apple now requires a PrivacyInfo.xcprivacy file declaring which APIs you use and why. Missing it causes rejection. Check every third-party SDK you bundle many require their own privacy manifest entries.

Post-submission, pre-launch

13. Staged rollout

Both the App Store and Play Store support phased rollouts. Start at 5–10% of users. Monitor crash rates and reviews before widening. The ability to pause a rollout has saved launches that would otherwise have become incidents.

14. Error monitoring live before launch

Sentry (or equivalent) should be wired up and actively reporting before your first user arrives. The first 24 hours of a launch surface bugs you didn't see in testing. You need visibility before they compound.

The one thing

If you take nothing else from this list: test the full journey from a clean install on a real device you've never used for development. Forget nothing. Notifications, deep links, first-launch onboarding, permissions. Developers see their own app too often. A fresh device reveals what fresh eyes see.