App Release Checklist Template for Agile Teams

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.

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.

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.

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).

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. ---