The mobile app development process: what happens at each stage, from kickoff to launch

A mobile app build runs through the same stages whoever builds it: scoping, design, build in sprints, testing, store review, and the run phase after launch. This guide explains what happens in each stage, what you are asked to sign off, what "done" looks like, and where schedules usually slip, with the platform rules from Apple and Google cited where they decide the outcome.

By Kanika Mathur, Head of Service Delivery

Reviewed by Resourcifi engineeringPublished Sep 8, 2026Updated Sep 8, 202610 min read

Process

Key takeaways

The short version

Scoping produces a document you sign. It fixes the first release's feature list, the platforms, the build approach and the sprint plan. Everything not needed to prove the core use goes on a later list.
You see a clickable prototype before any code. Design sign-off covers every screen state, including errors, empty states and permission prompts, because those are what reviewers and users hit first.
Build runs in fixed-length sprints with a demo on a real device at the end of each. Done means merged, reviewed, tested and installable, not "coded".
Store review is fast when the submission is complete. Apple reports that 90 percent of submissions are reviewed in under 24 hours, and that over 40 percent of unresolved issues trace to one guideline: app completeness. Google says review can take up to seven days or longer for some accounts.
Maintenance is not optional. Apple and Google each raise their minimum build requirements on a schedule, so an app that is never updated eventually stops being accepted or stops reaching new users.

Discovery and scoping: what gets decided and what you sign off

Scoping turns an idea into a written scope you sign before design starts: the problem, the users, the feature list for the first release, the platforms, the build approach and the sprint plan. The decision rule inside it is simple. If a feature is not needed to prove the core use of the app, it goes on the later list.

The stage is a short series of working sessions with your product owner, a lead engineer and a designer. If you are still weighing whether an app is the right vehicle, start with our overview of what mobile app development involves. The decisions, in the order they come up:

Who the first release is for, and the one thing it must do well, written as a sentence a user would say. Every later cut is made against it.
Platforms. iOS, Android or both on day one. One platform first is a legitimate way to shorten the schedule.
Build approach. Native per platform or a shared cross-platform codebase. Our guide to native, hybrid and cross-platform apps covers the trade-offs; in short, shared suits most product apps, native wins for heavy camera, sensor or graphics work.
Third-party services. Payments, maps, messaging and analytics are bought, not built, on accounts in your name.
Store accounts, opened in your company's name at kickoff. Google requires new personal developer accounts to run a closed test with at least 12 testers opted in for at least 14 days before production⁷.
Data and privacy. What the app collects, why, and where it lives. Both stores make you declare this at submission¹², and Apple requires a privacy policy link in the listing and in the app¹.

What you sign off: the scope document, the sprint plan with the number of sprints and the demo dates, and the estimate.

Design and prototype: what you see before a line of code

Before code, you see user flows, then wireframes, then finished screens, then a clickable prototype on a phone. You sign off on the prototype, and that is the last cheap place to change your mind. A screen that moves in a prototype costs a designer a short revision; the same change after the build starts becomes a sprint story.

Design runs in four passes, each reviewed with you before the next starts:

User flows. Boxes and arrows for each job the app does: sign up, the core action, paying, recovering from an error.
Wireframes. Gray-box layouts for every screen, including the ones nobody enjoys drawing: empty states, loading, no network, permission denied, expired session.
Visual design. Typography, color, components and motion, following each platform's conventions.
Clickable prototype. Every flow tappable on a device, with a written list of the states each screen can be in, because engineers estimate from that list. Put it in front of a few target users and watch without narrating.

Two store rules belong in design rather than at the end. Apple requires in-app account deletion wherever an app offers account creation, and an equivalent private sign-in option wherever it offers a social login¹. Design the account screens to those rules and you avoid a rejection months later.

Build: sprints, demos, and what "done" means

Build runs in sprints of a fixed length agreed at kickoff, and each sprint ends with a demo of working software on a real device, not slides. A story is done when the code is merged, reviewed by a second engineer, covered by automated tests, and present in a build you can install yourself.

