September 5th, 2026 at 10:40 am
Last updated: September 2026 Author: Ronak shah, Nordstone — app development consultancy
Launching an app means registering an Apple Developer and Google Play Console account, preparing store listing assets and privacy disclosures, submitting your build for review, and going live once approved. Apple’s review typically takes 24–48 hours; Google Play is usually faster but requires new accounts to complete a mandatory closed test first.
TL;DR
- Accounts & fees: Apple Developer Program is $99/year; Google Play Console is a one-time $25 fee. Both are required before you can submit.
- Assets you need: app icon, screenshots per device size, a written description, a privacy policy URL, a support URL and a content/age rating questionnaire.
- Apple submission + review: builds go through App Store Connect and App Review, which averages 24–48 hours for a clean submission but can take longer for finance, health or kids’ apps.
- Google submission + testing: new personal Play Console accounts must run a closed test with at least 12 opted-in testers for 14 continuous days before they can apply for production access.
- Common rejections: crashes, missing or inaccurate privacy policies, no in-app account deletion, mismatched screenshots, and payment-flow violations.
- UK privacy disclosures: you need a UK GDPR-compliant privacy policy, Apple’s privacy “nutrition label”, Google Play’s Data safety section, and — if your app might be accessed by under-18s — consideration of the ICO’s Children’s code.
What does launching an app actually involve?
Launching isn’t a single event — it’s a sequence of administrative, creative and review steps that typically run in parallel across both platforms. Realistically, budget 2–4 weeks from “app is built” to “app is live” for a straightforward, policy-compliant app on iOS, and slightly longer on Android if you’re a new Google Play developer working through the mandatory testing period. The sequence is broadly: register your developer accounts, prepare your store listing assets and legal disclosures, build and upload your release, complete platform-specific testing or review, then publish. Regulated categories — finance, health, and anything likely to be used by children — tend to take longer on both platforms because they’re routed to more thorough review.
Before you submit: accounts, assets and policies
Before either store will accept a submission, you need an active developer account on that platform, a complete set of store listing assets, a live privacy policy, and — where relevant — a content rating for your app.
Apple Developer account & fee
The Apple Developer Program costs $99 (USD) per year for an individual or organisation account, renewing annually, and covers unlimited app submissions and updates under that account. It also gives you access to App Store Connect, Test Flight (for internal and external beta testing), certificates and provisioning profiles. There’s no separate per-app fee — one membership covers everything you publish. Apple typically verifies identity and, for organisation accounts, your company’s legal registration, which can take a few days, so it’s worth starting this step early rather than leaving it until the build is ready.
Google Play Console account & fee
Google Play charges a one-time $25 registration fee for a Play Console account, with no annual renewal. The bigger consideration for new developers is Google’s closed-testing requirement: personal developer accounts created after 13 November 2023 must run a closed test with at least 12 real, opted-in testers who stay opted in continuously for 14 days before Google will grant production access. Testers who opt out and back in reset that continuous window, so it’s worth recruiting slightly more than 12 to allow for drop-off. This requirement doesn’t apply to organisation (business-verified) Play Console accounts, which is one reason many agencies and studios register as an organisation from the outset.
Store listing assets (icons, screenshots, description)
Both stores require a finished icon at the correct resolution, a set of screenshots sized for each supported device (phone and, where relevant, tablet), a short and long description, keywords, a support URL, and a marketing/promotional text field. Get these details wrong — blurry screenshots, placeholder text, a description that doesn’t match what the app actually does — and you risk a rejection that has nothing to do with your code. Both platforms also require you to complete a content/age rating questionnaire (Apple’s age rating system and Google’s IARC-based rating), which determines how your app is labelled to users and, in some markets, restricts distribution outright if answered inaccurately.
Publishing on the Apple App Store
Once your Apple Developer account is active, the process runs through App Store Connect: create your app record, complete the store listing and age rating, upload your build via Xcode or Transporter, and submit for review. Apple states that most submissions are reviewed within 24 hours, historically around 90% in under a day, though third-party trackers report more variance in 2026 as submission volumes have climbed sharply. Regulated or child-directed categories — Finance, Kids and Health in particular — are routed to senior reviewers and often require licensing or compliance evidence, which adds days rather than hours. If Apple rejects your build, you’ll get a specific guideline reference and a description of the issue; fixing and resubmitting puts you back in the review queue, so a single avoidable rejection can easily add several days to your timeline, and two rejections can add a week or more.
Publishing on Google Play
In Play Console, you create your app, complete the store listing, Data safety section and content rating, then upload your release to a testing track before it can go to production. For accounts created after November 2023, that testing track must be a closed test meeting the 12-tester, 14-day rule described above — this is not optional, and there’s no way to bypass it for a personal account. Once the testing period is complete, you apply for production access through the Play Console dashboard, answering questions about your app’s design, testing process and readiness. Google’s own review of production releases is typically faster than Apple’s, often completing within a few hours to a few days, but the 14-day testing clock is usually the longer pole in the tent for first-time Android publishers.
Common reasons apps get rejected — and how to avoid them
Most rejections on both platforms are preventable with preparation rather than a sign of an unreasonable reviewer. On Apple, crashes and bugs top the list — reviewers test your core user flows manually, and any crash or unresponsive screen triggers an immediate rejection, so a thorough pass on the exact build you’re submitting matters more than testing an earlier version. A missing, inaccessible or inaccurate privacy policy is the next most common cause, closely followed by the absence of an in-app account-deletion flow — required since 2022, and specifically tested for, with an email-based workaround no longer accepted. Screenshots or metadata that don’t match the actual app, broken login or checkout flows, and payment flows that bypass Apple’s or Google’s own in-app purchase systems (routing users to external payment links) round out the biggest categories. A useful habit before every submission: test the exact build you’re uploading end-to-end, re-read your privacy policy against what the app actually collects, and confirm every third-party SDK you use ships an up-to-date privacy manifest — outdated or undisclosed SDK tracking is an increasingly common, and entirely avoidable, rejection trigger.
| Rejection trigger | Which platform | How to avoid it |
| Crashes or broken core flows | Both | Test the exact submitted build end-to-end before uploading |
| Missing/inaccurate privacy policy | Both | Publish a live, accurate policy URL matching actual data use |
| No in-app account deletion | Apple (Guideline 5.1.1(v)) | Add a visible, functional in-app “Delete account” option |
| Screenshots/description mismatch | Both | Update listing assets every time the app’s features change |
| Payment flow bypasses store billing | Both | Route all digital purchases through StoreKit / Play Billing |
| Undisclosed third-party SDK tracking | Apple (privacy manifests) | Audit every SDK’s privacy manifest before each submission |
UK-specific requirements
Every app distributed to UK users needs a privacy policy that meets UK GDPR requirements — written in plain language, easily accessible from within the app and the store listing, and accurately describing what personal data you collect, why, and how long you keep it. Both stores also require their own structured disclosures on top of a general policy: Apple’s privacy “nutrition label” in App Store Connect, and Google Play’s Data safety section, both of which ask you to declare, category by category, what data your app collects and whether it’s shared with third parties — and both stores can reject or later remove an app if the declared label doesn’t match what the binary actually does. If your app is likely to be accessed by under-18s in the UK — which the ICO interprets broadly, not just apps explicitly aimed at children — you should assess it against the ICO’s Children’s code (the Age-Appropriate Design Code), which sets 15 standards covering age-appropriate defaults, data minimisation and profiling. Apps with a PEGI rating of 16 or lower generally need to conform to the code; higher-rated apps need robust age assurance to keep under-18s out rather than code conformance for them.
Launch-day and post-launch checklist
- Confirm your build is live in both App Store Connect and Play Console, and spot-check the listing on a real device in each store, not just the dashboard preview.
- Verify your privacy policy URL, support URL and any in-app legal links resolve correctly from the published listing.
- Check your app’s category, age rating and pricing display correctly for UK users specifically, not just your default market.
- Set up crash reporting and basic analytics before go-live if you haven’t already, so day-one issues surface immediately rather than via user reviews.
- Monitor early reviews and ratings closely in the first 48–72 hours; a fast response to a legitimate bug report can prevent a pile-on of low ratings.
- Plan your first update cycle — Apple and Google both reward apps that ship regular, policy-compliant updates with better visibility than apps that go quiet after launch.
- Keep your closed-test group (Android) or TestFlight group (iOS) active after launch; you’ll want it again for your next release.
Frequently asked questions
How long does it take to get an app approved?
How much does it cost to publish an app?
Why do apps get rejected from the App Store?
Do I need a privacy policy to launch an app?
What are Google Play's testing requirements?
Can I launch on one platform first?
What do I need to disclose about data under UK GDPR?
What should I do on launch day?
Talk to us about launching your app
If you’d like help getting your app through App Store and Google Play review first time — from store listing assets to privacy disclosures and the technical submission itself — get in touch with Nordstone for a free launch-readiness conversation.