# Launch a mobile app on the App Store and Google Play > Developer accounts, listing assets, privacy declarations, a review-proof build, and a staged rollout — the paperwork and order that stop a launch from being rejected the week it matters. - **Section:** Launch & marketing · **Region:** Global · **Difficulty:** medium - **Time:** 2–3 weeks before launch day; review 1–3 days (Apple), hours to days (Google) - **Cost:** Apple Developer Program $99/year · Google Play one-time $25 - **You end up with:** A live listing on both stores with a staged rollout, analytics, and a review-response routine - **Last reviewed:** 2026-09-05 · **Canonical:** https://for.do/p/app-store-launch/ ## Before you start - A finished build that passes on real devices, with crash reporting wired in - A privacy policy URL and a support URL that exist today An app launch fails on paperwork more often than on code: accounts not enrolled in time, privacy forms that contradict the binary, a reviewer who cannot log in. The steps below put the slow, external dependencies first so the build is the last thing you are waiting on. ## 1. Enrol the developer accounts early - [ ] Apple Developer Program ($99/year): individual is quick; an organisation needs a D-U-N-S number and can take a week or more. - [ ] Google Play Console ($25 once): complete identity verification; note that new personal accounts must run a 14-day closed test with at least 12 testers before they can publish to production. - [ ] Set up App Store Connect and Play Console users, tax and banking forms if you will charge. ## 2. Prepare the listing - [ ] Name (30 characters on Apple), subtitle/short description, keyword field (Apple) and full description with the key terms users search for. - [ ] Screenshots for each required device size, with a benefit caption on each; an app preview video is optional. - [ ] Icon at every required size; category; age rating questionnaire; support URL and privacy policy URL that work. ## 3. Privacy and compliance forms - [ ] Inventory what the app and every SDK collects (analytics, crash reporting, ads, auth). - [ ] Fill Apple's App Privacy questions and Google's Data safety form from that inventory, identically. - [ ] If you sell digital goods or subscriptions, use in-app purchase / Play Billing; reviewers check. ## 4. Make the build review-proof - [ ] Test on real devices, including the oldest OS version you support; fix every crash in crash reporting. - [ ] Remove debug menus, test flags and placeholder text; make sure all links resolve. - [ ] Write review notes with a demo account, the steps to reach gated features, and any hardware the reviewer needs. ## 5. Submit and stage the rollout - [ ] Apple: upload with Xcode or Transporter, complete the version page, choose phased release for automatic updates, submit. - [ ] Google: internal test → closed test (required 14 days for new personal accounts) → production with a staged rollout starting at 5–10%. - [ ] Watch crash-free rate and reviews for 48 hours; halt the rollout if a crash spikes. ## 6. Launch day and after - [ ] Coordinate the public launch (site, social, Product Hunt) for when both listings are live. - [ ] Reply to every review in the first weeks; prompt for ratings in-app only after a positive moment. - [ ] Track installs, conversion from listing views, retention at day 1/7/30, and iterate the screenshots and description with that data. ## Where people get this wrong - Registering the developer accounts the week of launch. Apple's enrolment can take days (an organisation needs a D-U-N-S number); Google's new-account verification and a 14-day closed test for personal accounts can add weeks. - Guessing the privacy declarations. Apple's privacy nutrition labels and Google's Data safety form must match what the app and its SDKs actually collect; mismatches are a rejection and a policy strike. - Submitting a build with placeholder content, broken links or a login-only demo. Provide a demo account in the review notes; reviewers do not create accounts. - Full rollout on day one. A staged rollout (Google) and phased release (Apple) let you halt at 5–10% when the first crash report arrives. ## Questions **How long does review take?** Apple: typically 24–48 hours, longer for a first submission. Google: from hours to several days, and new personal accounts must run a closed test with testers for 14 days before production access. **What are the common rejection reasons?** Crashes or bugs, incomplete information (no demo login), privacy declarations that do not match, guideline issues around payments (in-app purchase rules), and metadata that misleads. **Do I need both stores at once?** No. Launch where your first users are, learn from the reviews, then launch the other with the fixes. ## Tools used - [App Store Connect](https://find.do/t/app-store-connect/) (official) — Apple's console for submitting and managing iOS apps. - [Google Play Console](https://find.do/t/google-play-console/) (official) — Google's console for publishing Android apps. ## Sources - [Apple — App Store Review Guidelines](https://developer.apple.com/app-store/review/guidelines/) - [Google Play Console Help — Prepare your app for review](https://support.google.com/googleplay/android-developer/answer/9859455) - [Apple — App privacy details on the App Store](https://developer.apple.com/app-store/app-privacy-details/)