From Prototype to App Store: A Realistic Timeline

Almost every project we quote starts with the same two questions in the same order: what will it cost, and when can it be live. The second is harder to answer honestly, because the schedule is only partly about engineering. A meaningful share of the elapsed time between a prototype and a live listing goes on decisions, accounts, approvals and reviews — none of which move faster because you hired more developers. Here is the sequence as it actually runs.

How long does it actually take to get from prototype to the App Store?

For a typical business app with a backend: four to seven months from a standing start, of which a small and unpredictable slice belongs to App Review. Broken down, assuming a team already working on it rather than one being hired:

• Discovery and scoping: one to three weeks.
• Prototype: two to four weeks, partly overlapping the end of discovery.
• MVP build: three to five months for a workflow app with accounts, a backend and sync. Much less for something self-contained; much more if offline sync, payments or someone else's system is involved.
• TestFlight beta: two to six weeks, overlapping the tail of the build rather than following it.
• Submission and App Review: days in the good case, but plan a fortnight of buffer, because a rejection costs a round trip.

Two things move that range more than anything else: how many external systems you must integrate with, because their timelines are not yours, and whether one person on the client side can decide without convening a committee. That second factor has swung projects by six weeks in our experience, and no proposal can price it.

What happens in discovery, and can you skip it?

Discovery decides what you are building and what you are deliberately not building. You can skip it, and you will pay for it later at a worse exchange rate.

A discovery phase that earns its fee produces four things: one sentence naming the repeated interaction the app exists to improve, a list of user tasks in priority order with an explicit cut line, a technical risk register, and a rough data model. The cut line is the valuable one — a scope document without one is a wish list, and wish lists become fixed-price arguments in month four.

The risk register matters nearly as much and is usually missing. It is the list of things nobody on the team has done before, or that depend on something outside your control: an ERP with undocumented endpoints, a Bluetooth peripheral whose SDK is Android-only, offline conflict resolution, background location that must survive a full working day. Each gets a spike in the prototype phase, because discovering in month four that the sync model does not work is what actually blows up schedules. One to three weeks is the realistic budget; longer usually means you are working around an unmade decision.

What is a prototype, and what is it not?

A prototype is a deliberately incomplete thing built to answer one question. It is not a head start on the real app, and treating it as one is the most expensive mistake at this stage. There are two distinct kinds and most projects need both.

The design prototype

Clickable screens with no working logic — Figma, or a thin SwiftUI shell with fake data. Its job is to answer whether people understand the flow. Put it in front of six real users, watch where they hesitate, and change it while changing it is still free. A week or two, and the cheapest schedule insurance available.

The technical spike

Ugly, throwaway code that proves the risky thing works. Can we hold a Bluetooth connection while the screen is off? Does their API return the field we need? How large is the initial sync over a bad connection? A spike is judged on what it proves, not how it looks. One to three weeks depending on the risk register.

How do you decide what goes in the MVP?

One workflow, covered end to end, for one type of user. Everything else waits for evidence.

The instinct to load version one is understandable — the budget conversation feels like it happens once — but it reliably produces a longer, more expensive build with lower odds of being used. A release that does one thing completely teaches you more in three weeks of real usage than another quarter of specification. The filters we apply when scoping a first release:

• Cut every feature serving a second user type. Admin and reporting can wait; there is nothing to report on yet.
• Cut every configurable option. Pick a sensible default. Settings screens are where scope goes to hide.
• Cut offline sync unless the app is unusable without it. It is the largest cost multiplier in mobile, because two people editing one record on two disconnected phones is a genuinely hard problem, not a checkbox.
• Keep everything the core workflow cannot complete without, including the unglamorous parts: sign-in, error and empty states, failure recovery, and in-app account deletion if you offer account creation, which Apple requires.
• Keep crash reporting and analytics from day one. Retrofitting them means flying blind through the period you most need instruments.

Three to five months is typical for the build. Expect the backend to be a larger share than predicted — on workflow apps it is frequently more work than the app itself, and it is the part clients are most surprised to be quoted for.

When should you start TestFlight?

Earlier than feels comfortable — as soon as one workflow runs end to end, not when the app feels finished.

TestFlight has two tiers and the difference matters for planning. Internal testers are people on your App Store Connect team, capped at a modest number, and their builds appear without review, usually minutes after processing. External testers can number in the thousands and are invited by email or public link, but the first build of a version distributed to them goes through a beta review — lighter than full App Review, still a queue. Builds also expire after a fixed period, so a long beta needs fresh ones. Check Apple's current limits before planning around specific numbers; they have changed.

1. Week one: internal only, five to ten people including someone non-technical from the client side. The goal is finding the embarrassing things privately.
2. Week two: a small external group of real users — ten to thirty — doing their actual job with it, not a demo script.
3. Weeks three and four: widen it, and start watching numbers rather than opinions. Crash-free session rate, core-task completion, and where people stop.
4. Fix in priority order: crashes, then anything blocking the core workflow, then everything else. Resist cosmetic feedback while a completion rate is still bad.
5. Stop when the crash rate is stable and the core task completes reliably. Beta ends on evidence, not on the calendar.

