A mobile app launch checklist exists because launches fail on small things. Not the big features, which everyone tests, but the privacy label that does not match the SDKs, the demo account that expired the night before review, the push certificate nobody renewed, or the store screenshots from two designs ago. Each one costs days, and on launch week days are what you do not have.
This app launch checklist is the one we work through on every release, organised by timeline: six weeks out, two weeks out, launch week, launch day and the first 30 days. It covers both the App Store and Google Play, with the current platform requirements. If you would rather hand the store side to a team that does it routinely, our app store launch and ASO services cover submission, listings and post-launch optimisation.
Review is where most launch dates slip. According to Apple’s 2025 App Store Transparency Report, Apple reviewed 9,100,620 submissions in 2025 and rejected 2,093,244, roughly 23%. Most rejections are avoidable with preparation.
App launch checklist at a glance: the timeline
Work back from your launch date. The earlier items are the ones that cannot be rushed.
| When | Focus | Main outputs |
|---|---|---|
| 6 weeks before | Accounts, compliance, platform requirements | Developer accounts verified, privacy policy, SDK audit, target versions confirmed |
| 4 weeks before | Store listings and beta | Screenshots, descriptions, keywords, TestFlight and Play closed testing running |
| 2 weeks before | Release candidate and QA | Feature freeze, regression on real devices, crash-free beta, analytics verified |
| Launch week | Submission and review | Builds submitted, review notes and demo account, phased release configured |
| Launch day | Release and monitoring | Release triggered, dashboards watched, support ready |
| First 30 days | Stabilise and learn | Hotfixes, review replies, ASO iteration, first data-driven backlog |
Six weeks out: accounts, compliance and platform requirements
These items have external dependencies, such as account verification and legal review, so start them first.
- Apple Developer Program and Google Play Console accounts in the company’s name, with organisation verification complete
- Vendor and team members added with the minimum roles they need; no shared logins
- Builds produced with Xcode 26 or later and the iOS 26 SDK, required for App Store uploads since 28 April 2026 per Apple’s upcoming requirements notice
- Android app targeting Android 16 (API 36), required for new apps and updates from 31 August 2026 per Google Play’s target API requirements
- In-app account deletion working if users can create accounts, as Apple requires
- SDK audit complete: every third-party SDK listed, with privacy manifests and signatures where Apple requires them (Apple privacy manifest rules)
- Privacy policy published at a public URL and linked in the app and both store listings
- App Privacy details (Apple) and Data safety form (Google) drafted from the SDK audit, not from memory
- Payment model confirmed: in-app purchase for digital goods, other payment methods for physical goods and services
- Age rating questionnaires answered honestly for both stores
- Trademark check done on the app name before it appears in any listing
Apple Guideline 2.3 requires store metadata, including privacy information, to reflect what the app actually does. Analytics, crash reporting, ads and attribution SDKs all collect data. If your privacy label says “no data collected” and an SDK says otherwise, expect a rejection or worse. Build the label from the audit.
Four weeks out: store listings and beta testing
Listings take longer than anyone budgets for, especially in several languages.
- App name, subtitle (iOS) and short description (Android) written with target keywords
- Full description focused on the first three lines, which are what most people read
- Screenshots for every required device size, from the current build, with captions
- App preview video (optional) showing real in-app footage
- App icon final at all sizes, legible at small scale, no third-party brand marks
- Keyword field (iOS) researched; no competitor names
- Support URL, marketing URL and contact email working
- TestFlight external testing group and Play Console closed testing track running with real users
- Feedback channel for beta testers and a triage owner
- Localised listings for each launch market, if applicable
Two weeks out: release candidate and QA
Freeze features. From now on, only fixes go in. If you need deeper test coverage, our mobile app testing services page explains how we test on real devices.
- Feature freeze declared; release branch cut
- Full regression on real devices: at least one older and one current iPhone, and a spread of Android devices including a mid-range phone
- Fresh install, upgrade from the previous version, and offline / poor network tested
- Permissions requested in context, with clear purpose strings; app still usable if permission is denied
- Deep links, push notifications and in-app purchases tested end to end on production configuration
- Crash reporting (Crashlytics or Sentry) live, with symbol files uploaded so crashes are readable
- Analytics events firing and visible in the dashboard; launch metrics defined
- Backend load-tested for launch traffic; rate limits and monitoring in place
- Production API keys, environment variables and certificates confirmed; nothing pointing at staging
- Accessibility basics checked: dynamic type, screen reader labels, contrast
- Rollback plan written: feature flags for risky features, and how to pause a phased rollout
Want the store side handled for you?
We prepare listings, privacy forms, review notes and phased rollouts, and handle reviewer questions while you focus on launch.
Launch week: submission and review
The submission steps themselves (upload, review notes, demo account, product page) are covered in our guides on how to publish an app on the App Store and how to publish an app on Google Play. This list is only what launch week adds on top. Submit early in the week, so review feedback arrives while your team is working.
- Both builds submitted, with review notes and a non-expiring demo account checked the same day
- Release set to manual or scheduled release on iOS, so approval does not trigger the launch early
- Phased release (iOS) or staged rollout percentage (Android update) agreed, with a named person who can pause it
- Launch date held back until both approvals are in; no press or paid campaign dated before then
- Team on standby to answer reviewer questions the same working day
- Website, landing page and store badges ready, links pointing at the right listings in each market
Marketing, support and press tasks for launch
Review is not the only thing that slips a launch. Most rejections come from a short list of causes (crashes on an untested device, placeholder content, a broken demo login, privacy answers that do not match the SDKs), and we cover each with fixes in top App Store rejection reasons. The tasks below are the ones no store checks, so nobody owns them unless you name someone.
| Task | When | Owner |
|---|---|---|
| Featuring nomination in App Store Connect (Apple asks for at least a few weeks’ notice, ideally up to three months) | 6–12 weeks before | Marketing lead |
| Press list and press kit: icon, screenshots, short description, founder quote, contact | 3 weeks before | Marketing or PR |
| Help-centre FAQ and canned replies written from beta feedback | 2 weeks before | Support lead |
| Waitlist and beta-tester email drafted with store links per market | Launch week | Marketing lead |
| Incident message templates ready (in-app banner, email, social) in case of an outage | Launch week | Product owner |
| Social posts and press emails sent only once the listing is live in key markets | Launch day | Marketing lead |
| iOS promotional text updated for launch news (changeable without a new submission) | Launch day | Marketing or ASO lead |
| Store review replies, with bug reports passed to engineering | Daily, first two weeks | Support lead |
| Week-one summary to stakeholders: installs, crash-free rate, top support issues | Day 7 | Product owner |
Apple featuring guidance and promotional text rules per App Store Connect documentation. Featuring is an editorial decision, so a nomination is a request, not a guarantee.
Who owns what during launch
Most launch-day confusion comes from unclear ownership. Name one person per row before launch week.
| Area | Owner | Decides |
|---|---|---|
| Store accounts and release button | Product owner (client side) | When to release, pause or roll back |
| Build, signing and submission | Lead engineer | Which build goes out; hotfix scope |
| Monitoring | Engineer on call | When to raise an incident |
| Store listings and ASO | Marketing or ASO lead | Listing changes after launch |
| User support | Support lead | Escalation of bugs to engineering |
On an app launch checklist, ownership is the item teams most often leave blank. Keep the client as owner of the store accounts and the release decision.
Launch day
Keep launch day boring. Everything on this list should already be prepared.
- Release triggered at a time when both engineering and support are online
- Crash-free sessions, API error rates and sign-up funnel watched on a shared dashboard
- Phased rollout paused immediately if crash rates rise
- Support inbox, in-app help and FAQ ready; canned replies drafted for predictable questions
- Announcement, email and social posts sent once the listing is live in your key markets
- One person owns the decision to roll back or hotfix
First 30 days after launch
The launch is the start of the learning, not the end of the project.
- Reply to store reviews, especially negative ones with fixable issues
- Hotfix release ready within days for any top crash
- Weekly review of retention, funnel drop-off and crash-free rate
- First ASO iteration: test screenshots or subtitle against install conversion
- Prompt for ratings at a moment of success, using the native review APIs
- Backlog reprioritised from real usage data
- Maintenance calendar set: annual Google Play target API deadline every 31 August, and Apple’s September OS releases
Plan for life after launch
An app is never finished. Each year brings a new iOS release, a new Android target API deadline, SDK updates and security fixes. Budget for that before launch, not after the first warning email. Our guide to mobile app maintenance costs breaks down what to expect, and our app maintenance and support service covers it as a monthly plan.
If you are still building, the 12-week MVP plan shows where launch preparation fits into the schedule, so the checklist above starts on time rather than in the final week.
For the store steps in detail, see our guides on how to publish an app on the App Store and how to publish an app on Google Play.
FAQs about launching a mobile app
How long does App Store review take?
Apple says it typically reviews at least 50% of submissions in under a day and 90% in under two days. That is typical timing, not a promise: a rejection restarts the clock and busy periods run slower. Leave about a week between first submission and a fixed launch date, set the release to manual so approval does not publish early, and keep someone free to answer reviewer questions.
Should I launch on iOS and Android at the same time?
If your users are on both platforms and your team can support both, yes. A simultaneous launch simplifies marketing. If resources are tight, launching on one platform first lets you fix issues with a smaller audience. For US-focused apps, the split between iOS and Android is close, so most products need both within a short period.
What is a phased release or staged rollout?
Both stores let you release an update to a portion of users first. On iOS, phased release spreads an update over several days; on Google Play, you choose the rollout percentage. If crash rates rise, you pause the rollout before most users are affected. Use it for every significant update, not only the first launch.
What do I need for an app launch checklist on Google Play?
The essentials are a verified Play Console account, an app targeting Android 16 (API 36) for new apps and updates from 31 August 2026, a completed Data safety form, content rating, privacy policy URL and store listing assets. Running a closed testing track before production is strongly recommended. Staged rollout lets you release gradually and pause if problems appear.
How far in advance should I start preparing for launch?
Start about six weeks before your target date. Account verification, legal review of the privacy policy, SDK audits and store listings all take longer than expected, and some depend on people outside the team. Feature freeze should happen around two weeks before launch, leaving time for regression testing and a stable beta.
Launch with fewer surprises
Tell us your launch date and where the app is today. We reply within one business day with a launch plan covering QA, store listings and submission.