The most common question after a mobile app ships is not "what did it cost to build?" It is "why does it keep costing money?" The app is live. The development sprint is done. And yet every few months there is something: a new iOS version, a crash on a device that someone just upgraded, a third-party SDK that stopped working, a privacy requirement that Apple made mandatory. Maintenance is not a surprise — it is the predictable ongoing cost of running software on a platform you do not control.
The problem is that most teams budget maintenance the same way they budget hosting: a small, fixed monthly fee that does not change much. In practice, mobile app maintenance is lumpy, driven by Apple's annual release cycle, and grows in cost as the codebase accumulates technical debt. This post breaks down what those costs actually look like, what drives the range, and how to structure the support model to avoid paying too much for too little.
The 15-20% Annual Rule and Why Teams Ignore It
The standard rule of thumb for software maintenance is 15-20% of the original development cost per year. For a mobile app that cost $150,000 to build, that is $22,500 to $30,000 annually. For a $400,000 app, that is $60,000 to $80,000 per year.
Most teams do not budget anywhere near this number for two reasons. First, the build project has a defined end date and a defined budget — maintenance feels different, like it should cost less because you are not building anything new. Second, the first year after launch is often quiet. The app is on a current iOS version, the SDK dependencies are up to date, and the crash rate is low. The costs start compounding in year two and three when the technical debt from the initial build starts showing up in compatibility issues, and when the first round of SDK deprecations forces mandatory updates.
The 15-20% figure is a useful starting estimate. The actual percentage for any specific app depends on four factors: platform count, SDK dependency count, code quality, and test coverage. We will come back to each of these when we discuss what drives the percentage higher or lower.
Annual iOS Major Release Cost: What Changes Each September
Apple releases a major iOS version every September. For most apps, this is not optional maintenance — it is mandatory. The App Store requires apps to be built with the current Xcode version, which means updating to the latest SDK, which means fixing whatever broke when Apple deprecated APIs your app was using.
iOS major release support costs $5,000 to $20,000 per app per year. The range is wide because the cost depends on how much of the app's code uses APIs that Apple deprecated in the new version, and how much the SwiftUI or UIKit APIs the app relies on changed.
The lower end of the range ($5,000–$8,000) applies to apps that:
- Use modern APIs that Apple is actively supporting and has not deprecated
- Have minimal third-party SDK dependencies, so vendor updates do not cascade into breaking changes
- Have reasonable test coverage so that API changes surface in tests rather than in production crashes
- Are built with SwiftUI and use patterns that Apple is evolving rather than replacing
The higher end ($15,000–$20,000) applies to apps that:
- Have significant UIKit code that needs migration to SwiftUI patterns that Apple is pushing as the standard
- Use deprecated networking, authentication, or cryptography APIs that Apple is removing
- Require new entitlements to support new OS privacy requirements (which Apple has added every year for the past three years)
- Have multiple targets (iOS + macOS + watchOS) that each require compatibility updates
- Use third-party analytics, attribution, or payment SDKs that have their own update cycles tied to new OS features
Budget $5,000–$20,000 annually for iOS major release compatibility and treat it as a fixed cost of operating a mobile product. The cost is not optional — apps that do not update break on the current iOS version, which drives user-visible crashes and App Store rating damage.
Crash Fix SLA Costs by Severity
Crashes are the most visible maintenance cost because they have a direct user-facing impact. How quickly a crash gets fixed — and what it costs to fix it at that speed — depends on severity.
| Severity | Definition | Target response | Typical fix cost |
|---|---|---|---|
| P0 — Critical | App crashes on launch or blocks all users from core functionality | 2–4 hours to hotfix submission | $2,000–$6,000 |
| P1 — High | Crash affecting a significant percentage of sessions or blocking a primary feature | Same day or next business day | $1,000–$4,000 |
| P2 — Medium | Crash affecting a minor feature or small percentage of users in specific conditions | 2–5 business days | $500–$2,000 |
| P3 — Low | Rare crash in edge case, minimal user impact, next planned release acceptable | Next release cycle | $200–$800 |
P0 crashes are expensive to fix quickly not because the code change is complex, but because the process of emergency response, diagnosis, fix, test, App Store submission, and expedited review consumes senior engineering time under time pressure. The $2,000–$6,000 range includes the engineer time for the fix, the testing to confirm it does not introduce a regression, and the expedited App Store review request process. Apple's standard review takes one to three days; expedited review for critical crash fixes is typically approved within 24 hours but requires a clear explanation in the review notes.
P1 and P2 crashes account for the majority of the ongoing crash fix budget. A well-maintained app with good monitoring should see two to five P1/P2 issues per quarter, costing $3,000–$15,000 annually across all crash fixes. Apps with poor monitoring discover P1 crashes through user reviews rather than crash reporting tools, which means the fix cycle is slower and the App Store rating damage is already done before the fix begins.
Third-Party SDK Deprecation Risk
Most mobile apps depend on third-party SDKs for analytics, crash reporting, payments, authentication, and feature flags. Each of these SDKs has its own release cycle, its own breaking change schedule, and its own response to Apple's annual changes. When a third-party SDK you depend on stops supporting the iOS version your users are on, your app breaks — not because of something in your code, but because of something outside your control.
Three categories of SDK dependency create the most maintenance cost:
Analytics and attribution SDKs. Firebase, Amplitude, Mixpanel, and attribution SDKs like AppsFlyer and Adjust all have aggressive release cycles tied to Apple's privacy and data collection framework changes. Every time Apple introduces a new ATT (App Tracking Transparency) requirement or modifies the privacy manifest system, these SDKs require an update. If you do not update the SDK, your app may be rejected on the next App Store submission. If the SDK vendor drops support for an older iOS version you still support, you face a choice: drop that iOS version or maintain a forked version of the SDK. Neither option is free.
Payment SDKs. Stripe, RevenueCat, and other payment SDK vendors update frequently due to PCI compliance requirements and Apple's StoreKit API evolution. StoreKit 2 introduced in iOS 15 has been progressively replacing StoreKit 1, and apps using older purchase flows face increasing pressure to migrate. Each migration of a payment integration requires careful testing across all purchase scenarios, which is more expensive than updating most other SDKs.
Social authentication SDKs. Sign in with Apple, Google Sign-In, and Facebook Login all have their own SDK update cadences. Apple's Sign in with Apple requirements have evolved over time, and apps that implement custom login flows instead of using the system-provided API have faced forced migration work. Facebook's SDK in particular has a history of large-version releases that require significant integration updates.
Budget $3,000–$10,000 annually specifically for SDK dependency updates, separate from iOS major release costs. Apps with four or more third-party SDK dependencies will typically land at the high end of this range, because SDK updates are rarely synchronized and sometimes conflict with each other.
Feature Velocity Maintenance: Why Year 2 Costs More Than Year 1
A counterintuitive aspect of mobile app maintenance is that shipping new features gets more expensive over time, not less. In year one, the codebase is relatively clean, the architecture matches the current feature set, and engineering estimates are reasonably accurate. In year two and year three, the codebase has accumulated technical decisions that made sense when they were made but now create friction when building new things.
Three patterns drive this cost increase:
Architecture mismatches. The architecture designed for a simple feature set does not always accommodate a complex one cleanly. Adding a feature that cuts across the original architectural boundaries requires either a targeted workaround (faster, but adds technical debt) or a structural refactor (slower, but cleans up the foundation). Teams that take the workaround path consistently find that each subsequent feature in that area costs progressively more to implement.
Test coverage gaps. Apps with low test coverage discover regressions in production rather than in testing. Every feature addition in a low-coverage codebase carries higher risk, which means engineering teams add manual testing time to compensate. That manual testing time is invisible in estimates but real in delivery timelines.
Accumulated state complexity. As an app matures, the state it needs to manage becomes more complex. User preferences, offline data, sync state, session state, and feature flag combinations multiply. Bugs in state management are disproportionately difficult to reproduce and fix, and they become more common as the number of possible state combinations grows.
The practical implication is that the cost to ship a feature of similar complexity in year two is 20–40% higher than in year one for most apps that have not invested in addressing technical debt. Budgeting for feature development should account for this growth rather than projecting flat costs.
In-House vs Retainer vs Per-Ticket: Support Model Comparison
| Model | Monthly cost | Crash response time | Best for |
|---|---|---|---|
| In-house iOS engineer | $8,000–$18,000/mo | Same day | Apps with continuous feature development, core product with high user volume |
| Retainer (agency/contractor) | $3,000–$8,000/mo | 4–24 hours (per SLA) | Stable apps with moderate feature velocity, teams without internal iOS expertise |
| Per-ticket / ad hoc | $0–$5,000/mo (variable) | 1–5 business days | Very stable, mature apps with infrequent maintenance needs |
In-house makes sense when the app is central to the business, feature development is continuous, and the engineering cost is justified by ongoing product work beyond maintenance. A dedicated iOS engineer at $8,000–$18,000 per month (salary plus overhead) is a significant investment, but it comes with the fastest possible response time and the deepest codebase knowledge. For apps processing meaningful transaction volume where a P0 crash for four hours costs more in lost revenue than the monthly engineering cost, in-house is the right call.
A maintenance retainer makes sense for apps that are stable with moderate feature velocity — a few significant feature additions per year, quarterly iOS update compatibility work, and responsive crash fix SLAs. The $3,000–$8,000 per month range buys committed hours from an engineer who knows the codebase, without the overhead of full-time employment. The trade-off is that the retainer engineer is not exclusively focused on your app — response times are governed by the SLA rather than proximity.
Per-ticket / ad hoc works for mature apps that mainly need annual iOS compatibility updates and occasional crash fixes. If your app has been stable for two or more years, has low feature velocity, and crashes infrequently, paying for maintenance only when something needs fixing is the most cost-effective model. The risk is response time — when something breaks, the ad hoc relationship requires finding an available engineer before work can start, which adds time when speed matters most.
What Drives the Percentage Higher or Lower
The 15-20% annual maintenance rule is a starting point. Four factors shift it significantly in either direction:
Code quality and test coverage. Apps with good test coverage and clean architecture cost significantly less to maintain because changes are safer and regressions surface before production. The investment in code quality during the initial build reduces ongoing maintenance cost by 30–50%. Apps built with speed as the primary objective often have technical debt that manifests as maintenance cost within 12–18 months of launch.
Platform count. Each platform you support is a separate maintenance cost center. An app that targets iOS, macOS, and watchOS pays iOS major release costs three times, has three separate crash profiles to monitor, and has three sets of platform-specific APIs that Apple may deprecate. Multi-platform apps with shared Swift code reduce some of this cost, but the platform-specific layers are still separate maintenance targets.
SDK dependency count. Every third-party SDK is a maintenance dependency. An app with two third-party SDKs will spend less on SDK update management than an app with ten. Teams that invest in reducing SDK count — by implementing features natively that a third-party SDK was providing, or by consolidating overlapping SDK functions — reduce the long-term maintenance surface area.
Feature velocity. Apps that ship new features frequently have higher ongoing engineering cost, but they also pay down technical debt faster because engineers stay engaged with the codebase and spot issues earlier. Paradoxically, apps with very low feature velocity sometimes accumulate more maintenance cost per unit of change because the codebase drifts further from current platform patterns between updates.
Frequently Asked Questions
How much does mobile app maintenance cost per year?
The standard rule is 15–20% of the original development cost per year, but this varies based on platform count, SDK dependency count, and code quality. A simple single-platform app that cost $80,000 to build should budget $12,000 to $16,000 annually. A multi-platform app with significant third-party SDK dependencies built for $250,000 should budget $40,000 to $60,000 per year. These figures cover OS compatibility updates, crash fixes, SDK dependency updates, and a small allowance for minor enhancements — not significant new features.
What does each major iOS release cost to support?
iOS major releases cost $5,000 to $20,000 per app to support, depending on how extensively the app uses deprecated APIs, how much SwiftUI migration is required, and whether new privacy requirements introduce mandatory changes. Apps with modern codebases using current APIs, minimal third-party SDK dependencies, and good test coverage land at the low end. Apps with significant UIKit legacy code, many SDK dependencies, or multiple targets land at the high end. Budget this range annually and treat it as a fixed cost of operating a mobile product.
When does a mobile app maintenance retainer make more sense than in-house?
A maintenance retainer makes more sense than in-house when: the app is stable with low feature velocity and does not justify a full-time iOS engineer; the team has no internal iOS expertise; crash response time requirements exceed what a part-time internal resource can provide; or the app is one of several products and dedicated iOS engineering headcount does not make economic sense at current revenue. In-house makes sense when the app is core to the business with continuous feature development and the team already has or needs iOS engineering expertise for other work.
Get a Maintenance Plan for Your App
If you have a shipped mobile app and you are trying to figure out what ongoing maintenance should cost — or you are in the planning stage and want to build a realistic maintenance budget before launch — a short conversation is the fastest path to a clear answer. Bring the app's tech stack, platform count, and SDK list and I will tell you what the realistic annual budget looks like and which support model fits your situation.
