The Indie Developer's App Launch Checklist for 2026

Apple rejected 1.93 million app submissions in 2024. [1] Not because those apps were fundamentally broken. Most were rejected for metadata errors, missing privacy disclosures, or screenshot violations that a straightforward checklist would have caught.

If you're a solo developer shipping your first app (or your fifth), the submission process is full of requirements that aren't obvious until they block you. Google Play now requires new personal accounts to run a 14-day closed test before you can even access production. [2] Apple requires builds targeting the iOS 26 SDK starting April 28, 2026. [3] Both stores reject apps with broken privacy policy links on the spot.

This is every step you need to complete before, during, and after submission, ordered by when you should actually do it. No agency workflows. Just the checklist for shipping as a solo dev.

Table of Contents

1. Four Weeks Out: Accounts, Certificates, and Testing
2. Two Weeks Out: The Technical Pre-Submission Audit
3. One Week Out: Screenshots, Icons, and Visual Assets
4. One Week Out: Metadata and ASO
5. Submission Day: iOS and Android Side by Side
6. Launch Week: The First Seven Days
7. The Compressed Checklist

1. Four Weeks Out: Accounts, Certificates, and Testing

Start here. Not because account setup is complex, but because some steps have built-in wait times that will block you if you leave them too late.

Apple Developer Program costs $99 per year. Enrollment typically processes within 48 hours, but if Apple flags your identity verification, it can take up to a week. If you're registering as an organization rather than an individual, you'll need a D-U-N-S Number from Dun & Bradstreet, which takes 2-4 weeks to process.

Google Play Console costs $25, one-time. The account itself is instant. But here's the part most guides skip: if you created a new personal developer account after November 2023, Google requires a closed test with at least 12 testers who remain opted in for 14 consecutive days before you get production access. [2] Not 12 installs. Twelve active, opted-in testers for two straight weeks. If someone opts out, the clock restarts.

Start your closed test the day your account is active. Recruit testers from friends, developer communities, or beta testing platforms like TestFlight (iOS) or Firebase App Distribution. The 14-day timer is the single biggest bottleneck for first-time Android releases.

While you wait:

