How long does app store review typically take?

Apple's review typically takes 24-48 hours, though it can take up to 5 business days during peak periods (holiday season, major iOS releases). Google Play reviews usually complete within a few hours to 2 days. Plan for the worst case and submit earlier than you think you need to. Track your historical review times to improve estimates.

What are the most common reasons for App Store rejection?

The top reasons are: incomplete or inaccurate metadata, requesting permissions without clear justification in the app, crashes or bugs during the review (the reviewer tests on the latest devices), missing login credentials in review notes, and guideline violations around in-app purchases (trying to bypass Apple's payment system). Review Apple's [common rejection reasons](https://developer.apple.com/app-store/review/rejections/) before every submission.

Should I use staged rollouts for every release?

Yes, unless the release is a trivial metadata-only update. Staged rollouts let you catch issues that only appear at scale (race conditions, server load, regional bugs) before they affect your entire user base. Even a 24-hour soak at 5% of users has caught critical bugs that QA missed. The cost of a slower rollout is much lower than the cost of a bad release to 100% of users.

How do I coordinate iOS and Android releases?

Aim to submit both platforms on the same day, but do not wait for one to ship before submitting the other. Apple and Google review timelines are independent. Use feature flags to control when the new feature goes live on each platform, so you can synchronize the user-facing launch even if the builds are approved on different days. Track the release in a shared tool like the [launch playbook](/launch-guide).

What should go in the "What's New" release notes?

Write for users, not developers. Lead with the most impactful change. Use plain language (not technical jargon). Keep it under 4000 characters but aim for 2-4 bullet points. Include specific improvements ("Photo loading is 40% faster") not vague claims ("Performance improvements"). Never write "Bug fixes and improvements" as the only note. Users who read release notes are your most engaged audience. ---

App Release Checklist Template for Agile Teams

What This Template Is For

Shipping a mobile app update is not like deploying a web change. You cannot hotfix a typo. You cannot roll back instantly. Every release goes through a review process that takes 1-5 days, and a rejected submission means starting the clock over. A missed step in your release process can delay a launch by a week or trigger a wave of 1-star reviews from a bug that slipped through.

This checklist covers everything from pre-submission QA through post-launch monitoring for both the iOS App Store and Google Play. It is designed to be copied and used as a literal checklist for each release cycle. The goal is to make releases boring and predictable rather than stressful and error-prone.

For a broader launch planning framework, see the Product Launch Playbook. This template focuses specifically on the technical and operational steps of getting a mobile app through store review and into users' hands.

How to Use This Template

Copy this checklist into your team's project management tool at the start of each release cycle.
Assign owners to each section (QA, engineering, PM, marketing).
Work through the checklist in order. Each section must be complete before moving to the next.
Gate submission on all P0 items being checked off.
After launch, complete the post-release section and file any learnings for the next cycle.

The Template

Pre-Release QA

☐ All P0 bugs resolved and verified on both platforms
☐ Regression testing complete on minimum supported OS versions
☐ Test on at least 3 device categories: small phone, large phone, tablet (if supported)
☐ Test on both Wi-Fi and cellular networks
☐ Test with slow/no network connectivity (airplane mode, throttled connection)
☐ Verify deep links open to correct screens from push notifications, emails, and web
☐ Test the app upgrade path from the previous production version
☐ Test fresh install flow (new user, no cached data)
☐ Verify analytics events fire correctly for all key user flows
☐ Run automated UI tests (Espresso, XCUITest, or Detox)
☐ Performance testing: cold start time under [target] seconds
☐ Memory leak check: no unbounded growth during 30-minute session
☐ Battery consumption test: app does not drain more than [%] per hour in foreground

iOS-Specific Checks

☐ Build tested on TestFlight with internal testers
☐ App Transport Security (ATS) exceptions documented and justified
☐ Privacy manifest (PrivacyInfo.xcprivacy) updated with current data collection details
☐ Required reason APIs documented (UserDefaults, file timestamp, system boot time, disk space)
☐ App Tracking Transparency prompt implemented correctly (if using IDFA)
☐ Sign in with Apple implemented (required if any third-party login is offered)
☐ In-app purchase receipt validation working correctly
☐ Widget / App Clip / Live Activity tested (if applicable)
☐ Minimum deployment target matches what is declared in App Store Connect
☐ Screenshots updated for all required device sizes (6.7", 6.5", 5.5"; iPad if universal)

Android-Specific Checks

☐ Build tested on Google Play internal testing track
☐ Target SDK version meets Google Play's current requirement (API 34+ as of 2026)
☐ Runtime permissions handled correctly (notification permission on Android 13+)
☐ Data Safety section in Google Play Console matches actual data collection
☐ ProGuard/R8 rules verified (no crashes from obfuscated code)
☐ 64-bit build included (required for Google Play)
☐ App Bundle (AAB) format used (not APK)
☐ Adaptive icon provided
☐ Screenshots updated for phone and tablet (if supported)
☐ Test on at least one low-end Android device (2-3 GB RAM)

App Store Metadata

☐ Version number incremented correctly (semantic versioning)
☐ "What's New" release notes written in user-facing language (not commit messages)
☐ App description reviewed and keywords updated (see ASO template)
☐ Screenshots reflect current UI (not outdated designs)
☐ App preview video updated if UI changed significantly
☐ Support URL and Privacy Policy URL are valid and accessible
☐ Age rating accurate for current content
☐ Category and subcategory still appropriate

Compliance and Legal

☐ Privacy policy updated to reflect any new data collection
☐ Terms of service reviewed if pricing or features changed
☐ GDPR/CCPA consent flows tested for users in regulated regions
☐ COPPA compliance verified (if app is used by or marketed to children)
☐ Export compliance documentation current (encryption usage)
☐ Accessibility: VoiceOver (iOS) and TalkBack (Android) tested on key flows

Staged Rollout Plan

☐ Define rollout stages with percentage and duration

Stage	Percentage	Duration	Success Criteria
Internal	Team only (TestFlight / Internal Track)	2-3 days	No P0 bugs, analytics verified
Limited	5-10% of users	2-3 days	Crash rate < [%], no new P0
Expanded	25-50% of users	2-3 days	No regression in key metrics
Full	100% of users	-	Monitoring continues

☐ Define rollback criteria (crash rate threshold, critical bug count)
☐ Confirm ability to halt rollout on both platforms
☐ Ensure previous version is still available for rollback if needed

Submission

☐ Final build uploaded to App Store Connect and Google Play Console
☐ Build selected for review in both consoles
☐ Review notes written for Apple reviewers (demo account credentials, feature explanations)
☐ Content rights documentation attached (if using licensed content)
☐ Phased release option selected (iOS) / staged rollout percentage set (Android)
☐ Release scheduled or set to manual release (not auto-publish unless confident)

Post-Release Monitoring

☐ Monitor crash reporting dashboard (Crashlytics, Sentry) for first 24 hours
☐ Check crash-free rate: target > 99.5%
☐ Monitor app store ratings and reviews daily for first week
☐ Respond to negative reviews within 24 hours
☐ Verify analytics event volumes match expected patterns
☐ Check key funnel conversion rates against pre-release baselines
☐ Monitor customer support ticket volume for release-related issues
☐ Confirm staged rollout is proceeding on schedule

Post-Release Retrospective

☐ Document any issues discovered during release
☐ Log time from submission to approval (track trends)
☐ Note any app store review feedback or rejection reasons
☐ Update this checklist with new items based on learnings
☐ Share release summary with stakeholders

Release timeline:

Date	Milestone
Feb 24	Feature freeze, QA begins
Feb 28	TestFlight build to internal testers
Mar 3	Submit to App Store Connect and Google Play
Mar 5	Apple approval received
Mar 5	10% staged rollout begins
Mar 7	Expanded to 50% (no critical issues)
Mar 10	Full rollout (100%)

Rollback criteria: Halt rollout if crash-free rate drops below 99%, or if more than 3 P0 bugs are reported in the first 48 hours.

What's New text:

"Share your progress with friends. See what your connections are working on, send encouragement, and celebrate milestones together. Plus: faster app launch time and bug fixes."

Key Takeaways

Mobile releases cannot be hotfixed. A missed step can cost a week of delay and user trust
Always use staged rollouts. A 24-hour soak at 5% catches issues that QA cannot
Submit to both stores simultaneously but use feature flags to synchronize the user-facing launch
Write release notes for users, not developers. Lead with the most impactful change
Run a post-release retrospective and update this checklist after every release

About This Template

Created by: Tim Adair

Last Updated: 3/4/2026

Version: 1.0.0

License: Free for personal and commercial use

App Release Checklist Template for Agile Teams