A mobile app launch rarely fails because of the code. It fails because the build was rejected two days before a planned announcement, because the Google Play data safety form did not match what the SDKs actually collect, or because the app crashed on a device nobody tested and the team had no crash reporting to tell them. A good mobile app launch checklist exists to remove those surprises, so launch day is about users rather than firefighting.
This is the checklist we work through with clients before and after shipping to the App Store and Google Play. It assumes the app is built and tested; if you are still deciding how to build it, start with our comparison of React Native vs native app development and our breakdown of mobile app development cost.
Before you submit: accounts, builds, and timelines
- Developer accounts in the company's name. Apple Developer Program and Google Play Console accounts should belong to your organisation, not to a freelancer or agency. Organisation enrolment can require verification steps that take days, so start early.
- Plan for Google Play testing requirements. Newer personal Google Play developer accounts must run a closed test with a minimum number of testers over a set period before they can publish to production. Check the current rules in Play Console and build that time into your plan.
- Production builds, signed correctly. Release builds with debug logging removed, correct bundle identifiers, and signing keys stored safely. Losing an upload key is recoverable on Google Play, but painful.
- Target current OS versions. Google Play requires apps to target a recent Android API level, and Apple expects builds made with a recent Xcode and SDK. Old toolchains are a common source of last-minute blockers.
- Buffer for review. Do not announce a launch date that assumes first-time approval. Leave room for at least one rejection and resubmission.
How to pass App Store review and Google Play approval
Most rejections we see are not about the core product. They are about missing information, broken edge cases, or policy details. Read Apple's App Store Review Guidelines once in full before your first submission; it is time well spent.
Give reviewers a working test account
If your app has a login, provide a demo account in App Store Connect's review information and in Play Console's app access section. Make sure it has realistic data, does not require a one-time code sent to a phone the reviewer cannot access, and still works on the day of review. A reviewer who cannot get past the login screen will reject the build.
Privacy nutrition labels and the data safety form
Apple's App Privacy details (often called privacy nutrition labels) and Google Play's Data safety section both ask what data your app collects, why, and whether it is linked to the user or used for tracking. These must cover everything your third-party SDKs collect, not just your own code. Analytics, crash reporting, advertising, and support chat SDKs all count. On iOS, also confirm your app and its SDKs include the required privacy manifests, and that you request App Tracking Transparency permission if you track users across other companies' apps.
Common rejection causes to check
- Crashes or broken flows on the reviewer's device, often on a tablet or older OS version you did not test.
- No in-app way to delete an account, when the app allows account creation.
- Selling digital content or subscriptions without using the platform's in-app purchase system where the rules require it.
- Permission prompts that do not explain why the app needs camera, location, or contacts access.
- Placeholder content, broken links, or a privacy policy URL that does not load.
- An app that is essentially a website in a wrapper, with no meaningful native functionality.
App Store Optimization basics for launch
App Store Optimization (ASO) decides whether people who search for your category ever see your app. At launch, get the fundamentals right:
- Title. Brand name plus your most important keyword, within the character limits each store allows. Do not stuff it; both stores penalise that.
- Subtitle and keywords. On the App Store, use the subtitle and the hidden keyword field for terms not already in your title, without repeating words. On Google Play, there is no keyword field, so the short and full descriptions carry your keywords and should read naturally.
- Screenshots. Most people decide from the first two or three screenshots without reading anything. Lead with the core outcome, use short captions, and show real screens rather than abstract marketing art.
- Category and ratings. Choose the category where your target users browse, and plan when to ask for ratings: after a success moment, using the native review prompt, never in the middle of a task.
- Localisation. If you are launching in multiple markets, such as the UAE and wider GCC, localise the listing as well as the app. Arabic listings with proper right-to-left screenshots reach a different audience than English-only ones.
Crash reporting and analytics for a mobile app launch
You cannot fix what you cannot see, and mobile users rarely report crashes; they uninstall. Before launch, add:
- Crash reporting with Firebase Crashlytics or Sentry, with symbol files (dSYMs on iOS, mapping files on Android) uploaded for every build so stack traces are readable. For React Native, make sure JavaScript errors are captured too, not just native crashes.
- Product analytics with a short, named list of events covering onboarding steps and your activation event: the action that shows a user got value. Firebase Analytics, PostHog, and Mixpanel all support mobile.
- Release tracking so every crash and event is tagged with the app version. Users update slowly, and you will have several versions live at once.
- Remote config or feature flags so you can switch off a broken feature without waiting for a new review.
Push notification strategy that does not drive uninstalls
Push notifications are the most powerful retention tool you have and the fastest way to get uninstalled. On iOS, and on Android 13 and later, users must grant permission, and you usually get one good chance to ask.
- Ask in context. Do not show the system prompt on first launch. Ask when the user does something that makes notifications obviously useful, such as booking an appointment or following an order, ideally with a short explanation screen first.
- Make every notification useful. Transactional messages (your order shipped, your booking is confirmed) are welcome. Generic "we miss you" messages are not.
- Give users control. Use notification categories or channels so users can mute promotions without losing important updates.
- Measure opt-outs, not just opens. A campaign that lifts opens but increases notification disables is a loss.
Technically, Firebase Cloud Messaging covers both platforms and is what we typically use; on DataCorpGroup AI we paired FCM push with in-app and email notifications and let users set channel preferences per event, which is the kind of control that keeps opt-outs low. For loyalty and wallet-style products, VEXION uses APNs alongside web push.
Retention and post-launch update cadence
Downloads feel like the launch metric, but retention is what tells you whether the app works. Track cohorts by install date and watch three checkpoints:
- Day 1 retention mostly reflects onboarding: did users understand the app and reach value in the first session?
- Day 7 retention reflects whether the app fits into a weekly habit or need.
- Day 30 retention reflects whether there is a lasting reason to come back.
Benchmarks vary widely by category, so compare your cohorts against each other over time rather than chasing an industry number. If day 1 is weak, fix onboarding before anything else; no amount of push notifications will rescue a confusing first session.
For updates, plan a fix release within the first one to two weeks, because real users always find something. Use staged rollouts on Google Play and phased release on the App Store so a bad build reaches a small share of users first. After that, a steady cadence of every two to four weeks keeps the app current, shows reviewers and users the product is maintained, and keeps each release small enough to roll back safely.
Frequently Asked Questions
How long does App Store and Google Play review take?
Review times vary and change over time. Many apps are reviewed within a day or two, but first submissions and apps in sensitive categories can take longer, and a rejection restarts the clock. Always build in buffer before a public launch date.
Do I need a privacy policy to publish a mobile app?
Yes. Both stores require a privacy policy URL for most apps, and it must match what you declare in Apple's App Privacy details and Google Play's Data safety section, including data collected by third-party SDKs.
What is the most common reason apps get rejected?
In our experience, the most common causes are reviewers being unable to log in, crashes or broken flows on devices the team did not test, missing account deletion, and incomplete or inaccurate privacy disclosures.
Should I launch on iOS and Android at the same time?
If your audience is on both platforms and you built with a cross-platform framework, launching together is usually sensible. If budget forces a choice, launch where your target users are concentrated and treat the second platform as a fast follow.
If you are preparing to launch, or want someone to run through this checklist with your build, our mobile app development team handles store submission, monitoring, and post-launch releases for React Native and native apps. Get in touch and we will review your launch plan with you.