The first sprint is mostly foundations: project setup, continuous integration, the backend skeleton, authentication, and the pipeline that delivers a build to your phone through TestFlight and the Play internal track. After that, each sprint has the same rhythm:

One sprint, from the product owner's side
Moment	What the team does	What you do
Planning	Pulls the next stories from the priority list, sizes them, commits	Confirm priorities; answer open questions on the spot
During the sprint	Builds, reviews and tests each story; posts progress daily	Answer questions within a day; add nothing mid-sprint
Demo	Shows each finished story on a device, error states included	Accept or reject each story against its acceptance criteria
After the demo	Ships the build to your test devices	Use it for real for a day; log what you notice

The definition of done belongs in the contract, because it is where quality is decided. A sound definition of done has five parts: merged, reviewed by a second engineer, automated tests passing, checked by hand on a physical iOS and a physical Android device, and the acceptance criteria met. Fail any one and the story is not done. Your side of the bargain is decision speed: a question that waits days costs the sprint more than the feature it was about.

Testing: devices, performance, security

Testing runs through the build, not after it. Automated unit and UI tests run on every change, manual testing happens on real phones every sprint, and performance and security get their own passes before submission. The commercial reason is blunt: both stores reject apps that crash, and users delete them.

Both platforms document the layers. Android separates local tests, small and fast on a development machine, from instrumented tests that run on a physical or emulated device and usually drive the UI⁹. On iOS, XCTest and Swift Testing cover unit tests, XCTest drives UI tests and measures performance, and Simulator stands in when a physical device is not available³. The split we use:

Automated, every change. Unit tests for business logic and the API layer, plus UI tests for the flows that must never break: sign in, the core action, checkout.
Manual, every sprint, on real devices. A device pool spanning old and new, cheap and flagship, catches what emulators miss; Google Play's pre-launch report adds an automated pass on Google's own device lab when you upload an app bundle, subject to device-lab capacity¹¹.
Beta, before submission. TestFlight on iOS and a closed test on Google Play, which for a new personal Play account is also the gate to production⁷.
Performance pass. Cold start, scroll smoothness, memory on low-end devices, battery drain, and behavior on slow or absent networks. Measured, with numbers in the report.
Security pass, against the OWASP Mobile Application Security Verification Standard, which groups its controls into storage, cryptography, authentication, network, platform, code, resilience and privacy¹⁰. Our mobile app security guide goes through each group.

What you sign off: the test report, with devices tested, coverage, performance figures, open security findings and the known issues you are choosing to ship with. That last list is normal; an empty one means nobody looked.

Release: App Store and Play review, and what gets rejected

Release means submitting a build plus store listing, privacy declarations and review notes to each store, then waiting for review. Apple reports that on average 90 percent of submissions are reviewed in less than 24 hours². Google says review for certain developer accounts can take up to seven days or longer in exceptional cases⁶. Plan the launch date around the slower of the two.

90%

of App Store submissions are reviewed in less than 24 hours, on average.

Apple, App Review

40%+

of unresolved App Review issues relate to one guideline, 2.1 App Completeness: crashes, placeholder content, missing information.

Apple, App Review

Up to 7 days

Google Play review time for certain developer accounts, or longer in exceptional cases.

Google, Publish your app

Apple states that over 40 percent of unresolved issues relate to guideline 2.1², which asks for a final build tested on-device, no placeholder content, working back-end services, and a demo account if the app has a login¹. The other common causes are rules you can check before you submit:

What Apple rejects, and the guideline it cites
What the reviewer finds	Guideline	How to avoid it
Crash, placeholder content, dead links, no demo login	2.1 App Completeness	Test the exact build on-device; complete the App Review Information section; supply a demo account
Screenshots of only a splash or login screen; undescribed features	2.3 Accurate Metadata	Screenshots of the app in use; Notes for Review; app name of 30 characters or fewer
Digital content unlocked by an outside payment or code	3.1.1 In-App Purchase and 3.1.3(e)	In-app purchase for digital content; your own provider for physical goods and services
A wrapped website or a set of links	4.2 Minimum Functionality	Ship features that only make sense as an app
Social login with no private alternative	4.8 Login Services	A sign-in limited to name and email that lets users hide their email
No privacy policy link, no consent, no in-app account deletion	5.1.1 Data Collection and Storage	Privacy policy in the listing and the app; consent before collection; in-app deletion

