Mobile App Launch Checklist 2026 (React Native + Expo)
The pre-launch checklist that catches the things you forget. Account deletion, App Store metadata, push permissions, paywall localization, analytics, and the boring legal items that block submission.
Written by
Kaspar Noor
Updated May 4, 2026
Use this before you submit, not after rejection
This is the checklist I run before every store submission. It is opinionated toward Expo / React Native apps, and it catches the items that get apps rejected on the first review or buried after launch.
Most launch checklists you find online are either generic marketing fluff or pre-2024 advice that misses the things both stores added recently. This one is grounded in what Apple and Google actually enforce in 2026, plus what teams keep forgetting.
If you are still in build mode, the React Native boilerplate chooser can help you skip a lot of the setup that this checklist depends on.
This section trips up half of all submissions in 2026 because Apple now strictly enforces account deletion and Sign in with Apple parity.
Email/password sign-up works end to end
Magic link or email verification flow tested on a real device
Google sign-in works on iOS and Android
Sign in with Apple is offered if you offer any other social login (Apple requires this)
In-app account deletion is implemented and works (Apple requires this since 2022, still enforced)
Account deletion actually removes user data on the backend, not just signs the user out
Password reset flow works on a real device, not just the simulator
Deep links from email return the user into the app, not the browser
Logged-out state never shows protected content
Account deletion is the most common rejection reason for apps with auth. The button has to be reachable inside the app. Sending the user to a website to delete their account is rejected.
If you are using Supabase or Convex, our authentication tutorial covers the production shape of these flows.
Paywall shows at least one subscription option clearly
Restore purchases button is visible and works
Free trial terms are displayed clearly (length, then what)
Subscription length and price are visible before purchase
Subscription terms link to your terms of service
Privacy policy is linked from the paywall
RevenueCat or store entitlements verified server-side, not just client-side
Subscription cancellation instructions are findable in-app or in support
Family Sharing setting decided (enable or disable explicitly)
Promotional offers configured if you plan to use them
The "verify server-side" item is the one that ships broken in many apps. Client-side state can be tampered with on jailbroken devices. Your server functions for paid features should check entitlement against RevenueCat or a webhook-synced server table.
App icon at 1024x1024 with no alpha channel and no transparency
iOS screenshots for 6.7-inch and 6.5-inch devices, optionally iPad
Android screenshots at the right aspect ratios for phone and 7-inch / 10-inch tablet
App preview videos prepared if you plan to use them
Title, subtitle, and keywords optimized for ASO
Promotional text written and current
What's New text written for v1
Age rating completed honestly (Apple) and IARC questionnaire completed (Google)
Content rights confirmed for any third-party content shown in screenshots
Marketing URL and support URL both live
ASO is a separate topic, but the basics are: put your most-searched keyword in the title, the secondary keywords in the subtitle, and the rest in the keyword field. Do not waste keyword space on your brand name.
These are the ones that will get the app pulled, sometimes after a successful first launch:
GDPR consent flow if you target EU users and collect any personal data
CCPA notice if you have California users
COPPA compliance if your audience includes children under 13
DSA terms compliance for EU (Apple and Google both enforce this in 2026)
Data deletion request mechanism that an end user can actually use
Third-party SDK list current with what is shipped in the binary
All TODO and console.log statements stripped from the production bundle
Debug menus hidden behind a feature flag, not just commented out
The "console.log stripped" item matters because reviewers and security researchers do read your bundle. Leaving an internal admin URL or staging API key in production is a common mistake.
Monitoring crash reports and shipping a 1.0.1 within a few days.
Watching paywall conversion and tweaking copy.
Replying to early App Store and Play Store reviews promptly (Apple shows your response publicly).
Watching for Apple or Google emails about compliance issues — they sometimes flag things post-launch.
After the first 30 days, the rhythm becomes: ship a small update every two to three weeks, plan an Expo SDK upgrade twice a year, and keep an eye on ASO.
Want this checklist baked into your codebase?
Shipnative ships with account deletion, paywall flows, push permissions, and store-ready scaffolding already in place.