Two to six weeks is the honest range. Under two and you have not observed a full usage cycle; past six and you are usually postponing a launch decision. Build a way to collect feedback inside the app while you are at it — testers who have to switch to email mostly do not bother, and what you lose is the feedback from people least invested in helping you.

How to build an in-app feedback loop in SwiftUI

What actually delays App Review?

Not the review itself, usually. Apple's published guidance has for some years been that the majority of submissions are reviewed within about a day, though this varies with volume and time of year. What delays launches is being rejected and going round again — and rejections cluster around a predictable set of causes:

• Incomplete submissions. A missing or broken demo account is the classic. If anything sits behind a login, a working test account and clear review notes are mandatory: reviewers will not sign up for your service and will not guess.
• Crashes on the reviewer's device. Test on the oldest OS version you claim to support, and on a device that has never run your app.
• Privacy problems. Inaccurate privacy answers, a missing or wrong privacy manifest, permission strings that do not explain why you need the data, tracking without the App Tracking Transparency prompt, or account creation without in-app account deletion.
• Payment rules. Selling digital goods outside in-app purchase, or linking out to your own payment page in ways current rules do not permit. These have moved repeatedly under regulatory pressure — verify the current position rather than copying a competitor.
• Minimum functionality. Apps that are a repackaged website, or too thin to justify being an app. Common when a first release got cut too aggressively.
• Metadata mismatches. Screenshots that do not match the app, a description promising a missing feature, or the wrong age rating.
• User-generated content without moderation. If users can post, you need filtering, reporting, blocking, published terms and a way to act on reports. That is a full feature, and it is regularly discovered late.
• Login requirements. If you offer third-party or social sign-in, check whether current rules oblige you to offer an equivalent private option alongside it.

Two scheduling notes. Apple typically announces reduced review processing around the end-of-year holidays, so a late-December launch is a bad plan; check the dates Apple publishes each year. And expedited review exists for genuine emergencies, but it is a favour you spend occasionally, not a schedule strategy.

What has to be in place before you can submit at all?

A surprising amount of admin and almost no engineering. Start it alongside the build, not after:

• Apple Developer Program enrolment under the right legal entity, with a D-U-N-S number for an organisation account. Longest lead time on the list.
• Clear ownership of that account — it should belong to the client, not the agency. Migrating an app later is painful.
• A published privacy policy at a stable URL, and a support URL a real person monitors.
• App Store Connect metadata: name, subtitle, description, keywords, category, age rating questionnaire, and screenshots at the sizes Apple currently requires. The required set has been simplified over time, so check rather than assume.
• Privacy answers, a privacy manifest, and manifests or signatures for third-party SDKs that require them.
• Export compliance answers about the encryption you use — usually straightforward for standard HTTPS, but you must answer.
• A demo account, test data, and review notes explaining anything a reviewer could not reasonably work out.

Budget a solid week, done properly, with one named person on it. This is the phase most often squeezed between "the build is done" and "why isn't it live yet".

What does a realistic calendar look like?

A worked example for a mid-sized workflow app — a field service tool with a backend, accounts, photo capture and a sync — assuming a decision-maker who answers within a day:

1. Weeks 1 to 2: discovery. Scope with a cut line, risk register, data model. Developer Program enrolment submitted in week one.
2. Weeks 3 to 5: design prototype tested with real users, plus spikes on the two highest risks. Go or no-go at the end of week five.
3. Weeks 6 to 12: backend and core workflow. First internal TestFlight build in week ten, not week twenty.
4. Weeks 13 to 18: the rest of the MVP, integrations, error and empty states, accessibility, analytics and crash reporting.
5. Weeks 17 to 21: beta — internal, then a small external group, then wider. Store metadata and privacy answers prepared in parallel.
6. Week 22: submit, with a few days of buffer for one rejection round trip.
7. Week 23: launch, ideally as a phased release so a bad build reaches a fraction of users rather than all of them.

A little over five months, sitting mid-range. Anyone quoting six weeks for the same scope is either not including the backend, not including beta, or planning to hand you something you will pay to rebuild.

What happens in the first month after launch?

More work than most plans allow for, and it is the month that decides whether the app survives. Expect a crash you never saw in beta, because production hardware and real data are more varied than any test group. Expect support questions clustering on one screen, which is a design finding rather than a training problem. Expect the first reviews within days, and expect them to be more useful than they are pleasant.

Keep the team available for four weeks at reduced capacity rather than moving everyone onto the next project the day after launch. That single scheduling choice is the difference between fixing things while people are still paying attention and shipping a patch to users who already deleted the app. Then plan the next release from what people actually did, not from the wish list cut in month one — and expect some of those cut features to turn out unnecessary, which is the discovery paying for itself.

The short version

Discovery decides what you are building. The prototype answers whether it will work, in two forms — one for the flow, one for the risk — and gets thrown away. The MVP covers one workflow completely. Beta runs on evidence, not on a date. Submission is mostly paperwork you should have started in month one. Review is fast when you prepared for it and slow when you did not.

Four to seven months, most of the time. Anyone promising materially less is quoting a different project than the one you described.