Google Play's policies cover the same ground, from privacy and device abuse to monetization and store listing, and are explicit that apps which crash or fail to give a working experience are not allowed⁵. Every Play submission also carries a Data safety form¹²; fill it in from what the app actually collects, not from what the plan said.

Three habits make review boring. Submit the build you tested, not one with "one small fix". Write the review notes for someone who has never seen your product. For updates after launch, release in stages on both stores, so a bad build stops early.

After launch: monitoring, updates, the maintenance budget

Launch starts the run phase, and it needs a budget line, a named owner and monitoring on day one. There are four costs to plan for: fixing what real users find, keeping up with each year's operating system and store requirements, paying for the services the app depends on, and building the next features on the later list. The first two are not optional, and the platforms set the pace.

The pace is published. Since 28-Apr-2026, apps uploaded to App Store Connect must be built with Xcode 26 or later using the iOS 26 SDK⁴. From 31-Aug-2026, new apps and updates on Google Play must target Android 16 (API level 36) or higher, with extensions to 01-Nov-2026, and an existing app that is not updated must still target Android 15 (API level 35) or higher, or it stops being available to new users on devices running a newer Android version⁸. Both requirements move every year.

What monitoring should cover from the first day:

Crashes and errors, by version and device, with an alert that reaches a person.
The funnel. Installs, sign-ups, first core action, return on day seven. Our guide to mobile app KPIs covers which of these belong on the dashboard.
Store reviews and service bills, read weekly. Reviewers report bugs that never reach your crash tool.

On the budget, we deliberately do not give a percentage of the build cost, because the honest figure depends on how much the app changes and how many paid services it leans on. Put a monthly figure against each of the four buckets and reserve engineering time in whole days per month rather than "as needed". A growing product needs a standing team; a finished one needs a retainer for the yearly platform updates.

Where projects slip, and how to keep yours on schedule

Projects slip in five predictable places: scope that grows mid-sprint, accounts and credentials that are not ready, third-party services that behave differently from their documentation, testing squeezed when the build runs long, and a store rejection at the end. Each has a countermeasure you can put in place at kickoff.

The five common slips and the countermeasure for each
Where it slips	Why it happens	What prevents it
Scope grows mid-sprint	A good idea is added without anything being removed	The later list; new ideas enter only at planning, by displacing something of similar size
Accounts and credentials	Store accounts, payment approval and certificates requested when needed, not at kickoff	A first-week checklist of every account in your name; Google's tester requirement for new personal accounts alone takes 14 days⁷
Third-party services	Sandbox differs from production; a provider's approval outlasts the sprint	Integrate the riskiest service first, in a spike
Testing squeezed	Build overruns eat the device, performance and security passes	Test inside every sprint; keep the definition of done fixed
Store rejection	Placeholder content, a missing demo account, a rule found late	A pre-submission checklist from the guidelines; an early TestFlight external build, which goes through TestFlight App Review against the same guidelines¹

Two further rules keep a schedule honest. Report in working software, not percentages: a demo on a device is a fact, "70 percent complete" is a feeling. And under pressure, cut scope rather than testing. For how long each stage tends to take, see our guide on how long an app takes to develop. If you would rather have a team that already runs this process, our mobile app development page explains how we scope, staff and run a build.

Frequently asked

Process questions

What are the stages of the mobile app development process?

A build runs through scoping, design and prototyping, development in sprints, testing, store submission and review, and then an ongoing run phase of monitoring and updates. The stages overlap in practice: testing runs inside every sprint rather than after the build, and store accounts, privacy declarations and third-party approvals are started at kickoff because they take longer than the step that needs them. What you sign off is a scope document, a clickable prototype, each sprint demo, a test report and the submission itself.

What do I need to sign off before development starts?

