Most apps don’t get retired on a date someone picked. Apple’s App Store Improvements policy states that apps that crash on launch are removed immediately, and a removed app keeps working for people who already installed it.
The build is a small piece of the whole story. Store review, updates, user retention and eventually a shutdown all come after it, and the platform owners get a say in that last one.
What Is an App Lifecycle?
The term covers everything that happens to one application between the first requirements meeting and the day it stops being available. That includes the build, the store release, the updates after launch and the work of keeping users around.
It runs through planning, design, development, testing, deployment, maintenance and retirement. Product managers, UX designers, developers, QA engineers and DevOps engineers each own a piece, and every stage hands the next one something concrete. A requirements document, a design, a tested build, a store listing, a patch, a shutdown notice.
Most guides frame this around mobile app development, but web and desktop apps go through the same stages.
Retirement isn’t always final. Appetiser’s lifecycle glossary notes that a retired app can be replaced by an upgraded version or a new product, which starts the next lifecycle.
App lifecycle versus the software development lifecycle
The software development lifecycle, or SDLC, is the general framework for building software of any kind. A generic software development process says nothing about app stores, install bases or churn, and whether a given SDLC variant continues past deployment depends on who wrote it.
ISO/IEC/IEEE 12207:2017 covers acquisition, supply, development, operation, maintenance and disposal, yet it prescribes no specific life cycle model.
The app lifecycle picks a model for one kind of product and ties each stage to the store rules and metrics that apply to a live app.
Related terms that get mixed up
Application lifecycle management is mostly governance and tooling, things like who gets access to which version. Product lifecycle is the market view of introduction, growth, maturity and decline.
The app lifecycle covers the actual work and decisions for a single app as it moves through its stages.
Stages of the App Lifecycle, From Planning to Retirement
Here is how the work splits up, with what each stage produces and who usually owns it.
| Stage | Deliverable | Owner role | Typical tool |
|---|---|---|---|
| Planning | Requirements document | Product manager | Jira |
| Design | Wireframes, prototype | UX designer | Figma |
| Development | Working build | Developer | GitHub |
| Testing | Test report | QA engineer | TestFlight, Google Play closed testing |
| Deployment | Store listing, release notes | DevOps engineer | App Store Connect, Google Play Console |
| Maintenance | Patch and feature releases | Developer, product manager | Firebase Crashlytics |
| Retirement | User notice, data export | Product manager | Store availability settings |
The tools are examples and teams swap them freely. On a five-person team one developer can cover several of the usual software development roles, while larger companies give each stage its own owner.
Why published counts disagree
Guides give four, six, eight or nine stages for what is largely the same work. CIO Index’s application portfolio guidance uses four: introduction, growth, maturity and decline. Netguru’s mobile lifecycle guide runs from planning through maintenance and lands on six.
Omnissa gets to eight by adding steps like discovery and rollback to its lifecycle management stages. Orient Software reaches nine by giving research, wireframing and technical feasibility their own steps.
The counts differ because sources split or merge the same work. The four-stage model describes where the app sits in its market, while the others describe what the team is doing.
Netguru’s six stop at maintenance, which is why the seven-stage count here keeps retirement as its own stage.
Waterfall, Agile and DevOps in the App Lifecycle
None of these models owns the app lifecycle. Waterfall, agile and DevOps arrange the same seven stages differently, and every app ends up looping once it is live, because maintenance feeds the next round of planning.
| Model | Stage order | Release rhythm | Best fit |
|---|---|---|---|
| Waterfall | Sequential, one pass | One release at the end | Fixed scope, sign-off heavy apps |
| Agile (Scrum) | Repeated inside sprints | After any sprint | Changing requirements |
| DevOps | Overlapping, automated pipeline | Frequent, automated | Apps updated often |
Waterfall
Royce’s 1970 paper in the IEEE WESCON proceedings is the usual origin of the waterfall model, yet it drew feedback between neighboring phases and never used the word waterfall.
For an app, a waterfall approach freezes requirements before design starts and ships to the stores once. It still works for fixed-scope apps that need documented sign-off at every stage.
The upside is clear handoffs and a full documentation trail. Scope stays predictable as well.
The downside is late feedback, since users see the app only after testing, and changes get expensive once design is frozen.
Agile
The 2020 Scrum Guide defines sprints as fixed-length events of one month or less, so an agile app team plans, builds and tests inside every sprint.
The backlog, often kept in Jira, sets the order of work. The Agile Manifesto behind the approach dates to a February 2001 meeting in Snowbird, Utah, according to Jim Highsmith’s account on agilemanifesto.org.
A team can push a build to TestFlight or a Play Console track after any sprint.
Feedback arrives every sprint, so a requirement change costs one iteration instead of a rewrite. The cost is open-ended scope, and without a fixed budget the project can drift.
DevOps
DevOps merges the people who build an app with the people who run it.
Under DevOps practices, a CI/CD pipeline builds, tests and uploads every change automatically. Jenkins typically runs the build and test pipeline, and Fastlane automates build and store upload.
DORA’s State of DevOps research tracks delivery performance with measures such as deployment frequency, lead time for changes, change failure rate and failed deployment recovery time.
The payoff is fast releases and early failure detection. The trade-off is setting up and maintaining the pipeline, which small teams tend to underestimate, and store review still gates every release.
Why the lifecycle loops after launch
Maintenance feeds planning in every model. Crash reports and store reviews become backlog items for the next release.
A strictly sequential lifecycle fits poorly when an app never has a single launch date, such as a web app updated several times a day. The stages still exist, but they run in parallel.
Enterprise lifecycles differ too. Omnissa describes steps such as entitlement and rollback, with apps delivered to managed desktops instead of public stores.
Pre-Launch Stages: Planning, Design, Development and Testing
Each pre-launch stage ends with something the next one can’t start without. A requirements document, a prototype, a working build and a test report.
Planning
Planning produces the requirements document, which sets out the purpose, target audience, monetization model and MVP scope (the smallest version that tests the core idea). The product manager owns it, and the backlog and sprint tasks usually live in Jira.
Teams usually write it as a software requirement specification that separates functional from non-functional requirements.
The classic failure here is scope creep. An MVP that grows before design starts pushes every later stage back.
Design
Design turns requirements into screens.
The UX designer starts with low-fidelity wireframing, builds a clickable prototype in Figma, and finishes with a UI specification the developers can build from.
Design changes after coding starts mean rework in finished code, which is why prototype feedback belongs in this stage.
Development
Since April 28, 2026, Apple requires apps uploaded to App Store Connect to be built with Xcode 26 or later against the iOS 26 SDK or the matching 26 SDKs (Apple Developer, upcoming requirements). The previous baseline, Xcode 16 with the iOS 18 SDK, applied from April 24, 2025.
That makes the toolchain a lifecycle dependency. A team that skips the annual SDK update cannot upload even a bug fix.
Developers build the front end and the back end, choose between native and cross-platform code, and keep every change in GitHub. Shortcuts taken here become technical debt that maintenance pays for later.
Version numbers follow Semantic Versioning where the team uses it. MAJOR is for incompatible API changes, MINOR for backward-compatible additions and PATCH for backward-compatible bug fixes (semver.org, specification 2.0.0).
Testing
The QA engineer owns testing, and the test report is its deliverable.
Functional, performance and device checks run first. User acceptance testing follows, where stakeholders confirm the build meets the requirements document.
On iOS, Apple’s App Store Connect Help allows up to 100 internal testers and up to 10,000 external testers through TestFlight, and a build stays testable for 90 days after upload. External builds may need beta review first.
On Android, personal accounts created after November 13, 2023 must run a Google Play closed test with at least 12 testers opted in continuously for 14 days before applying for production access (Google Play Console Help).
Testing closes when the report shows no open blocking defects. The approved build is the input for deployment.
How to Deploy an App to the App Store and Google Play
Deployment follows the same path on both stores, from building the release to watching the first days after it ships.
- Build and sign the release: an archive for iOS, a signed app bundle for Android.
- Upload it to App Store Connect or to a Google Play Console release track.
- Complete the listing: description, screenshots, privacy details and release notes.
- Submit for review.
- Choose how it goes out: to everyone at once, or in stages.
- Watch crash and rating data for the first days, with a plan to pause.
A DevOps engineer or release manager usually runs steps one, two and five, while the product manager owns the listing text.
Teams treat app deployment as routine until a rejection lands, which is why it pays to know what reviewers check.
What store review checks
Apple’s App Review Guidelines are arranged into five sections: Safety, Performance, Business, Design and Legal.
The same page makes developers responsible for everything inside the app, including ad networks, analytics services and third-party SDKs.
Apple also keeps a list of common missteps that slow review down or trigger a rejection. Out-of-date contact details and a reviewer who can’t get full access to the app are on it. So are backend services switched off during review.
Google Play applies its own developer policies, and every upload must also clear the target API level rule covered under maintenance.
How long review takes
Apple’s App Review page states that on average 90% of submissions are reviewed in less than 24 hours (Apple Developer, App Review). In a June 2026 statement, reported by 9to5Mac, Apple put the figure at 90% of submissions processed within 48 hours, with an average review time of 1.5 days.
Recent threads on Apple’s own developer forums describe waits of five days to two weeks, so treat 24 to 48 hours as the typical case and not a promise.
Submit to the store days before any fixed launch date.
Choosing a release method
Apple lets you release manually after approval, release automatically, or use phased release. Phased release reaches an increasing share of users over a set period and can be paused if a defect shows up.
Google Play uses staged rollout to a percentage of users, raised only while crash data stays clean.
A staged rollout works like a canary deployment. A small group meets a defect first, and the rest of the install base never sees it.
Post-Launch Maintenance: Updates, Fixes and Platform Compliance
Bug fixes, security patches, OS compatibility updates and feature releases keep coming for as long as the app is live.
The post-deployment maintenance workload is set partly by the stores, because both platforms raise their minimum requirements every year.
Compliance deadlines
Since August 31, 2026, Google Play requires new apps and app updates to target Android 16 (API level 36) or higher (Play Console Help). Wear OS and Android Automotive OS apps must target Android 15 (API level 35) or higher, and Android TV and Android XR apps Android 14 (API level 34) or higher.
Existing mobile apps must target Android 15 (API level 35) or higher. Below that, the app stays available only on devices running the same or an older Android version than its target.
An app nobody updates drops out of discovery for new users on current phones, while existing installs keep running.
Crash monitoring
Firebase Crashlytics reports the percentage of crash-free users and crash-free sessions, and its Release Monitoring dashboard compares the newest build with earlier ones.
Android vitals counts users with at least one crash per day. Google Play may reduce visibility once the user-perceived crash rate passes 1.09% or the user-perceived ANR rate passes 0.47% (Android Developers).
The two tools measure different units, so the same crash produces different percentages.
Gate each release on one of them and keep the other as a cross-check, because the numbers will never match. Which one you pick matters less than sticking with it.
Technical debt and who pays
Shortcuts from the build stage come due as technical debt. Typical cases are a dependency that blocks an SDK upgrade and screens that break on new devices, plus the odd patch nobody dares to ship.
The developer and the DevOps engineer carry the fixes. The product manager decides which defect or compatibility item goes first, usually by the share of users affected.
Deferred maintenance has a visible end state. The compliance rules above hide the app from new users, and Apple’s removal criteria, covered under retirement, finish the job.
Metrics That Show Where an App Stands in Its Lifecycle
Retention rate, DAU/MAU ratio, crash-free sessions and app store rating are the readings that place an app somewhere on its path.
Retention rate
Retention rate tells you how much of an install cohort is still active on a given day. Day 30 retention is users active on Day 30 divided by users who installed on Day 0, times 100, and churn is 100 minus retention.
Adjust’s benchmarks show how quickly users drop off.
- Day 1 retention averages 26% globally (Adjust, April 2024)
- Day 7 falls to 13% (Adjust, April 2024)
- Day 30 lands at 7% globally, with 8% on iOS and 6% on Android (Adjust, April 2024)
- Braze, citing Statista, reports a conflicting Day 30 range of 1.2% to 5% for most categories
The two Day 30 readings do not agree, and the sources do not publish a cohort definition that would reconcile them. Adjust’s own April 2022 post put the Day 30 average near 6%, and the April 2024 update of the same post puts it at 7%, so even one publisher’s benchmark moves.
Use benchmarks as a sanity check, then track your own cohorts. A travel booking app opened a few times a year will sit far below a messaging app, and that is normal.
DAU/MAU ratio
DAU/MAU is a habit measure more than a reach measure.
Google Analytics defines DAU as active users in the last 24 hours and MAU as active users in the last 30 days, and the ratio hits 100% only if users engage every day. Firebase Analytics shows retention cohorts in its dashboard, and Google Analytics 4 calculates the stickiness ratios automatically.
Crash-free sessions
Crash-free sessions are the percentage of sessions that did not end in a crash, the closest everyday measure of software reliability for a live app. Crashlytics calculates it automatically.
The Firebase documentation adds a caveat. Crash-free users is an aggregate over the selected period, not an average, so values from different time windows cannot be compared.
App store rating
Apple lets developers reset the overview rating when they release a new version. Written reviews stay, and the old rating cannot be restored.
Apple’s own guidance warns that a fresh rating with few votes can discourage downloads, so reset only after a fix that answers the complaints behind the old score.
Reading the numbers by stage
In growth, Day 7 retention holds while installs climb. Maturity looks flat, with DAU/MAU steady and crash-free sessions stable across releases.
Decline shows up as DAU/MAU falling while crash-free sessions stay healthy, which means the app works and users still leave.
That decline pattern is the one that triggers a retirement decision.
When Should an App Be Retired?
Retire an app when its maintenance cost outruns the value that retention and revenue show, and nobody has funded a rebuild.
Usage that stays flat or falls across several releases, in both DAU/MAU and Day 30 retention, is the obvious sign. Security debt counts too, meaning dependencies that block the next SDK or target API upgrade.
Sometimes the store hides or removes the app. Sometimes a newer product simply covers the same job.
When the store retires the app for you
Apple flags apps that have gone three years without an update and miss a minimal download threshold across a rolling 12 months, then emails the developer about possible removal (Apple’s App Store Improvements notice, April 2022).
Developers get up to 90 days to submit an update. Removed apps keep working for people who already downloaded them.
Google Play’s version of the same pressure hides outdated apps from new users instead of deleting them.
Update, rebuild or retire
Update when retention is healthy and the only problem is a compliance deadline. Rebuild when users stay but the codebase can’t take the next SDK upgrade.
If usage and revenue both fall and the rebuild has no owner or budget, retire.
How to retire an app on each store
On Apple’s side, Remove from Sale in App Store Connect stops new downloads and leaves the app with existing users. A reply on Apple’s developer forums says it stays available for re-download and iCloud restore.
The separate Remove App option deletes the app record, and vendor help centers call it hard to undo. Passion.io notes the app name can be claimed by someone else.
Guides disagree on what Remove App does to re-downloads by existing users, so choose Remove from Sale unless you must free the name.
Google Play handles it with Unpublish in Play Console. New users cannot find or install the app, while existing users keep using it and receive updates (Play Console Help).
Order of operations
The order decides whether users get a clean exit.
First, announce the end date in the app and by email, before touching the listing. Then offer a data export or migration route, and suppress offers for new subscriptions while existing subscribers can still cancel.
Shut the backend down last, because existing users keep a working app only while its services run.
Google followed this order with Google Play Music: streaming access ended in stages from September to October 2020 and the service shut down fully in early December 2020, with a transfer tool to YouTube Music and a Google Takeout export available until the remaining library data was deleted on February 24, 2021, after the original year-end deadline slipped (Android Authority, The Star). Subscribers who did not transfer were cancelled at the end of their billing cycle (Google’s August 2020 announcement).
An app removed from sale can return through the availability settings. A permanent removal cannot.
App Lifecycle FAQ
Which states does an app move through while it runs on iOS and Android?
Runtime states belong to a single session on a device and have nothing to do with the stages of a product.
iOS apps move between not running, inactive, active, background and suspended. Android activities pass through onCreate, onStart, onResume, onPause, onStop and onDestroy.
How long does it take to move an app through its lifecycle?
No standard duration exists. Scope, team size and store review time set the pace to launch.
Maintenance runs until retirement, so a fixed price fits a defined release, not the whole lifecycle.
Does an internal enterprise app follow the same lifecycle?
Yes. The stages stay the same, but deployment goes through private distribution or device management instead of a public store listing.
Retirement then means removing user access rather than delisting the app.
Is an MVP a separate stage of the lifecycle?
No. A minimum viable product is the first pass through planning, design, development, testing and deployment, built with only the features needed to collect real user feedback.
After release, the maintenance loop turns that feedback into the next version.
Which Stage Is Your App In, and What Comes First?
To place a live app, read stability and usage, in that order. Stability comes first because a failing build distorts every usage figure that follows.
A store that hides an outdated app from new users, or lowers a crashing one in visibility, shrinks the install cohorts that retention is measured on.
So clear store compliance and the crash rate first. Then read the Day 30 retention and DAU/MAU trend, and only after that choose between update, rebuild and retire.
The cost is one release cycle spent on fixes while feature work waits.
This order holds as of October 21, 2026, and changes whenever Apple or Google revise the requirements that gate an update.
- Protecting Users and Brand Standards Across Image-Driven Platforms - November 10, 2026
- Go Cheat Sheet - November 9, 2026
- Build or White-Label Software? How Software Teams Decide What to Resell in 2026 - November 9, 2026
