Overview

Submitting a mobile app to the App Store and Google Play is not the finish line. A smooth launch depends on dozens of small decisions about testing, store listings, analytics, support and what happens on the day after release. Missing one of them can mean a rejected submission, a crash that nobody notices, or users who cannot reach you.

This checklist groups those tasks into stages. Use it as a starting point and adapt it to your app, your audience and your release schedule.

Four to six weeks before launch: product readiness

Start by freezing the scope of the first release. Late feature additions are a common cause of delayed launches and untested code. Anything not finished by this point should move to a later update.

Then test on real devices, not just simulators. Cover a range of screen sizes, older operating system versions you intend to support, slow and intermittent connections, and both light and dark modes.

  • Freeze the feature set for version one.
  • Run a closed beta through TestFlight and Google Play internal or closed testing.
  • Test sign-up, login, password reset and account deletion end to end.
  • Check offline and poor-network behaviour, including clear error messages.
  • Review accessibility: text scaling, screen reader labels and colour contrast.
  • Confirm performance on a lower-end Android device, not only flagship phones.

Accounts, compliance and policies

Store reviewers check more than the app itself. Make sure the business and legal paperwork is ready well before submission, because developer account verification can take time, particularly for organisation accounts.

Both stores require you to describe what data your app collects and why. Apple's privacy details and Google Play's data safety section must match what the app and any third-party SDKs actually do, so audit your analytics, crash reporting and advertising libraries before filling them in.

  • Enrol in the Apple Developer Program and Google Play Console under the correct legal entity.
  • Publish a privacy policy and terms of use at stable URLs.
  • Complete App Store privacy details and the Google Play data safety form accurately.
  • Provide in-app account deletion if users can create accounts.
  • Prepare a demo account and notes for app reviewers if login is required.
  • Check age rating questionnaires and any region-specific requirements.

Store listing and assets

Your store listing is often the first and only thing a potential user sees before deciding to install. Write it for people, not just for search. Lead with the main benefit, keep the description scannable and avoid claims you cannot support.

Prepare screenshots for each required device size, and make sure they show the real app. Consider localising the listing for your main markets if your audience spans several languages.

  • App name, subtitle or short description, and full description.
  • Keywords for the App Store and a well-written Play description for search.
  • Screenshots for the required phone and tablet sizes, plus an optional preview video.
  • App icon in all required sizes and a Play feature graphic.
  • Support URL, marketing URL and a contact email that someone actually monitors.

Measurement and monitoring

Once the app is in users' hands, you cannot see their screens. Crash reporting and analytics are how you find out what is happening. Set them up during beta so you can confirm events are firing correctly before launch.

Decide on a small set of events that describe the core journey, such as account created, onboarding completed and key action performed. A short, reliable list is more useful than hundreds of events nobody reviews.

  • Integrate crash reporting, for example Firebase Crashlytics or Sentry.
  • Define and test core analytics events and funnels.
  • Set up backend monitoring and alerts for API errors and slow responses.
  • Configure push notifications and test opt-in flows on both platforms.
  • Add a way to prompt for store reviews at a sensible moment, within store rules.

Release week

Submit early. Review times vary, and a rejection can require changes and resubmission. Apple lets you release manually once approved, which gives you control over timing. On Google Play, a staged rollout lets you release to a percentage of users first and pause if something goes wrong.

Make sure your backend is ready for real traffic, and that someone is available to respond during the first days after launch.

  • Submit builds with enough time for review and possible resubmission.
  • Use manual release on iOS and staged rollout on Android.
  • Confirm production API keys, environment settings and payment configuration.
  • Prepare answers to likely support questions and a short FAQ.
  • Agree who monitors crashes, reviews and support messages each day.

After launch

The first weeks generate valuable information. Read every review, reply to the ones that need a response, and watch crash-free rates and drop-off points in your funnels. Plan a first maintenance update so you can ship fixes quickly rather than bundling them with new features.

Keep a running list of feedback and sort it into fixes, improvements and new ideas. Revisit the roadmap once you have real usage data, not before.

  • Track crash-free sessions and fix the most common crashes first.
  • Respond to store reviews politely and specifically.
  • Schedule a first patch release within the first few weeks.
  • Keep SDKs and target operating system versions up to date to meet store policies.
Have a project where this applies? Let’s discuss it