How Long Does It Take to Build a Mobile App?
How long does it take to build a mobile app? For a focused MVP — one core workflow, accounts, a real database, push notifications, one Flutter codebase on both stores — budget about 4–8 weeks of engineering, and a fuller product app with payments, offline sync, and an admin backend somewhere between two and four months. But the number founders actually need is not the build time; it is the calendar time, and on mobile those are different in a way they never are on the web. A web app is live the moment you deploy it. A mobile app then has to get through the stores. Apple states that 90% of submissions are reviewed in under 24 hours, which is genuinely fast. Google publishes no guaranteed turnaround and warns that some reviews take 7 days or longer. And the one that blindsides people: a personal Google Play developer account created after 13 November 2023 must run a closed test with at least 12 testers, opted in continuously for 14 days, before it can even apply for production access. That single rule can add a fortnight to a launch that was otherwise ready — and it is invisible until you go looking for it. This guide maps the real timeline, gate by gate.
Key takeaways
- A focused mobile MVP is roughly 4–8 weeks of build; a fuller product app is two to four months. The calendar, though, is longer than the build.
- Apple reviews 90% of submissions in under 24 hours. Google publishes no guaranteed turnaround and warns of 7 days or longer.
- The hidden fortnight: a personal Play account created after 13 Nov 2023 needs 12 testers opted in for 14 continuous days before production access. Organisation accounts are not covered — register the right account type on day one.
- The last 10% runs long because release builds behave differently from debug builds, and because the store paperwork (privacy details, data safety, screenshots, signing) is real work nobody estimates.
- You cannot compress a review queue. You can compress everything else: one codebase, one workflow, accounts registered on day one, and the closed test started before the app is finished.
What does the build time actually go on?
The screens are the fast part. What takes the weeks is everything that happens around them: the data model, what the app does when the network drops, what happens when the OS kills the process, and how state gets from a server to a device and back without ever losing a user’s work.
Here is what a realistic six-week MVP calendar looks like. It is deliberately front-loaded with the two things that cause the most re-work when they are rushed — the data model and the core flows.
Why is the calendar longer than the build?
Because shipping a mobile app is not deploying it. It is submitting it — to two companies with their own queues, rules, and paperwork, neither of which is interested in your launch date.
Three gates sit between “the app is finished” and “people can download it”, and only one of them is fast. They are not negotiable, but they are entirely predictable — which means the whole cost of them is avoidable by scheduling rather than by hurrying.
- Apple review is genuinely quick: Apple’s own figure is that 90% of submissions are reviewed in under 24 hours. A rejection, though, costs you a round trip — and by Apple’s account, over 40% of unresolved issues relate to Guideline 2.1, App Completeness: crashes, placeholder content, and incomplete information.
- Google Play review is slower and far less predictable. Google publishes no guaranteed turnaround and explicitly warns that some apps face extended reviews of 7 days or longer, with new developer accounts getting more scrutiny.
- Google’s closed-testing requirement applies to personal Play accounts created after 13 November 2023: at least 12 testers, opted in for 14 continuous days, before you can apply for production access. Testers who opt out early do not count, so a mistake here restarts the clock. Organisation accounts are not covered by this rule — which makes the account type you register one of the highest-leverage decisions in the whole project.
- Account verification itself takes time: enrolling with Apple as an organisation requires a D-U-N-S number, and obtaining one takes days you will not get back. This is why the accounts are a week-zero task, not a launch-week task.
The 14-day rule is the single most common launch-date killer
It catches founders who registered a personal Play account to “get started quickly”, finished the app, and only then discovered they needed 12 real testers opted in continuously for two weeks. Nothing about the app is wrong. The account was. Register the right account type on day one — it is the cheapest fortnight you will ever save.
Why does the last 10% take longer than everyone expects?
Because it is the first time you are testing the thing you are actually going to ship. On Android, the release build is minified and the debug build is not — so an entire class of bugs simply does not exist until you build for release, and then they all arrive at once, usually in code that relies on reflection. A crash that never appeared in three weeks of development can appear in the first release build, on the day you planned to submit.
The store paperwork is real work too, and it is nobody’s favourite week. Apple’s App Privacy details are required to submit, Google’s Data Safety form is mandatory for every app on every track, and both must account for what your third-party SDKs collect — not just your own code. Add screenshots for several device sizes, a privacy policy, store descriptions, and signing keys, and you have a genuine few days of work that no one ever puts in an estimate.
The fix is not to work faster. It is to move all of it earlier: build release artefacts and test on real devices from week one, and fill in the store paperwork while the app is still being built rather than while it is waiting to be submitted.
- Test the release build, on real devices, from the first week — not the last.
- Ship to an internal testing track early and often; treat the first store upload as a week-two milestone, not a week-six ceremony.
- Do the privacy and data-safety forms alongside the build, while you still remember which SDK collects what.
- Remember that Play version codes are permanent and monotonic: once a build has gone to any track that number is spent forever, and a production release should promote the exact bundle you tested rather than rebuild it.
What makes an app take six months instead of six weeks?
Almost never the technology. The projects that stretch are the ones where the scope was never really agreed, or where the hard parts were left until the end.
These four account for most of the overruns we see — and each of them is a decision, not an accident.
- Scope that grows during the build — the single largest cause, on mobile and everywhere else. A fixed written scope is what makes a confident date possible: see fixed-price vs hourly and why software projects fail.
- Offline-first sync, discovered late. Retro-fitting conflict resolution into an app that assumed a network is close to a rewrite of the data layer. Decide it in week one, or accept that it is not in v1.
- Real-time and background work. Calls, live location, and scheduled sync each fight a different battle with each operating system’s power management. They are weeks, not days, and they are where mobile estimates most often go wrong.
- No decisions. An app waiting on feedback is not being built. The fastest projects we run are the ones where someone answers questions the same day.
How do you compress the timeline honestly?
You cannot compress Google’s review queue and you cannot compress 14 continuous days of closed testing. What you can compress is everything you control — and the biggest lever is not working faster but building the app once instead of twice.
One codebase means one implementation, one QA pass, and one bug backlog rather than two of each; whether that is right for your product is the subject of cross-platform vs native. Beyond that, the levers are all about sequencing — and about the cost of each week, which is priced out in what a mobile app really costs.
- Register both developer accounts on day one — the right account type, before anything else happens.
- Build one codebase rather than two, unless a platform-specific capability genuinely demands otherwise.
- Cut the v1 to one workflow that delivers real value. The discipline in what a v1 should include transfers to mobile unchanged.
- Start the Play closed test as soon as you have something installable — not when the app is finished. Those 14 days can run in parallel with your final build week.
- Use a managed backend rather than building authentication, storage, and a database from scratch.
- Budget for one store rejection. Planning for a clean first submission is optimism, not a schedule.
Frequently asked questions
How long does the App Store review take?
Apple states that, on average, 90% of submissions are reviewed in under 24 hours. That is a review of the binary you submitted, though — a rejection means fixing the issue and re-submitting, which costs another cycle. Most rejections are avoidable: Apple reports that over 40% of unresolved issues relate to Guideline 2.1, App Completeness — crashes, placeholder content, and incomplete information.
How long does Google Play review take?
Google publishes no guaranteed turnaround and warns that some apps are subject to extended reviews taking 7 days or longer, with new developer accounts reviewed more thoroughly. Plan for a week and be pleased if it is faster — and never schedule a launch event around an unreviewed Play submission.
What is the 12-testers, 14-day Google Play rule?
Personal Google Play developer accounts created after 13 November 2023 must run a closed test with a minimum of 12 testers who have been opted in continuously for at least 14 days before they can apply for production access. Testers who opt in and then leave early do not count. Organisation accounts are not covered by this requirement — which is why the account type you register on day one can decide whether your launch slips by a fortnight.
Can I launch an app in two weeks?
Only if the app is genuinely tiny, the developer accounts already exist and are verified, and you are on an account type not subject to the closed-testing requirement. It is possible, but it is a statement about scope, not about speed. For most products a rushed two-week build simply moves the missing weeks into the months after launch.
Does building for both platforms take twice as long?
Not with one codebase. The app is built once and the second platform costs a fraction — mostly device testing, store setup, and review. With two native codebases it genuinely does approach twice the work, which is the single biggest reason the cross-platform default exists.
How long does it take to update an app after launch?
The engineering takes as long as the change, but every update still passes through review — so a same-day hotfix is realistic on iOS and optimistic on Android. This is a structural difference from the web, where you deploy a fix in minutes, and it is worth designing for: use feature flags and remote config so you can turn a broken feature off without shipping a new binary.
Have a project in mind?
We design, build, and ship software end-to-end — with a fixed, written quote after a free scoping call.