Short answer: a simple app takes about two to three months, a mid-complexity app with accounts, a backend and payments takes three to six months, and a complex multi-role or real-time product takes six to nine months or more. These figures cover the full path from kickoff to store approval, including design and testing, with a small experienced team building iOS and Android from one codebase.
About these ranges. They are planning estimates based on typical effort for a team of two to four people. They are not guarantees and not a BBR delivery promise. Real dates come from a written scope.
Timeline by app complexity
| Type of app | Typical characteristics | Kickoff to store |
|---|---|---|
| Simple | Few screens, no accounts or a thin backend, data from one source, local storage, standard interface. Examples: calculator, tracker, single-feed content app | 2–3 months |
| Mid-complexity | Accounts, custom backend, admin panel, push notifications, subscriptions or payments, a few integrations. Examples: subscription content app, booking app for one business, companion app for a web product | 3–6 months |
| Complex | Two or more user roles, real-time features, maps with live location, marketplace payments, offline sync, hardware integration or regulated data. Examples: on-demand marketplace, field-service app, social app with messaging | 6–9+ months |
If the complex row describes your idea and nine months is too long, the answer is rarely a faster team. It is a smaller first release. Our MVP timeline guide covers how to cut a product down to something that ships in one quarter.
Phase by phase
| Phase | Typical duration | What happens | What you do |
|---|---|---|---|
| Discovery and scope | 1–2 weeks | Feature list, priorities, technical approach, written scope, quote | Answer questions, decide what is in the first release |
| Design | 2–4 weeks | User flows, screen designs, clickable prototype | Review on your own phone and give consolidated feedback |
| Build | 6–20 weeks | App, backend and admin panel developed in iterations with test builds | Install builds, test, answer questions, supply content |
| Testing and hardening | 1–3 weeks | Device and OS testing, fixing, performance and edge cases | Acceptance testing against the agreed criteria |
| Store preparation and review | 1–2 weeks | Listings, screenshots, privacy declarations, submission, reviewer follow-up | Approve listing text, provide legal and support URLs |
Phases overlap in practice. Backend work can start while later screens are still being designed, and store listings can be prepared during testing. The build phase carries almost all the variation between a simple app and a complex one; the other phases change much less.
Store accounts and review: the part nobody schedules
Store logistics add calendar time that has nothing to do with engineering, and they are a common reason a “finished” app is not live.
- Developer account registration. Enrolling a company in the Apple Developer Program requires a D-U-N-S number and identity checks. Google also verifies new accounts. Allow anywhere from a few days to a few weeks and start in week one.
- Google Play testing requirement for new personal accounts. Google requires newly created personal developer accounts to run a closed test with a minimum number of testers for 14 days before an app can go to production. Organisation accounts are treated differently. Check the current Play Console rules for your account type before fixing a launch date.
- Review time. Apple reviews most submissions within a day or two. Google Play can take several days, particularly for a new app from a new account.
- Rejections. A first submission being sent back is common and usually minor: a missing account deletion option, an unclear permission explanation, incomplete privacy details, or a reviewer who could not log in because no demo account was supplied. Each round costs a few days.
A sensible plan puts two weeks between “build complete” and any date you have announced publicly. Both stores let you hold an approved app and release it manually, so submitting early costs nothing.
What slows app projects down
Slow decisions
The most common delay has nothing to do with code. A question about a business rule that waits a week for an answer delays the feature by a week, and ten such questions are a lost month. Appoint one person who can decide within a day or two.
Scope that grows during the build
Every “small addition” is reasonable on its own. Together they move the launch. Keep a second-release list, put new ideas on it by default, and move something into the current release only when you also accept the change in date and cost.
Feedback in fragments
Design comments from five people arriving over two weeks, some contradicting others, stall the design phase. Collect feedback, resolve disagreements internally, and send one list.
Third-party dependencies
Payment provider approval, access to a partner’s API, a hardware sample that has not arrived, legal sign-off on terms. These have their own queues. Identify them in discovery and start them immediately.
Content and assets
An app cannot be submitted without its content, privacy policy, support URL, icon and screenshots. These tend to be remembered in the final week.
Late discovery of platform rules
Finding out at submission that digital subscriptions must use store billing, or that background location needs a justification, means redesign and rework. A team that has released apps before raises these in the first week.
How to shorten the timeline without cutting quality
- Cut scope, not testing. Remove whole features; do not ship all features half-tested.
- Build cross-platform if you need both stores, so each feature is written once.
- Use managed services for authentication, push, storage and analytics in place of building them.
- Use platform-standard interface components. Custom controls and animation are slow to build and slow to test.
- Launch on phones only. Add tablet layouts when usage justifies them.
- Start store accounts, payment provider onboarding and legal documents in the first week.
- Release to a small group through TestFlight and Google Play testing tracks before the public launch, so the first crash reports come from friendly users.
- Agree a fixed weekly slot for demos and decisions, and keep it.
A realistic example
Take a subscription content app: accounts, a searchable library, favourites, push notifications, a paid plan through store billing and an admin panel for publishing. With a team of three, a workable schedule looks like this:
- Weeks 1–2: discovery and scope. Developer account enrolment begins.
- Weeks 3–5: design and prototype. Backend foundations start in week 4.
- Weeks 6–15: build. First installable test build around week 7; subscription flow tested in the stores’ sandbox environments from week 11.
- Weeks 16–17: device testing, fixes, store listings.
- Weeks 18–19: submission, review, one resubmission allowed for, staged release.
That is about four and a half months, in the middle of the mid-complexity range. The same app with an added community feed and chat would move toward six or seven months. The matching budget arithmetic is in our app cost guide, which uses the same building blocks.
When you compare vendors, treat the timeline as a test of honesty. A proposal that is much shorter than the others has usually left something out, most often testing and the store process. Our guide to evaluating app development companies lists what a credible plan contains, and the mobile app development page describes how BBR stages a project.