The honest answer has two halves, and mixing them is why app schedules slip. The first half is build time, which depends on scope, and which you control. The second half is store time: required testing periods, review queues, and the possibility of being sent back to fix something. You control none of that, and no tool changes it.
This guide gives planning ranges for four build paths, then shows how to turn them into a defensible date by counting work, waiting, and uncertainty separately. It states no review duration as a commitment, because neither store offers one.
QUICK ANSWER
How long does it take to build an app?
As a planning range, allow 1 to 3 weeks for a single-workflow app, 4 to 12 weeks for a real product with accounts and data, and several months for anything with payments, offline behavior, or regulated data. Then add store time on top: a first Android release on a new personal account carries a 14-day minimum closed test, and neither store commits to a review duration.
Fix these five inputs before you name a date
A date without these is a guess wearing a number. Each one moves the range by weeks, and four of the five are decisions rather than work.
- The launch boundary, written down: List the screens and behaviors that must exist on launch day, and a separate list of everything deferred. Then define done: real content, the main flow working on a real phone, accounts and data behaving, the build signed and uploaded, and a check performed on the installed app. A generated first version is not launch-ready and should never be reported as though it were.
- Which stores, and whose accounts: iOS only, Android only, or both, decided now rather than in week six. Each store is a separate submission, a separate review queue, and a separate set of assets. Both accounts must be in your own name, so if you do not have them yet, that setup is on the critical path, not a formality at the end.
- Your Google Play account type and creation date: This one silently adds a fortnight. Google requires personal developer accounts created after 13 November 2023 to run a closed test with at least 12 testers opted in continuously for at least 14 days before applying for production access. If that applies to you, your earliest possible Android launch is two weeks after you have twelve committed testers, no matter how fast the app was built.
- The data and accounts the app really needs: Sign-in, stored records, file uploads, notifications, payments, and offline behavior are each a schedule item, not a checkbox. An app that only displays content is a different project from one that holds user data, and the second one carries testing, privacy, and recovery work the first does not.
- One decision owner and a review cadence: Name the single person who can approve a build and settle conflicting feedback, and agree how quickly they will respond. Two hours a day of a busy founder is not one project day. Convert available attention into workdays before you convert workdays into a date.
Four build paths, and what each one really costs in weeks
These are reasoned planning ranges under the assumptions in this guide, and they describe build time only. Store time is added separately in step four, because it behaves differently and no build path shortens it. A faster tool compresses implementation; it does not approve your content, recruit your testers, or move you up a review queue.
| Approach | Best for | Tradeoff |
|---|---|---|
| AI builder: about 1 to 6 weeks of build time | A first version of a focused app, with one or two user roles, real data, and a founder who can make decisions quickly. | A working version appears in hours, which is exactly what makes the estimate dangerous. The remaining weeks go into correcting real content, handling the states nobody described, testing on actual devices, and preparing store assets. |
| Visual no-code builder: about 3 to 10 weeks of build time | Data-backed apps with a lot of screens, built by someone willing to learn the platform properly. | Assembly is predictable and slow. The time risk is not the building, it is discovering in week five that the platform will not do the one thing your product needs, at which point there is rarely a partial escape. |
| Freelancer or small agency: about 8 to 20 weeks | Products that need design work, a specification, and someone accountable for delivery. | You gain capacity and judgment and you add coordination. Scheduling, proposals, revision rounds, approvals, and handoff routinely make elapsed time twice the hands-on time. |
| Custom development: about 4 to 12 or more months | Payments, complex permissions, offline synchronization, regulated data, hardware integrations, or anything where the technical design is the product. | Full control, and a full software project: requirements, architecture, implementation, security review, device testing, release operations, and someone to own it afterwards. |
Recommended:Choose the least complex path that satisfies the launch boundary, then prove the riskiest thing in it during the first week. The most expensive schedule mistake is not picking a slow path, it is picking a fast path and finding out in week five that it cannot do the one thing the product exists for.
Build a defensible app development timeline
Separate build time from store time, pick a complexity band, count work and waiting apart, prove the risky part first, then test, submit, and keep the schedule honest as it changes.
STEP 01
Split the estimate into build time and store time
Two different clocks with two different owners. Estimating them as one number is the root cause of most missed app launches.
Build time is everything up to a signed binary: design, implementation, content, data, testing on real devices, and store assets. You own it, and scope moves it.
Store time is everything after: required closed testing, the review queue, and any round trip caused by a rejection. You do not own any of it, and no builder, agency, or subscription tier shortens it.
Write them as two lines from the start. When someone asks for the launch date, give both numbers and say which one you control. That single habit prevents the conversation where a two-week build is reported as a two-week launch.
Expected result: The plan has two separate durations, each with a named owner, rather than one blended figure.
Verify it: Ask whoever wants the date which of the two numbers they are hearing. If they cannot tell, the estimate is not yet usable.
STEP 02
Inventory the work, and mark every wait state
Count unique work, missing inputs, and things you are waiting on other people for, in three separate columns.
Create rows for each user role, each main screen, sign-in and account recovery, the data model, file handling, notifications, payments, offline behavior, settings, store assets, and device testing. Estimate a best case and a conservative case for each in workdays.
Mark as a wait state anything you cannot finish alone: store account approval, a D-U-N-S lookup if you are enrolling as a company, tester recruitment, legal or privacy sign-off, third-party API credentials, and review. Wait states go on the calendar even though they consume none of your working hours.
Content is a dependency. An AI builder will draft copy, but your prices, your policies, your permissions text, and your screenshots still need an accountable owner and a date.
Expected result: Every row has an owner, a low and high workday estimate, and a flag saying whether you or someone else controls it.
Verify it: Filter to rows with no owner or an unknown input. If more than a handful remain, the schedule is a wish; resolve them or publish a range with an explicit low confidence.
STEP 03
Pick a complexity band, then adjust it for what you actually found
Start from a band that matches the launch scope, and move within it for the constraints the inventory exposed.
Use 1 to 3 weeks of build time for a single-workflow app: one user role, a handful of screens, sign-in, simple stored records, and no payments. Use 4 to 12 weeks for a real product with several roles, meaningful data, file uploads, notifications, and an admin view.
Use several months for anything with payments, offline synchronization and conflict handling, regulated data, hardware access, or a migration from an existing system. These are not harder screens, they are different categories of work with their own testing and failure handling.
Move toward the high end when content is missing, when more than one person can reopen a decision, when the team has limited weekly attention, or when the app needs both stores at once. Split the release rather than compressing the estimate.
Expected result: One band is selected, the reasons for its position inside that band are written down, and the assumptions are visible next to the number.
Verify it: Take every launch requirement and check it against the band. If any single requirement belongs to a higher category, either raise the band or move that requirement to the deferred list, explicitly.
STEP 04
Add store time, and never present it as a date you control
Model the required testing period and the review queue as separate calendar items with stated uncertainty.
If Google requires a closed test for your account, that is a hard floor of 14 continuous days with at least 12 testers opted in, plus however long it takes to find twelve people who will stay opted in. Start recruiting during the build, not after it.
For review, plan in days and hold the date loosely. Google states that processing an app change can take a few hours or up to seven days, or longer in exceptional cases, and that new developer accounts can be subject to extended review. Apple publishes its own guidance separately; on 2026-08-16 the App Review page did not return a readable figure to an automated fetch, so this guide states no Apple figure rather than repeating one from memory. Read the source yourself before you rely on a number.
Neither store commits to a turnaround, and both can reject a submission and send you round again. Treat the first submission as an attempt, not as a launch. If a launch is tied to an external date, submit with real slack in front of it and use a staged rollout.
Expected result: The calendar carries the required testing period and a review window that is explicitly labelled as outside your control and not a commitment.
Verify it: Read the plan back and check that no sentence promises an approval date or an approval outcome. If one does, rewrite it as a range with the stated uncertainty.
STEP 05
Prove the riskiest part in the first week
Build the one flow that would invalidate the whole estimate, end to end, before scaling anything.
Pick the flow that carries the real risk: usually sign-in plus the single most important thing a user does with their own data. Build it against a real backend with real records, not a mock.
On Playcode, describe the app, the roles, and that main flow, and let it build against a real database and real logins so the state is genuine. Then open it on your own phone and use it as a user would. There is no simulator in this loop by design; a real device is what tells you the truth about layout, input, and speed.
If the pilot exposes a requirement nobody had described, update the inventory and the range now. Repeating an unresolved pattern across twenty screens creates rework, not progress.
Expected result: One complete flow works on a real phone with real stored data, and the remaining unknowns are named.
Verify it: Hand the phone to someone who did not build it and ask them to complete the flow without help. Every place they hesitate is either a design fix or an estimate correction.
STEP 06
Test on real devices before you spend a review cycle
A rejection or a crash found after submission costs a full round trip. Find it before.
Exercise the whole flow on a real phone: sign-in and sign-out, account recovery, permission prompts, an interrupted action, a lost connection, a slow connection, a rotated screen, a small screen, and the largest text size the operating system offers.
Check the states that only appear with real data: an empty list, a very long name, a failed upload, a duplicate submission, and a session that expired while the app was in the background. Confirm no secret, token, or private key is present in anything shipped to the device.
Prepare the store listing while you test, not after. Screenshots, description, category, age rating, privacy answers, and a working account for the reviewer are each a schedule item, and an incomplete listing is one of the most avoidable reasons to be sent back.
Expected result: The release candidate survives a recorded matrix of device, network, permission, and data-state cases, and the store listing is complete before submission.
Verify it: Run the full matrix on at least one real iOS device and one real Android device, and record the result per case. Anything unresolved becomes a fix or an explicitly accepted risk before you submit.
STEP 07
Submit, and plan the release as a staged rollout
Upload the signed build under your own account, then release gradually rather than to everyone at once.
Releasing means uploading a signed binary, an .aab for Android or an .ipa for iOS, to Google Play Console or App Store Connect. From there Apple and Google run review, testing tracks, and rollout. The accounts are yours and you press the final submit yourself.
Use an internal or closed track first on Android, and TestFlight on iOS, so the people who find the first crash are people you know. Then release to a small percentage and widen it as the crash rate stays flat.
Keep the previous build ready. On the day something is wrong, the fastest safe action is usually to halt the rollout rather than to rush a fix through another review cycle.
Expected result: The signed build is uploaded under your own developer accounts, a staged rollout is configured, and a halt path is ready before the first user installs.
Verify it: Install the released build from the store on a device that has never had the app, and complete the main flow end to end as a genuinely new user.
STEP 08
Keep the schedule honest after launch
The first release is the start of a cadence, not the end of a project. Re-estimate when the inputs change.
Name owners for crash reports and store reviews, for the operating-system updates that arrive on their own schedule, for the Apple membership renewal, and for whatever content goes stale.
When scope changes, record the item, its owner, its effect on work days or wait days, and whether the date, the scope, or the capacity absorbs it. Silent additions are how a four-week plan becomes a four-month one without a single visible decision.
Re-estimate when a new role or integration appears, when a pilot disproves an assumption, when a reviewer misses the agreed cadence, or when a store changes a requirement.
Expected result: Every ongoing responsibility has an owner, and every scope change has a visible effect on the plan.
Verify it: Compare this month plan with last month plan. If the date moved and no row explains why, the change log is not being kept.
Test the estimate the same way you test the app
An estimate that only survives the happy path is not an estimate. Run these four before you present a date to anyone who will plan around it.
| Test | Scenario | Expected result |
|---|---|---|
| happy path | Estimate a single-workflow app with one user role, sign-in, stored records, no payments, one decision owner, and existing store accounts. | The worksheet produces a traceable build range inside the 1 to 3 week band, with store time shown separately and labelled as outside your control. |
| invalid input | Someone asks for a fixed launch date while the store accounts do not exist, the tester list is empty, and the payment requirement is undecided. | The plan refuses the fixed date, lists the missing decisions, offers at most a low-confidence conditional range, and names what would have to be true to firm it up. |
| retry | The first submission is rejected and the fix requires a change to the sign-in flow. | Only the affected rows and the review window are re-estimated; approved work stands, the change log records the cause, and the new date shows the second review as a fresh unknown rather than a repeat of the first. |
| production smoke | Install the released build from the store on a device that has never had the app, on a mobile network rather than office wifi. | The app installs, sign-in works, the main flow completes once, data persists after a restart, and no secret or private payload is visible in anything shipped to the device. |
Why app timelines slip, and what each cause tells you
When the date moves, find out whether the cause added work, created rework, reduced capacity, or added waiting. Each one calls for a different response, and treating them alike is why the second estimate is usually wrong too.
| Symptom | Likely cause | Check | Fix |
|---|---|---|---|
| The app worked on day two and is still not launched two months later | The estimate counted generation as completion and omitted real content, real data states, device testing, store assets, required testing periods, and review. | Compare the original estimate line by line against the launch definition and mark every acceptance task that was never in it. | Rebuild the range from the full path to a released build, and from then on report build-ready and launch-ready as two separate dates. |
| The Android launch is blocked and nobody saw it coming | A personal Google Play developer account created after 13 November 2023 requires a closed test with at least 12 testers opted in continuously for at least 14 days before you can apply for production access. | Check the account type and creation date in Play Console, then check how many testers are currently opted in and for how long. | Recruit testers during the build rather than after it, and treat the 14-day period as a fixed calendar item that runs in parallel with your remaining work. |
| The submission was rejected for something that has nothing to do with the code | An incomplete store listing, missing privacy answers, no working account for the reviewer, or a description that promises something the app does not do. | Read the rejection against the store guidelines and separate the content problems from the functional ones. Most first rejections are content. | Prepare the full listing before submitting, provide reviewer credentials for anything behind a login, and treat the first submission as an attempt with a round trip budgeted. |
| Every review round reopens work that was already approved | There is no single decision owner, or feedback arrives separately from several people who disagree with each other. | Compare feedback across rounds and count the decisions that were reversed rather than refined. | One decision owner, one consolidated review window, and a change log that shows the schedule cost of each reversal. |
| A simple-sounding feature turned into a month | Payments, offline behavior, background sync, or a hardware permission was described as one screen when it is a category of work with its own failure handling. | List every state that feature can be in, including the failed and interrupted ones, and count how many of them need their own handling and their own test. | Reclassify it, prove it in isolation before integrating it, and consider launching without it if the business can wait. |
| The build is ready but the developer accounts are not | Store account setup was left to the end. Company enrollment with Apple needs a D-U-N-S Number registered to the legal entity, and payout setup needs banking details and tax forms. | Check whether both accounts exist, are verified, and are in the correct legal name, before checking anything about the app. | Open both accounts in week one. They are cheap, they are slow, and they sit on the critical path whether or not the plan admits it. |
Release, watch, recover
Deploy
Freeze the release candidate, record the version, upload the signed build under your own developer accounts, and release through a staged rollout with the previous build ready to fall back to.
Prepare the store listing, privacy answers, and reviewer credentials before submitting, and submit with real slack in front of any external date.
Monitor
Watch crash-free sessions, the completion rate of the main flow, backend error rates, and store reviews for the first days after each release, and widen the rollout only while those hold.
Track the Apple membership renewal date and the operating-system release calendar, because both can take a working app off the store without any change on your side.
Recover
If a release is bad, halt the rollout first. That is immediate and does not need a review cycle, unlike shipping a fix.
Preserve the evidence, diagnose the failed boundary, correct it, run the full device matrix again, and resubmit as a new attempt with its own review window rather than assuming the second one will be faster.
The security work that belongs inside the estimate
Moving these after launch makes the schedule look shorter by hiding required work, and one of them is a common reason for a rejection round trip.
- Keep API keys, provider tokens, and database credentials on the server. Anything shipped inside the app can be read out of it, so treat a key in the bundle as already public.
- Collect only the personal data the app needs, be able to say what each field is for, and answer the store privacy questions truthfully. An answer that does not match what the app actually does is a rejection risk and a trust risk.
- Test authorization on the server, not in the interface. Hiding a button is not an access rule, and the fastest way to find that out is not in production.
- Plan account deletion and data export before launch, because both stores expect an account-based app to offer a route to remove an account, and retrofitting it is more work than building it.
- Budget time for dependency and operating-system updates. A yearly OS release can break a shipped app on devices you never touched.
App timeline questions
Can an app really be built in a day?
A working first version, yes, for a focused app. A launched app, no. Between the two sit real content, the data states nobody described, testing on real devices, store assets, developer accounts, any required closed test, and review. Report the first version as a first version; calling it launch-ready is how a one-day build becomes a two-month surprise.
How long does app store review take?
Neither Apple nor Google commits to a turnaround, so treat any number as planning guidance and never as a promise. Google states that processing an app change can take a few hours or up to seven days, or longer in exceptional cases, and that new developer accounts can face extended review. Reviews can also reject a build, which starts the clock again.
Why is my first Android release taking two extra weeks?
Almost certainly the closed-testing requirement. Google requires personal developer accounts created after 13 November 2023 to run a closed test with at least 12 testers opted in continuously for at least 14 days before applying for production access. Testers who opt out and back in restart the 14 days, so recruit more than twelve and tell them exactly what is being asked.
Does using an AI builder actually make it faster?
It compresses implementation, which is usually the largest single block of build time, and it does nothing to store time. The gain is real and it is bounded: you still decide what the product does, verify what was generated, test on real devices, prepare the listing, and wait in the same queue as everyone else.
Is it faster to build for one store first?
Usually yes, and Android is often the cheaper first step because the account fee is a one-time US$25 rather than an annual membership. The counterweight is the closed-testing requirement on newer personal accounts. Pick the store your actual users are on, and treat the second store as a separate release with its own assets, its own review, and its own date.
What part of building an app takes the longest?
For a first app, it is rarely the code. It is usually deciding what the product should do, producing the real content, and the store work at the end: accounts, listings, testing periods, and review. For complex products, payments, offline behavior, and permissions dominate. Your inventory tells you which case you are in.
How much buffer should an app timeline carry?
Do not add a percentage and call it certainty. Name each uncertain item, estimate its low and high effect, and show it as a line. Then add at least one full review round trip as an explicit item, because being sent back once is normal rather than exceptional for a first submission.
When should I re-estimate?
When a user role, integration, or payment requirement enters or leaves scope; when the pilot flow disproves an assumption; when store account setup turns out to be incomplete; when a submission is rejected; or when a store changes a requirement. Keep the old assumptions visible so the reason for the change stays legible.
COMPRESS THE HALF YOU CONTROL
Build time is yours. Spend less of it.
Describe what the app should do and get a working version with a real backend, a database, and logins behind it, then open it on your own phone and find out what you actually got. The store queue will still take what it takes.
Start BuildingStore review duration and outcome are decided by Apple and Google, not by any builder. You hold your own developer accounts and press the final submit yourself.