App Launch Checklist for Google Play and the App Store

Apps rarely miss their launch date because of one big bug. They miss it because of a dozen small things: a store account still waiting on verification, a reviewer who could not log in, a privacy form that did not match the SDKs inside the build. This app launch checklist covers those things for Google Play and the App Store, in the order you should deal with them, counting back from the day you want to be live.

The timings assume a first release. Updates are faster, but most of the list still applies.

Six weeks out: accounts and the steps you cannot rush

Store accounts are the part of a launch that no amount of overtime can speed up, so start here.

• Apple Developer Program: US$99 per membership year. Enrolling as an organization requires a legal entity (no trade names or DBAs), a D-U-N-S number, a work email on your company's domain and a public website.
• Google Play Console: a US$25 one-time fee. Organization accounts also need a D-U-N-S number, and Google warns that getting one can take up to 30 days.
• New personal Google Play accounts: if the account was created after November 13, 2023, the app must run a closed test with at least 12 testers for 14 days before you can apply for production. We explain how to plan for that in our article on the Google Play closed testing rule.

Our advice here is simple: open the accounts in the name of the business that owns the app, and add your developers as team members. An app published from a freelancer's personal account is awkward to move later.

Four weeks out: build requirements that change every year

Both stores raise their technical minimums on a schedule, and the rules on the day you submit are the ones that apply.

• Android target API level: according to Google's target API level requirements, since August 31, 2026 new apps and app updates must target Android 16 (API level 36) or higher, with lower targets allowed for Wear OS, Android Automotive OS, Android TV and Android XR apps. Google offers an extension to November 1, 2026 if you request it.
• App Bundle format: new apps on Google Play have been required to publish as Android App Bundles since August 2021.
• 16 KB memory pages: apps targeting Android 15 or higher must support 16 KB page sizes on 64-bit devices. If your app uses native libraries, directly or through an SDK, rebuild and check it; from February 1, 2027, updates that do not support 16 KB pages cannot be released.
• Xcode and SDK: Apple's upcoming requirements page says that since April 28, 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later using the iOS 26 SDK (or the matching SDK for other Apple platforms).

Raising a target SDK is not just a version number. Newer Android and iOS versions change how permissions, background work and notifications behave, so do it four weeks out and test the result, not the night before submission.

Two to three weeks out: the testing half of your app launch checklist

Say you run a clinic with three doctors and your app lets patients book, move and cancel appointments. A focused test pass for that app would include:

1. Fresh install and upgrade. Install the release build on a clean phone, then install it over the previous test build to confirm that saved logins and local data survive.
2. Real devices your patients use. If most of them use mid-range Android phones, test on two or three of those, plus a couple of recent iPhones. Emulators miss memory and camera problems.
3. Bad networks. Book an appointment on a slow connection, then switch to airplane mode mid-booking. The app should never show a confirmed slot the server did not save.
4. Denied permissions. Refuse notifications and location. Booking must still work, and the app should explain what the user loses.
5. Dates and time zones. Book an 11:30 PM slot, then change the phone's time zone. Appointments that shift by hours are a classic bug.
6. Payments and cancellations in test mode, end to end, including the confirmation email or SMS.
7. Account deletion, from the button in the app to the data actually disappearing on the server.
8. Crash reporting, confirmed by forcing a test crash in a release build and seeing it arrive in your dashboard.
9. Accessibility basics: the largest system font size and a screen reader on the booking screen.

Use the free help the stores give you. On Google Play, the pre-launch report installs your app on devices in Google's test lab when you upload a bundle and flags stability, performance and accessibility issues, usually within an hour; give it test credentials so it can get past the login screen. On iOS, TestFlight lets you invite up to 10,000 external testers once your first build is approved for TestFlight testing. If you do not have anyone to run this pass, it is exactly what our QA and testing team does before a release.

Two weeks out: privacy forms and policy checks

Both stores ask you to describe what data your app collects, and reviewers compare your answers with what the app actually does. Start by writing an SDK inventory: every analytics, crash, ads, payment and login library in the build, and what each one collects. Both stores' forms come from that list.

• Privacy policy: Apple requires a link in App Store Connect and inside the app. On Google Play, every app on a closed, open or production track must complete the Data safety form and link a privacy policy, even if it collects no user data.
• Third-party code counts: Google says your Data safety answers must cover the libraries and SDKs in your app, and Apple's privacy details must include data collected by third-party partners whose code you integrate.
• Account deletion: if users can create an account in the app, Apple requires that they can also delete it within the app. Google requires an in-app path plus a web link where users can request deletion, entered in the Data safety form.
• Permissions: on iOS, every permission needs a purpose string that says plainly why you need it. Ask at the moment the feature needs it, not on first launch.
• Tracking: if the app tracks users' activity, Apple requires their explicit permission through the App Tracking Transparency APIs.
• Age rating: Apple updated its age rating questions, and responses are needed in App Store Connect before you submit updates.

One week out: store listing and review notes

Apple's list of common review issues includes inaccurate screenshots and incomplete review information, so give this step a full day. The guidelines say screenshots should show the app in use, not just a splash or login screen, and app names are limited to 30 characters. The guidelines also tell you not to pack metadata with trademarked terms, popular app names or irrelevant phrases.

If your app has a login, give reviewers a working demo account with realistic data, and keep your backend switched on during review. Apple's guidelines say exactly that. Use the review notes to explain anything a stranger might not find: "Doctor accounts are created by the clinic; use the demo patient account to book, move and cancel." Make sure your support URL has a working way to contact you.

Launch week: control the release

• Decide when it goes live. Google Play's managed publishing lets you choose the exact moment an approved update is published. On the App Store, set the version to release manually, so an approved build waits as Pending Developer Release until you are ready.
• Plan gradual rollouts for your first update. Google Play staged rollouts and App Store phased release work for updates only, not a first release. Apple's phased release spreads an update over seven days, from 1% to 100% of users with automatic updates, and can be paused. On Google Play you set the percentage yourself and can halt a rollout if something goes wrong.
• Be ready to ship a fix. Keep a hotfix branch, a person on call and a tested release pipeline. Apple accepts expedited review requests for critical bug fixes.
• Watch the first 48 hours: crash rates, server errors, sign-up drop-off and the support inbox.

Not every launch needs all of this. An internal app distributed to 20 staff through a private channel can skip most of the store listing work. Everything that touches data, permissions and review, though, applies to any app on a public store.

Print this app launch checklist, put dates against each section and give each item an owner. For iOS-specific items such as signing, TestFlight groups and review notes, our iOS developers can go through your build and submission with you, and our Android team can do the same for Google Play. If you would rather describe your launch first, tell us where you are and we will suggest the next step.