App Store Launch Checklist 2025
Getting rejected from the App Store or Google Play after weeks of preparation is one of the most demoralizing experiences in the founder journey. Most rejections are avoidable with proper preparation.
Apple App Store Requirements
Metadata - App name: 30 characters max, no keyword stuffing, no competitor brand names - Subtitle: 30 characters max, descriptive of your core value - Description: up to 4,000 characters; first 3 lines are visible before "more" — make them count - Keywords field: 100 characters total; use commas, no spaces, no repeated words from name/subtitle - Privacy policy URL: required for all apps; must be accessible without login - Support URL: required; must actually work
Visual Assets - App icon: 1024x1024px PNG, no rounded corners (Apple applies rounding), no transparency - Screenshots: required for iPhone (6.7" and 5.5" sizes), iPad if your app supports it; show real UI, not just marketing imagery - App Preview video: optional but highly recommended; max 30 seconds per size class
Technical - Privacy manifest: required since Spring 2024; declare all APIs that access user data - App Tracking Transparency: required if you use tracking; request permission with a custom usage description - Sign in with Apple: required if you offer any other third-party login - IPv6 compatibility: your app must work on IPv6-only networks - No crash on launch: Apple's review team will reject immediately if the app crashes during review
Content and Legal - Age rating: must accurately reflect content (violence, mature themes, gambling) - No mention of Apple competitors in your app store listing or in the app itself - No reference to "beta," "test," or "demo" in the app or listing - No broken links or placeholder content visible in the app
Google Play Requirements
Metadata - Short description: 80 characters; appears in search results - Full description: up to 4,000 characters - Feature graphic: 1024x500px; shown in store and in Google search results - App icon: 512x512px PNG with alpha
Technical - Target API level: must target the current Android API level (or within one major version) - 64-bit support: required for all new apps - Sensitive permissions: each permission that accesses sensitive data requires a Data Safety Form declaration - Data Safety Form: must accurately declare what data you collect, how you use it, and whether you share it
Content Policy - Misleading metadata: descriptions and screenshots must accurately represent functionality - No prohibited content: Google has stricter content policies than Apple in some categories (financial apps, health claims)
The Submission Timeline
Allow 2–5 days for App Store review (Apple has improved review times significantly but it is still variable). Allow 1–3 days for Google Play review. Never plan a launch event or press announcement for the same day as submission.
Submit at least one week before your target launch date. This gives you time to address any rejection feedback and resubmit without missing your launch window.
What Makes a Good Launch Screenshot
Your screenshots are the single most influential asset on your store listing. Most people decide whether to install based on the first two or three images, often without reading a word of your description. Treat them as a pitch, not a photo album.
Apple has tightened its screenshot rules. For new and updated apps, the mandatory base submissions are now a 6.9-inch iPhone screenshot (1320 x 2868 pixels) and, if your app supports iPad, a 13-inch iPad screenshot (2064 x 2752 pixels). Apple automatically scales these down for smaller devices, so you no longer have to upload a separate image for every screen size. Files must be PNG or JPEG, RGB color, with no alpha channel (no transparency), and the pixel dimensions must be exact. There is no off-by-one tolerance. You can upload between 1 and 10 screenshots per device class.
Google Play is more flexible on dimensions. You can upload up to 8 screenshots per device type, with a minimum of 2 for phones. Images must be JPEG or 24-bit PNG without an alpha channel, each side between 320 and 3,840 pixels. Google also requires a feature graphic of 1024 x 500 pixels, which appears at the top of your listing and in promotional spots.
Specs aside, here is what actually converts:
- Lead with your strongest feature. Put the screen that delivers your core value first. Do not waste the first slot on a login or splash screen.
- Add short captions. A plain UI screenshot makes the viewer work. A caption like "Track every workout in one tap" tells them why the screen matters. Keep captions under about five words.
- Show real content, not empty states. Populate the app with realistic data. Empty lists and placeholder text make the app look unfinished.
- Tell a sequence. Read together, your screenshots should walk the viewer through the core journey: the problem, the action, the result.
- Localize for each market. If you target Spain and Germany, translate the captions. Screenshots in the user's own language convert noticeably better than English-only ones.
One rule both stores enforce: your screenshots must accurately represent the app. Mockups showing features that do not exist are a common rejection reason and erode trust even when they slip through.
During the Review Wait
Once you submit, Apple states that 90% of submissions are reviewed in less than 24 hours. In practice it can still take longer, especially around major iOS releases or holidays. Google Play review times vary similarly and can stretch to several days for a first submission. Plan for variability and never schedule a press announcement or paid campaign for the same day you hit submit.
The waiting period is not dead time. Use it to:
- Prepare your support channels. The support URL you submitted needs to be live and monitored from day one. Set up a basic help page or a monitored inbox.
- Stage your launch communications without publishing them. Draft your launch email, social posts, and any press outreach so they are ready the moment you are approved.
- Verify your analytics one more time. Confirm your core funnel events fire correctly in the production build, not just in testing.
- Do not push new builds unless you have to. Submitting a new binary while one is in review can reset your place in the queue.
If you have a genuinely time-sensitive reason, Apple lets you request an expedited review. Apple specifically lists two valid cases: a critical bug fix (include steps to reproduce the bug) and a time-sensitive event (include the event name, date, and your app's connection to it). Use this sparingly. It is meant for emergencies, not for routine launches.
How to Handle a Rejection
A rejection is not a verdict on your product. It is a list of items to fix, and for most apps the items are small. The most-cited rejection category is Apple's Guideline 2.1, App Completeness — crashes, bugs, broken links, and placeholder content. These are almost always fixable in a day or two.
When your submission does not pass, Apple provides the specific guidelines you did not meet through the App Review page in App Store Connect, which acts as your resolution center. Here is how to respond:
- Read the exact guideline cited. Apple tells you which rule was broken. Look it up in the App Review Guidelines and address that specific point, not what you assume the problem is.
- Reply in the resolution center. You can correspond directly with App Review to ask for clarification or explain how your app works before you resubmit. A clear, polite reply often resolves misunderstandings without a new build.
- Fix, then resubmit. Once you have addressed the issue, submit the corrected build. Each resubmission goes through review again.
- Appeal only when you are confident Apple got it wrong. If you genuinely believe your app complies and the reviewer misunderstood it, you can submit an appeal to the App Review Board. Apple allows one appeal per rejected submission, so make it count: give specific reasons, tied to specific guidelines, explaining why your app complies.
Google Play handles rejections through the Play Console, with the reason and the violated policy stated in your inbox and the app's status page. Google also offers an appeal process when you believe a decision was made in error.
The practical takeaway: build a buffer into your timeline. Submit at least a week before any date you have committed to publicly. That single habit turns a rejection from a crisis into a routine round of edits, which is all it usually is.