The short answer (3–6 months)
Most mobile apps shipped by professional teams in 2026 take 3 to 6 months from kickoff to App Store or Google Play. That number covers a realistic scope: two platforms, 15–40 screens, a backend API, user accounts and standard integrations. Here is how complexity maps to calendar time:
- Simple app (single platform, 5–15 screens, static or minimal backend): 2–3 months. Examples: calculators, basic readers, simple booking flows without payment.
- Medium app (two platforms or complex UX, real backend, payments, notifications): 3–6 months. This is where most startups and enterprise projects land.
- Complex app (both platforms, custom hardware integrations, heavy compliance, large content systems or real-time features): 6–12+ months. Examples: telemedicine, fintech, IoT companion apps.
These are calendar months for a properly staffed team: typically two to four developers, a designer, a QA engineer and a project manager. Smaller teams with the same scope will take proportionally longer.
Stage 1 — Discovery and scoping
Typical duration: 1–3 weeks.
Discovery is where the project is defined. Done well, it compresses every later stage. Done poorly — or skipped entirely — it is the root cause of most blown budgets and missed launch dates. What happens in discovery:
- Requirements workshops with stakeholders to define features, user flows and acceptance criteria.
- Technical architecture decisions: native (Swift/Kotlin) vs cross-platform (React Native or Flutter), backend stack, third-party integrations.
- Platform choice: iOS first, Android first, or both simultaneously — each has schedule implications.
- Compliance review: does the app touch health data (HIPAA), EU user data (GDPR) or payments (PCI DSS)? These add time to later stages and should be surfaced now.
- Output: a feature list with priorities, rough wireframes, a technical spec and a realistic project plan.
A week of focused discovery is worth four weeks of avoided scope creep later. See also our thinking on the cost of building an MVP — the economics of a tight scope apply equally to timeline.
Stage 2 — UX/UI design
Typical duration: 2–5 weeks.
Design runs from rough wireframes through high-fidelity UI and interactive prototypes to a developer-ready design system. In well-run projects, design and development overlap — developers start on backend and foundational screens while the designer finishes later screens. The key milestones:
- User flow maps and low-fidelity wireframes (all screens, rough layout): 1–2 weeks.
- High-fidelity mockups in Figma with real copy, assets and component library: 1–2 weeks.
- Prototype and usability review, client sign-off: up to 1 week depending on feedback cycles.
The most common design delay is late or vague client feedback. Every revision cycle adds 3–5 days. Agree internally on who has sign-off authority before design starts. If your branding, colour palette and copy are already defined, the design stage runs faster.
Stage 3 — Development
Typical duration: 6–16 weeks.
Development is the longest stage and the one with the most variability. It typically splits into backend (API, database, auth, integrations) and frontend (mobile screens, navigation, state management) tracks that run in parallel:
- Weeks 1–2: Project setup, authentication, core navigation, base API scaffolding.
- Weeks 3–8: Feature development sprint by sprint, working against the prioritised backlog.
- Weeks 8–12 (medium apps): Third-party integrations (payments, maps, push notifications, analytics), performance optimisation, offline handling.
- Weeks 12–16 (complex apps): Advanced features, compliance controls, admin dashboards, real-time layers.
Native vs cross-platform is a significant schedule variable. Building two separate native apps (one Swift/Kotlin iOS, one Android) effectively runs two parallel development tracks. Cross-platform with React Native or Flutter shares 80–90% of the codebase across both platforms, making it roughly 30–45% faster for combined iOS + Android delivery. Read the full tradeoffs in our native vs cross-platform comparison — the timeline impact is one of the biggest factors in that decision.
Stage 4 — QA and testing
Typical duration: 2–4 weeks dedicated, with QA overlapping development from week 2 onwards.
QA is not a phase that happens after development — it runs alongside it. A QA engineer joining at the end of development is a common mistake that adds weeks to the schedule. The right model:
- During development: QA reviews designs for testability, writes test cases alongside feature specs, runs smoke tests on each sprint’s completed screens.
- Integration testing: Full end-to-end flows tested on real devices across iOS and Android versions.
- Regression testing: Every bug fix verified not to break existing functionality.
- Performance & device coverage: Testing on low-end and high-end devices, poor network conditions, edge-case screen sizes.
- Final QA pass: 1–2 weeks of structured testing before store submission, producing a test report.
For regulated apps — anything touching HIPAA, PCI DSS, or medical devices — add 2–4 weeks for security audits, penetration testing and compliance documentation. GDPR data-handling audits for EU apps can be scoped into this stage as well. Adding security and GDPR work early (design stage, not QA) minimises the rework penalty.
Stage 5 — Store submission and launch
Typical duration: a few days to 1 week per store, plus buffer.
Store submission is often treated as a one-day formality. It is not. Budget a full week per platform, especially for first submissions. Here is the 2026 picture:
- Apple App Store: Review typically takes 24–48 hours in 2026 for updates and straightforward new apps. First submissions, apps with in-app purchases, health or finance features, or any app touching user-generated content can take 3–7 days. Rejection triggers a new review cycle — each cycle costs another 1–3 days. Before submission: resolve Xcode warnings, complete App Privacy nutrition labels, verify entitlements, set up TestFlight for internal review.
- Google Play: New app reviews run from a few hours to 7 days depending on category and any policy flags in 2026. Updates to existing apps typically go through faster. First-time developer accounts face additional scrutiny. Internal testing tracks can be published immediately and are useful for beta distribution while awaiting production review.
Practical advice: submit to both stores simultaneously, with a target launch date at least 1 week after your expected submission date. Do not announce a hard public launch date that depends on review approval — it is outside your control. Before submission, also optimise your store listing. ASO (App Store Optimisation) done before launch is dramatically more effective than retroactively, so read our guide to ASO before launch.
Stage 6 — Post-launch and iteration
Ongoing from launch; first iteration typically 2–4 weeks after go-live.
Launch is not the end — it is week one of a continuous cycle. The first weeks after go-live are typically the highest-intensity support period: crash monitoring, user feedback triage, emergency hotfixes and performance tuning under real traffic. Plan for a stabilisation sprint immediately after launch.
Iteration cadence depends on your model, but most successful apps ship meaningful updates every 2–6 weeks in the first year. Each update goes through the same store review process, though updates to existing apps move faster than initial submissions. Long-term, post-launch maintenance typically runs 15–20% of the original build cost annually — a figure worth building into budget from day one.
What makes it faster or slower
| Stage | Typical duration | What happens |
|---|---|---|
| Discovery & scoping | 1–3 weeks | Requirements, architecture, platform choice, compliance review, project plan |
| UX/UI design | 2–5 weeks | Wireframes, high-fidelity screens, component library, developer handoff |
| Development | 6–16 weeks | Backend API, mobile screens, integrations, parallel iOS + Android tracks |
| QA & testing | Overlaps dev + 2–4 weeks final | Device coverage, regression, security/compliance audit for regulated apps |
| Store submission & launch | Days to 1 week per store | Apple 24–48h typical; Google Play hours to 7 days; buffer for rejections |
| Post-launch iteration | Ongoing; first sprint 2–4 wks | Crash monitoring, hotfixes, user feedback loop, feature roadmap |
These are the factors that consistently lengthen or shorten a project, ranked by impact:
- Scope and feature count. Every additional screen or integration adds time. A clear, locked feature list for v1 is the single highest-leverage schedule decision. Features deferred to v2 are features that ship on time.
- Clarity and stability of the spec. Mid-project scope changes are the most common cause of schedule overruns. A change requested in week 8 that would have been trivial in week 1 can cost 2–3 weeks of rework.
- Native vs cross-platform. Choosing React Native or Flutter for a two-platform app saves roughly 30–45% of combined development time. For iOS-only or Android-only apps, this tradeoff does not apply. See our native vs cross-platform guide for a full breakdown.
- Third-party integrations. Each external API or SDK adds integration time, documentation discovery, sandbox-to-production migration, and a dependency on a third party’s uptime and API stability. Payments, mapping, biometrics and healthcare interoperability (HL7, FHIR) are particularly time-intensive.
- Compliance requirements. HIPAA (US health data), GDPR (EU personal data) and PCI DSS (card payments) each require architectural controls that must be designed in from the start, not bolted on. Expect 2–6 weeks of additional design and implementation time for each applicable framework, plus audit documentation.
- Design readiness. Starting development with incomplete designs means developers wait or build screens they will rebuild. Completing design for each sprint before that sprint starts eliminates this bottleneck.
- Team size and structure. A two-developer team takes roughly twice as long as a four-developer team on the same scope — not because engineering scales perfectly, but because more parallel tracks means more simultaneous progress. A dedicated QA engineer rather than developer-testing saves net time by catching defects before they accumulate.
- Client feedback velocity. Waiting 5 business days for design approval or spec sign-off is two weeks of potential development time lost per cycle. Fast, delegated decision-making on the client side is a genuine schedule accelerator.
If you want to understand the cost side of the equation, our mobile app development cost breakdown covers hourly rates, team compositions and total budget ranges in detail. For projects where speed to market is the priority, an MVP-first approach is often the right call — ship the core in 10–12 weeks, validate with real users, then build the full product on confirmed demand.
FAQ
How long does it take to build an MVP vs a full app?
An MVP typically takes 2–3 months: a tightly scoped set of core features, minimal onboarding, and one platform. A full feature-rich app with both iOS and Android, complex integrations, admin dashboards and compliance requirements usually runs 6–12 months or more. The key is defining MVP scope ruthlessly before development starts — every feature added to v1 delays validation of the core idea.
How long does App Store and Google Play review take in 2026?
In 2026, Apple App Store reviews typically take 24–48 hours, though first submissions or apps with sensitive categories (health, finance, kids) can take a few days to a week. Google Play reviews run from a few hours to 7 days depending on the app category and any policy flags. Plan for at least one week of buffer around your target launch date to absorb review delays or rejection cycles.
Does cross-platform build faster than native?
Yes, meaningfully so. Cross-platform frameworks like React Native and Flutter let a single team maintain one codebase that ships to both iOS and Android. In practice this means roughly 30–45% less combined development time compared to two fully separate native builds. The tradeoff is some limitations on platform-specific animations and deep OS integrations, though the gap has narrowed significantly in 2026. For most business apps, cross-platform is the faster and more cost-effective path.
Can you build a mobile app in one month?
Only for very simple, tightly scoped or template-based applications. A basic single-screen utility or a heavily scaffolded clone with no backend could reach a testable state in a month. Real products with user accounts, data persistence, notifications and store submission almost always need at least 2–3 months even as a minimal MVP. Teams that claim one-month delivery on complex apps are either scoping very narrowly or will miss the date.
What slows mobile projects down the most?
The biggest schedule killers are: unclear or frequently changing scope (each pivot restarts portions of design and development), late or incomplete design handoff (developers idling while screens are still being revised), complex third-party integrations (payment gateways, mapping, biometrics, EHR systems), compliance requirements like HIPAA or GDPR that require architectural changes, understaffing key roles especially QA, and slow client feedback cycles that create a bottleneck on decisions.
Last updated 12 June 2026.
