How Long Does a Dual-Store App Launch Actually Take

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: A UK seed-stage founder who has verbally committed a launch date to investors and is now briefing dev partners, without realising that Apple's review queue and their own delayed content decisions will consume more calendar time than the build itself.

Plan for six weeks between code-complete and a live listing on both stores, not two. The build is almost never the critical path for a first-time dual-store launch: Apple's initial review on a fresh developer account can sit in the queue for 14 days or longer right now, Google Play requires a mandatory 14-day closed test with 12 opt-in testers before you can even submit for production, and a single rejection on privacy or age-rating grounds restarts the Apple clock. If you have told investors a date, read the rest of this before you brief the dev partner.

This is the piece most seed-stage founders in the UK get wrong when they draw up a mobile app development timeline. The engineering estimate is a build estimate. The launch estimate is a build estimate plus store choreography plus legal paperwork plus a queue you do not control. The three things compound.

The actual phases of a dual-store launch

Here is how the elapsed calendar usually breaks down for a straightforward consumer or SaaS app — not a game, not a regulated fintech, not a health app with HIPAA scope. Treat the ranges as shape, not quote.

Phase 1 — Discovery and scoping (1–3 weeks, vendor-led, client-dependent)

Wireframes, acceptance criteria, data model, third-party service list, identity provider decisions, analytics stack. The client-side gating item is almost always sign-off: who at your company has the authority to approve the spec, and how often are they available. A founder who reviews builds in the evening between fundraising calls will add a week here without noticing.

Phase 2 — Integration access and accounts (parallel, 1–4 weeks, almost entirely client-dependent)

This is the phase that silently wrecks timelines. You need, before any store submission is possible:

• An Apple Developer Program enrolment (£79/year, 24–48 hours for an individual, often 1–2 weeks for a company because Apple verifies D-U-N-S number and legal entity details)
• A Google Play Console account ($25 one-time) and, for any account created after 13 November 2023, a completed 14-day closed test with a minimum of 12 continuous opt-in testers before you can push to production (Google Play policy, via superapp.dev)
• Payment processor merchant account (Stripe, Adyen, or RevenueCat for subscriptions)
• Push notification credentials (APNs key, FCM project)
• Analytics and crash reporting SDKs provisioned
• Any third-party API keys — maps, auth, KYC, payments — with production tier access, not sandbox

If your dev partner cannot start Google Play closed testing in week one of the build, you are already two weeks behind on launch.

Phase 3 — First usable slice (3–6 weeks, vendor-led)

A testable build on TestFlight and Google Play internal track covering the primary user journey end-to-end. This is the slice the founder and three advisors actually use on their phones. Nothing about this phase is unusual; it is the one everyone plans for correctly.

Phase 4 — Hardening, store assets, and legal (2–4 weeks, mostly client-dependent)

This is the second phase that silently wrecks timelines, and it runs in parallel with the end of phase 3 if you are organised. Required before submission:

• App Privacy details (Apple's "nutrition labels") — a line-item declaration of every data type collected, who it goes to, and why
• A published privacy policy URL that reflects reality — not a template. Under UK GDPR, a privacy notice is a legal requirement for any app processing personal data, and Apple blocks submission without a URL that resolves (ICO guidance via Mincoffs)
• Age rating questionnaire — honest answers; health, finance, and user-generated content categories get extra scrutiny
• Screenshots at required device sizes (6.9", 6.5", 5.5" for iPhone; 7" and 10" for tablet if you support them)
• App preview video if you want one (optional, adds a week if you do)
• Localised metadata if you target more than en-GB
• Export compliance declaration (almost every app uses HTTPS, which technically triggers this)

Most of this list is the founder's job or the founder's lawyer's job. A dev partner can draft the App Privacy declaration from the SDK list, but they cannot write your privacy policy or decide your age rating for you.

Phase 5 — Store submission and review (1–6 weeks, entirely out of your control)

Here is where founders who have run a fast, clean build get ambushed. Current state of the queue, as of early 2026:

• Apple's stated target is 24–48 hours for most submissions. Reality for a new developer account is 3–7 days at the typical end, with developer community reports of 14–45 days in "Waiting for Review" through late 2025 and early 2026 (ezscreenshots.com)
• iOS new app submissions rose 54.8% year-over-year in January 2026 and 56% in December 2025 per Sensor Tower, attributed largely to AI-generated app floods, which has materially lengthened the queue (Yahoo Finance / Appfigures)
• Apple rejected 2,093,244 of 9,100,620 submissions in 2025 — roughly 23%. Of those rejected, 387,087 were eventually approved after resubmission (Apple 2025 Transparency Report via haploapp.com)
• Legal violations — which include privacy and data-collection failures — were the second-largest rejection category in 2024 at 445,696 rejections (Apple 2024 Transparency Report via appknox.com)

Each rejection restarts the queue. A rejection on day 10 of a 14-day wait does not get expedited back to the front; you fix, resubmit, and wait again. Two rejection cycles is a month of elapsed calendar on Apple alone.

Google Play is faster once you clear the 14-day closed test gate: production review is typically 1–7 days, occasionally longer for first-time publishers or sensitive permissions (location, SMS, accessibility).

An illustrative worked example

Illustrative only. A seed-stage consumer app with email/password auth, Stripe subscriptions, two third-party integrations, no existing data to migrate, a founder who approves specs same-day, and no regulated-category concerns (not health, not credit, not under-13):

• Discovery: 2 weeks
• Accounts and integration access: starts week 1, done by week 3 — assumes Google Play closed testing kicks off in week 1
• Build to first usable slice: weeks 3–8
• Hardening, store assets, privacy policy: weeks 7–10 (overlapping)
• Apple first review (new developer account): submit end of week 10, expect decision week 11–12
• One rejection cycle budgeted: resubmit week 12, decision week 13
• Google Play production review: submit end of week 10, live week 11

Elapsed: around 13 weeks from kickoff to both stores live. The build itself is six weeks of that. Everything else is choreography, queues, and paperwork. If you skip the rejection buffer and Apple approves clean, you shave two weeks. If you hit two rejections and your privacy policy needs lawyer revisions, you add three.

The three things that most often add weeks

1. The privacy policy gets drafted after the build

Early signal: no one on the project has been named as the owner of the privacy policy by end of week 2. If your dev partner is asking what data you collect in week 8, you have already lost time. Draft the data inventory in week 1 — what you collect, who you share it with, retention periods, lawful basis under UK GDPR. A solicitor should review the final text; this is a legal document and a dev agency cannot write it for you. Building the inventory early also means your App Privacy nutrition labels are a copy-paste exercise, not a scramble.

2. The Apple developer account was opened the week of submission

Early signal: at kickoff, the founder says "we'll sort the developer account later." Open it in week 1. For a limited company, Apple's D-U-N-S verification and legal entity check can take 10–14 business days on its own. You cannot submit without it. You cannot even configure TestFlight distribution without it. The cost is £79/year and the form takes an hour; there is no reason to defer it.

3. The age rating or category triggers extra review

Early signal: the app does anything involving health data, financial advice, user-generated content, dating, crypto, or users under 13. Apple's human reviewers scrutinise these harder and reject more often. If you are building in one of these categories — a health app in the vein of what we've done with HealthPotli, or a lending product like Cashpo — budget a second rejection cycle by default and get specialist review on your submission notes before you click submit. The reviewer notes field is underused; a clear explanation of what the app does, who it is for, and how sensitive features work reduces rejections more than any amount of polish.

What you can do in week zero to shorten the whole thing

Before the dev partner writes a line of code:

• Open both store accounts. Apple Developer Program and Google Play Console. Do this today, not next month. Google Play's 14-day closed testing clock cannot start until the account exists and a build is uploaded.
• Name a privacy policy owner. Either you, your COO, or an external solicitor. Give them the data inventory by end of week 1. Target a published URL by week 4, not week 10.
• Recruit your 12 Google Play testers now. They need to be opted in continuously for 14 days. Friends, advisors, beta list — get the emails collected and the Google Groups set up before build starts.
• Decide your age rating honestly, then write the reviewer notes. If you are 17+, say so. If your app has user-generated content, describe the moderation. Under-declaration is the fastest route to rejection.
• Set the investor expectation at 13 weeks with a two-week buffer, not 8. Under-promising a launch date is cheap; missing one in front of a board is not.

If you are weighing dev partners, the question to ask them is not "how fast can you build it" — any competent shop will quote roughly the same build weeks. Ask "what's on your week-one checklist that isn't code," and see whether store accounts, privacy inventory, and the Google Play testing cohort are on it. If they are not, you are hiring a builder, not a launcher. CodeNicely's offerings and startup engagements are structured around exactly this choreography, but the point stands regardless of who you hire: the question is whether the first week of the project is set up to protect the launch date.

Frequently Asked Questions

How long does App Store approval take for a UK startup in 2026?

Apple's published target is 24–48 hours, but current reality for a new developer account is 3–7 days typical, with community-reported waits of 14–45 days through late 2025 and early 2026 driven by a 24%+ surge in submissions (Appfigures / Yahoo Finance). Google Play production review is typically 1–7 days, but a personal account created after November 2023 must first complete a mandatory 14-day closed test with 12 opt-in testers before you can submit at all.

What is the biggest hidden delay in a mobile app launch timeline?

The privacy policy and App Privacy nutrition labels. Under UK GDPR, a privacy notice is a legal requirement, and Apple will not approve an app without a working privacy policy URL. Founders who leave this to week 10 often find their solicitor needs two weeks to review and their nutrition labels need rewriting — adding three weeks on the critical path, right at submission.

Why do App Store rejections restart the clock?

Apple's review queue is FIFO. When a reviewer rejects a submission, the resubmission goes back into the queue, not to the front. In a two-week queue, two rejection cycles is a month of elapsed calendar. Apple rejected ~23% of submissions in 2025, and legal/privacy violations were the second-largest category (Apple 2025 Transparency Report), so budget at least one rejection cycle into your plan.

How long does it take to build and launch a mobile app end-to-end?

The shape of the number for a straightforward consumer or SaaS app with no regulated-category complications is around 12–16 weeks from kickoff to both stores live, of which 5–7 weeks is the build itself and the rest is discovery, store choreography, legal paperwork, and review queues. Regulated apps — health, lending, dating, under-13 — add 3–6 weeks. The three specifics that turn this range into a real number for your situation are: category and regulatory scope, number of third-party integrations, and whether you already hold the Apple and Google developer accounts. A scoping conversation with a dev partner is where that gets pinned down.

Can we expedite an App Store review?

Yes, but sparingly. Apple's Expedited Review request is intended for critical bugs affecting live users or time-sensitive events (a sports launch, a legal compliance deadline). First submissions are rarely granted expedited status, and abusing the system flags your account. Plan the realistic queue; treat expedited review as emergency reserve, not a scheduling tool.