• Generate your iOS distribution certificate and provisioning profile. Certificate mismatches are the most common first-timer stumbling block on iOS. If you're using Xcode's automatic signing, verify it works by deploying to a real device, not just Simulator.
• Set up crash reporting with Firebase Crashlytics or Sentry. You want crash data from the first user session, not from week four when someone reports a vague bug.
• Integrate basic analytics. Track three events at minimum: first open, core action completed (whatever your app's primary value moment is), and upgrade or purchase tapped. You can always add more events later. You can't retroactively collect data from users who already churned.

2. Two Weeks Out: The Technical Pre-Submission Audit

Your app works on your phone. That's necessary but insufficient. Apple's review team tests on current hardware running the latest iOS version. Google's automated checks scan for crashes, ANRs (Application Not Responding events), and permission abuse.

Run through this before you open App Store Connect or the Play Console:

• Test on a real device, not just Simulator or Emulator. Animations that run smoothly on your M3 Mac will stutter on an older iPhone SE. Performance characteristics between simulated and physical hardware are meaningfully different.
• Build against the latest SDK. Starting April 28, 2026, all new iOS submissions must target the iOS 26 SDK and be built with Xcode 26. [3] If you're still building against iOS 17, your binary won't pass the upload check.
• Audit your third-party SDKs. Every SDK you include must have a valid privacy manifest (PrivacyInfo.xcprivacy on iOS). This has been required since May 2024, but it still catches developers who say "this app doesn't collect data" while their analytics SDK quietly sends device identifiers. Check each SDK's documentation for its privacy manifest file.
• Implement "Delete Account." If your app has user accounts, both stores require a visible way for users to request deletion of their account and associated data. Not optional, not new, but still a common rejection trigger.
• Verify your privacy policy URL. Both Apple and Google reject apps with broken privacy policy links. Host it on your website, not a Google Doc or Notion page that might change URLs. Test the link in an incognito browser window. For the full list of screenshot and metadata compliance rules that trigger rejections, the screenshot compliance guide covers every common violation.
• Test the empty state. Apple reviewers open your app cold, with no existing data. If it requires a login, provide demo credentials in your review notes. If the app needs data to be useful (a fitness tracker with no workouts logged, a notes app with nothing in it), the empty state needs to make sense. A blank screen with no guidance is a fast path to rejection under Guideline 4.2 (Minimum Functionality).

3. One Week Out: Screenshots, Icons, and Visual Assets

This is where most indie developers lose the most time for the least reason. You've spent months building the app itself, and now you need 6-10 polished screenshots per device class, formatted to exact pixel dimensions, with captions that sell.

The required dimensions for iOS:

• iPhone (6.9" display): 1320 x 2868 px
• iPhone (6.7" display): 1290 x 2796 px
• iPad Pro 13": 2064 x 2752 px

For the complete list of every required size across both platforms, the screenshot sizes reference guide has current specifications.

Google Play requires a minimum of 4 screenshots per listing, with 6-8 recommended for better conversion. Format: PNG or JPEG, RGB color space, no transparency, maximum 10 MB per file.

Beyond dimensions, the screenshots themselves need to perform as marketing assets. Your first two screenshots determine whether users explore or bounce. Each frame should communicate a single value proposition. And visual consistency across the full set matters more than any individual frame's creativity. Mismatched colors, alternating fonts, or switching between light and dark mode reads as unfinished, even when the app beneath is polished. The top-charting apps analysis breaks down exactly which screenshot patterns correlate with higher conversion.

If this sounds like a design project on top of a development project, that's because it traditionally has been. AppScreenshotStudio generates a complete, consistent screenshot set from a description of your app. No design tools, no templates, no creative decisions required.

App icon checklist:

• 1024 x 1024 px, no transparency, no rounded corners (Apple applies the mask automatically)
• Test it rendered on both light and dark backgrounds
• Check legibility at small sizes (29 x 29 px in iOS Settings)
• The app icon design guide covers strategy and common mistakes

4. One Week Out: Metadata and ASO

Screenshots get attention. Metadata gets search traffic. Both matter for launch.

App name: 30 characters on iOS, 50 on Google Play. Place your highest-value keyword alongside the app name itself. "Tempo: Workout Tracker" beats "Tempo" alone.

Subtitle (iOS) / Short description (Android): 30 characters and 80 characters respectively. Lead with the primary benefit. "Track workouts. Build habits." beats "AI-powered fitness tracking platform."

Keywords field (iOS only): You get exactly 100 characters. Comma-separated, no spaces after commas. Don't repeat words that already appear in your title or subtitle because Apple indexes those automatically. Target long-tail keywords with lower competition. Broad terms like "fitness" won't rank for a new app. "Bodyweight workout log" might. The ranking factors guide covers which ASO signals carry the most weight for indie apps.

Description: iOS descriptions aren't indexed for keyword search, so optimize them for conversion (humans reading). Google Play descriptions are indexed, so maintain natural keyword density around 2-3% without stuffing.

Category selection: Pick the category where your app genuinely belongs, not the one with less competition. Apple's review team rejects apps placed in obviously wrong categories.

Release notes: For your initial release, describe what the app does and why someone would want it. Save the changelog format for updates.

5. Submission Day: iOS and Android Side by Side

The two stores handle submissions differently enough to trip you up when doing both simultaneously.

Before you submit:

• Write thorough review notes for Apple. Tell the reviewer exactly how to test your app. Provide login credentials if needed. Specify if features require location services, Bluetooth, or camera access. Roughly 14% of Apple rejections fall under "more information needed," and most of those are avoidable with detailed review notes.
• Complete the content rating questionnaire on both stores. Be accurate about violence, language, and user-generated content. Incorrect ratings trigger rejections.
• Complete the age rating questionnaire on Apple. Updated in January 2026, this is required before submission. [3]
• Choose your release timing. Apple lets you select manual release (you control when the approved build goes live) or automatic. If you're coordinating an iOS and Android launch on the same day, use manual release on Apple so you can sync both.

6. Launch Week: The First Seven Days

Your app is live. The work shifts from building to responding.

Don't launch on Friday. Tuesday or Wednesday gives you the full workweek to address crashes, respond to reviews, and iterate on metadata before the weekend.

Days 1-2: Watch crash rates. Target 99% crash-free sessions from the start. If you're below that threshold, fix crashes before investing in any marketing. A one-star "keeps crashing" review in your first week is almost impossible to outrun with later fixes.

Days 3-4: Respond to every review. The first ten reviews set the tone for your listing. A thoughtful reply to a three-star review can prompt the user to update it. Silence won't.

Days 5-7: Check search impressions. In App Store Connect Analytics, look at which keywords drive impressions and taps. In Google Play Console, check your acquisition reports. If your primary target keyword isn't generating impressions, adjust your metadata now. Don't wait a month to iterate.

Week 2 onward:

• Test a different screenshot order or a revised first-frame headline
• Update your subtitle or short description based on real impression data
• Consider localizing your listing for your top non-English markets (even metadata-only localization, without translating the app itself, can meaningfully expand your audience)

7. The Compressed Checklist

For quick reference:

30 days before:

• Register Apple Developer ($99/yr) and Google Play ($25 one-time)
• Start Google Play closed test (12 testers, 14 consecutive days)
• Generate iOS certificates and provisioning profiles
• Integrate crash reporting and analytics

14 days before:

• Test on real devices running latest OS
• Audit all third-party SDK privacy manifests
• Implement "Delete Account" (if app has user accounts)
• Verify privacy policy URL in incognito browser
• Test empty states and prepare demo credentials for Apple review

7 days before:

• Create screenshots for all required device sizes
• Finalize app icon (1024x1024, test at small sizes and on dark backgrounds)
• Write title, subtitle, keywords, and description
• Complete content and age rating questionnaires

Submission day:

• Upload builds via Xcode and Play Console
• Write detailed review notes (Apple)
• Set release type (manual vs. automatic)
• Submit and monitor for rejection notices

Launch week:

• Monitor crash rates (target 99%+ crash-free)
• Respond to every review
• Check keyword impression data
• Plan your first metadata iteration

Shipping Is the Hard Part

Most indie apps don't fail because the code is bad. They fail because the developer hit a wall somewhere between "the app works on my phone" and "the app is live in the store." An expired provisioning profile. A privacy policy link that 404'd. A Google Play account that couldn't access production because the closed test hadn't run long enough.

Every item on this checklist exists because it has blocked a real submission. Follow it start to finish, beginning four weeks before your target launch date, and you avoid the rejection triggers that catch most first-time developers.

The one item that still stops solo developers cold is screenshots. It doesn't need to. AppScreenshotStudio generates a finished, App Store-compliant screenshot set from a description of your app. No design tools, no templates, no creative decisions. Just the screenshots, ready to upload.