Three things. The scope document, which lists the first release features, the later list, the platforms, the build approach and the third-party services. The sprint plan, which sets the sprint length, the number of sprints and the demo dates. And the clickable prototype, screen by screen, with the states each screen can be in written down. Changing any of these after the build starts is allowed, but it moves the other two, so it is worth taking the reviews seriously rather than waving them through.

How long does App Store and Google Play review take?

Apple reports that on average 90 percent of submissions are reviewed in less than 24 hours. Google says review for certain developer accounts can take up to seven days or longer in exceptional cases. Plan a launch date around the slower of the two, submit the exact build you tested, fill in the review notes with a demo login and steps for every feature, and avoid resubmitting while a review is in progress.

Why do apps get rejected by the App Store?

Apple states that over 40 percent of unresolved issues relate to guideline 2.1, App Completeness, which covers crashes, placeholder content, dead links, back-end services that are switched off and missing demo accounts. The other common causes are specific rules: screenshots that show only a splash screen, unlocking digital content outside in-app purchase, apps that are a wrapped website, social login with no private alternative, and missing privacy policy links or in-app account deletion. All of them can be checked against the guidelines before submitting.

What is a definition of done in a sprint?

It is the written test a story must pass before the team calls it finished. A sound definition of done has five parts: the code is merged to the main branch, a second engineer has reviewed it, its automated tests pass in continuous integration, it has been checked by hand on at least one physical iOS and one physical Android device, and the acceptance criteria agreed at sprint planning are met. It belongs in the contract, and it should not loosen when the schedule is under pressure.

How much should I budget for maintaining an app after launch?

We do not give a percentage of the build cost, because the honest figure depends on how much the app changes and how many paid services it uses. Budget four buckets instead: fixing what users find, the annual platform work that Apple and Google require through new SDK and target API level rules, the monthly bills for hosting and third-party services, and the next features on your later list. Reserve engineering time in whole days per month; even a finished product needs a retainer for yearly platform updates and patches.

Kanika Mathur

Head of Service Delivery, Resourcifi

Kanika Mathur is Head of Service Delivery at Resourcifi. She leads the engineering pods that scope, build and run client software, from mobile apps to AI systems, and she reviews the process and figures in our engineering guides for accuracy.

Resourcifi on LinkedIn →

Sources

Apple, App Review Guidelines (guidelines 2.1, 2.3, 3.1.1, 3.1.3(e), 4.2, 4.8 and 5.1.1, the rules behind the rejection table and the account, login and privacy requirements; TestFlight betas must comply with the guidelines and go through TestFlight App Review).
Apple, App Review (90 percent of submissions reviewed in less than 24 hours on average; over 40 percent of unresolved issues relate to guideline 2.1; what to put in the App Review Information section).
Apple, Xcode (XCTest and Swift Testing for unit tests, XCTest UI tests and performance measurement, Simulator for testing across devices and OS versions).
Apple, Upcoming requirements (since 28-Apr-2026, uploads must be built with Xcode 26 or later using the iOS 26 SDK).
Google, Developer Policy Center (the policy areas Play enforces; apps that crash or do not provide a functional experience are not allowed).
Google, Publish your app, Play Console Help (review times of up to seven days or longer in exceptional cases for certain developer accounts).
Google, App testing requirements for new personal developer accounts (closed test with at least 12 testers opted in for at least 14 days before production access for new personal developer accounts).
Google, Target API level requirements for Google Play apps (from 31-Aug-2026 new apps and updates must target Android 16, API level 36, extension to 01-Nov-2026; existing apps must target Android 15, API level 35, to remain available to new users on newer Android versions).
Google, Fundamentals of testing Android apps (local tests on the development machine versus instrumented tests on a physical or emulated device; small, medium and big test scopes).
OWASP, Mobile Application Security Verification Standard (MASVS) (the eight control groups used for the security pass: storage, crypto, auth, network, platform, code, resilience, privacy).
Google, Use pre-launch reports to identify issues, Play Console Help (pre-launch reports are generated automatically when you upload an app bundle or APK, subject to capacity in the device lab).
Google, Provide information for the Data safety section, Play Console Help (all developers with an app published on Google Play must complete the Data safety form).