What Does App Maintenance Cost per Year?
By CodexierPublished 7 min read
The launch budget for an app is usually discussed in detail. The years after are often not discussed at all, and that is where apps quietly die: an OS update breaks a screen, a store policy deadline passes, a library stops being maintained and one day the app can no longer be submitted. This guide lists the work that recurs every year, explains the mechanism behind each item, and gives you a way to budget for it that does not depend on emergencies.
Why apps need yearly work
A website runs in a browser that stays backwards compatible for decades. An app runs on an operating system that changes every autumn and on hardware that changes every year, through a store whose rules change whenever the platform owner decides. None of that is under your control. What is under your control is whether someone is watching for the changes and applying them in a planned way, or whether you find out from a one-star review. The list below is what that person does.
OS and device updates
Each new iOS and Android version changes permissions, deprecates APIs and alters how the system draws things. Most apps keep working, but not all of them, and the ones that break do so in ways users notice: a layout that no longer fits a new screen shape, a camera or location permission that behaves differently, a login flow that no longer returns. Beta versions arrive in early summer, which is when the checking should happen, so a fix ships before the public release in September. New device sizes, foldables and tablets add layout checks. If the app is built with a cross-platform framework such as React Native, Flutter or Capacitor, that framework and its plugins also need upgrading to support the new OS, which is often the larger part of the work.
- Test the app on each OS beta before the public release, on real devices.
- Upgrade the framework and plugins at least once a year; large jumps skipped for two years become rewrites.
- Raise the minimum supported OS version deliberately, informed by your own user data, not by accident.
- Re-run the full permission flows after each major release; they change most often.
Store policy and SDK changes
Both stores set target SDK requirements with hard dates: after a given date, updates must be built against a recent SDK or they are rejected, and apps that fall too far behind can be hidden from search or removed. Alongside those come policy changes that need an app change or a form: privacy nutrition labels and data safety sections, mandatory account deletion for apps with sign-up, new rules for subscriptions, sign-in requirements and, in the EU, the alternative billing and Digital Markets Act provisions. None of these are hard individually. Collectively they arrive several times a year and each has a deadline.
| Recurring item | Frequency | What happens if missed |
|---|---|---|
| Target SDK deadline | Yearly per store | Updates rejected; app may be hidden or removed |
| Privacy and data safety forms | When data use changes, reviewed yearly | Review rejection or removal |
| Developer account renewal and agreements | Yearly | App removed from sale until accepted |
| Signing certificates and provisioning | Yearly for iOS distribution | Cannot build or push notifications stop |
| Third-party SDK updates (analytics, payments, maps) | Several times a year | Crashes, deprecated APIs, review rejection |
| Store listing and screenshots for new devices | Yearly | Listing looks outdated; new size classes unsupported |
Store fees and developer programme costs are set by Apple and Google and sit outside this list; they are paid directly to the platform.
Backend, hosting and monitoring
Most apps talk to a server, and that server has its own maintenance life: security patches, database upgrades, TLS certificates, dependency updates and the occasional provider price change. Cloud services deprecate APIs and retire old runtime versions on published schedules. Push notification services rotate keys. Crash reporting and analytics SDKs need updating to keep reporting at all. Then there is monitoring, the part that turns maintenance from reactive to planned: crash rates by version, API error rates, response times and a check that the login and the main flow work every hour. Without it, users are your monitoring system.
Security patches
Server OS, framework and dependency updates on a monthly cycle, with a faster path for critical vulnerabilities.
Backups and restore tests
Automated backups are only real if a restore has been tested. Do it quarterly.
Monitoring and alerts
Crash reporting, uptime checks on the API and alerts that reach a person who can act, not a shared inbox.
Cost review
Hosting and service bills drift. Review quarterly for unused resources and plan changes.
Budgeting and support plans
There are two honest ways to budget. The first is a fixed monthly plan that covers the recurring items above, with a defined response time for incidents and a set number of hours for small improvements. The second is to pay by the hour as things come up, which is cheaper in a quiet year and much more expensive in a year with a framework upgrade or a store policy change, and it puts the emergency on your calendar rather than the supplier's. Our own app maintenance and scaling plan is the first model, billed monthly with no setup fee; the figure is on the pricing page rather than repeated here, so it is always current. What it does not include is new features, which are scoped separately.
When you do not need a maintenance plan: an internal app used by a handful of staff on managed devices, where a broken screen costs an afternoon and not a customer, can be maintained on an ad hoc basis by whoever built it. And if the app is being retired within a year, spend on the essentials only: the store deadlines and security patches. For a customer-facing app with logins, payments or bookings, the plan costs less than one lost launch window. Which case you are in is a 15-minute call. If you send push notifications, the rules in push notifications users keep are part of the same yearly review.
- App maintenance and scalingOS updates, store compliance, backend patches and monitoring on a fixed monthly plan.
- PricingThe monthly plan and what it includes, alongside the rest of the catalog.
- Book a free 15-minute callTell us what the app is built with and when it was last updated; we say what is overdue.
Frequently asked questions
Can we just leave the app as it is if it works?
For a while. Then a store deadline passes, an OS update changes a permission or a library stops being maintained, and the next update becomes a large one because two years of changes have to be applied at once. Small yearly updates are cheaper than one big rescue.
Does maintenance include new features?
Usually not. Maintenance covers keeping the existing app working, secure and submittable, plus a small allowance for fixes. New screens, integrations or business logic are scoped and priced separately so the maintenance fee stays predictable.
Is a cross-platform app cheaper to maintain than two native apps?
Typically, because one codebase receives each fix. The trade-off is that the framework itself must be upgraded regularly, and plugins for native features sometimes lag behind OS releases. With a yearly upgrade cycle it is manageable; skipped for several years it becomes the largest single cost.
What happens to the app if we stop paying for maintenance?
Nothing immediately. Over the following months the risks accumulate: a missed store deadline, an OS change, an expired certificate. Users on new devices see problems first. If you stop, at least keep the developer accounts, certificates and store forms current yourself.
Not sure what your app is overdue for?
Fifteen minutes with an engineer: tell us the framework, the last update date and the stores it is in, and we list what is overdue and what the yearly plan would cover.
Book a free 15-minute call