The short answer
8 to 16 weeks from kickoff to App Store release for most builds. Smaller apps can be faster and larger ones take longer. Before that, a paid discovery phase of one to two weeks turns the idea into a written scope, which is what makes the timeline reliable.
Where the time goes
| Phase | Typical length | What happens |
|---|---|---|
| Discovery | 1–2 weeks | Goals, users and scope agreed. You leave with a written scope and a fixed quote. |
| Design | 2–4 weeks | Flows, screens and an interactive prototype, built on Apple’s Human Interface Guidelines. |
| Build | Most of the project | Swift and SwiftUI in two-week sprints, with a TestFlight build every week. |
| Launch | The final sprint | App Store submission, review and release under your own Apple account. |
| Support | 30 days, included | Fixes once real users arrive. |
Architecture and the start of development can overlap with the end of design, which is how most projects fit in the range. A weekly TestFlight build means you see the app growing rather than waiting for a reveal at the end.
What makes it take longer
- More core flows. Each separate thing a person opens the app to do needs its own screens, states and edge cases.
- A backend that does not exist yet. Building against an existing API is quicker than designing one alongside the app.
- Payments and subscriptions. Purchase, restore, renewal and cancellation need building and testing, and App Review checks them.
- Platform features. Widgets, Live Activities, HealthKit or Apple Pay are each a small project of their own.
- Design changes after building starts. A change in a prototype costs hours; the same change in code costs days.
- Slow decisions. A build waiting a week for feedback is a week added to the end.
- Review surprises. A rejection usually costs days. Our guide to App Store rejections lists the common ones.
The App Store part of the timeline
A few Apple steps run on Apple’s schedule, not yours. Start them early:
- Developer Program enrollment. An organisation needs a D-U-N-S Number, a public website on its own domain and a work email on that domain before it can enroll. Do this in week one, not in the last sprint.
- TestFlight review. The first build you share with external testers has to be approved by App Review for TestFlight. Internal testers, up to 100 people on your team, do not need it.
- App Review. Apple says it typically reviews at least 50% of submissions in under 24 hours and 90% in under 48 hours (source).
- Release. You can release manually, automatically on approval, or automatically on a set date. Updates can roll out gradually over 7 days with a phased release.
How to launch sooner
- Ship one flow first. A first version that does one thing well is the quickest route to real users.
- Design before you build. Agree the prototype, then write code.
- Use Apple’s components. System controls are quick to build and already familiar to your users.
- Review the weekly build in days, not weeks. Fast feedback is the cheapest acceleration there is.
- Prepare the listing during development. Screenshots, privacy details, the age rating and review notes can all be ready before the last sprint.
For what the same choices do to the budget, see how much an iOS app costs. For founders planning a first version, our MVP page covers what usually goes in and what waits.
Related: How much an iOS app costs · How to publish an app on the App Store · iOS app development