App maintenance cost in the UK: what to budget per month

Most app budgets stop at launch. The build is quoted, approved and paid for, and the line for what happens afterwards is either missing or a guess. Then the first iOS update breaks a screen, Apple changes a submission rule, a certificate expires, and someone asks how much it costs to keep an app alive.

This guide gives a straight answer for the UK in 2026: what maintenance actually involves, what we charge, what other UK agencies publish, and how to build a monthly figure for your own app. We publish our own iOS apps as well as building them for clients, so the examples are from apps we look after ourselves.

What "maintenance" actually means for an iOS app

An app that nobody touches does not stay the same. The platform moves under it. These are the things that need doing even when you ask for no new features:

• Each year's iOS and Xcode. Apple ships a major iOS release every autumn and, some months later, requires every upload to be built with the matching tools. The current rule is that since 28 April 2026 "apps uploaded to App Store Connect must be built with Xcode 26 or later using an SDK for iOS 26" ^[1]. An app last built with older tools cannot be updated at all until it is rebuilt, and a rebuild with a new SDK usually surfaces deprecated APIs, layout changes and at least one thing that used to work.
• Apple's changing submission rules. The same page lists age rating questions that had to be answered by 31 January 2026 to keep submitting updates, the requirement since May 2024 to declare approved reasons for certain APIs including those in third-party SDKs, and trader status for apps sold in the EU ^[1]. Each is small; each blocks the next update if it is missed.
• Certificates, profiles and keys. If your distribution certificate expires or is revoked, Apple says "you'll no longer be able to upload new apps or updates signed with the expired or revoked certificate" ^[2]. Push notification keys, provisioning profiles and the Developer Program membership itself all have renewal dates.
• The Developer Program membership. It costs 99 USD per membership year, or the local-currency equivalent ^[3]. If it lapses, "your apps will no longer be available for download and you won't be able to submit new apps or updates" ^[4]. The app disappears from the store until you pay.
• Crashes and bugs. New devices, new OS behaviour and new data expose bugs that were not there at launch. Someone has to read the crash reports.
• The store listing. Screenshots go out of date when devices change shape. The privacy label has to stay accurate; Apple says you are "responsible for keeping your responses accurate and up to date" and that you can change them any time without a new build ^[5]. Review notes, support URL and privacy policy URL all need to keep working.
• Third-party SDKs. Payment, analytics, crash reporting and advertising SDKs ship updates, deprecate versions and occasionally change what data they collect, which changes your privacy label.

None of this is optional, and all of it is cheaper done on schedule than done in a hurry when an update is blocked.

How often a new app actually changes

The textbook figure is one or two maintenance releases a year. Early in an app's life, it is much more. Here is the real release history of Cuefold, our teleprompter camera app, from its App Store Connect record:

Three releases in ten days, with a fourth submitted the day after. Several of those changes were not features at all. The 1.0.1 listing fix corrected a description that still mentioned a free trial and a lifetime purchase we had stopped selling before launch. The privacy label changed before 1.0.1 shipped, because we had added our own anonymous usage analytics and the label had to list the data types that involved. Between 1.0 and 1.0.1 we also fixed a permission-screen wording that Apple had rejected, in every language at once.

The point is not that every app needs a release a week. It is that the first three months after launch are the busiest period an app will ever have, and a maintenance budget that assumes a quiet quarterly update will be wrong exactly when it matters.

What we charge

Our monthly plan for a live iPhone or iPad app is App care at £450 a month, or £4,500 a year if paid yearly, which is two months free. Prices exclude VAT. It covers:

• Each year's iOS and SDK update: the app rebuilt and tested with the new iOS and Xcode, and any required SDK updates made.
• Keeping the app passing App Review as Apple's rules change, including privacy details and new submission requirements.
• Crash and bug fixes from the crash reports we watch. A fix that needs real rework is quoted first.
• Store listing and screenshot upkeep, so the listing matches the app and current devices.
• Renewals of certificates, provisioning profiles and push keys before they expire, and a reminder before your Apple Developer membership renews.
• Up to 4 hours of changes a month, for small features, copy changes or tweaks.
• A short note each month on what we did and anything coming up from Apple.

It does not cover Apple's Developer Program fee, which you pay so the account stays yours, or new features beyond the monthly hours, or the Android version of the app, which we quote separately. There is no minimum term; it is monthly with 30 days' notice.

If the app was built by someone else, we start with a takeover audit, from £650, so we know the code, the accounts and the risks before we take responsibility for it. For products that need steady new development rather than upkeep, our ongoing development plan starts at £1,500 a month for reserved build days.

What other UK agencies publish

Few UK agencies put a maintenance price on their website. These did, when we checked on 27 October 2026. We quote them so you can see the range, not to say any of them is wrong; their plans include different things from ours.

Two patterns stand out. Agencies that quote a percentage cluster around 15 to 25% of the build cost a year, so a £40,000 app implies £6,000 to £10,000 a year, or £500 to £830 a month. Agencies that quote a monthly price start between £675 and £1,500 for the entry tier, and those figures usually cover both iOS and Android, backend monitoring or a service-level agreement, which is why they sit above our £450 for one iOS app.

Pixelfield's worked example is the most useful comparison because it shows its working: 8 hours of engineering a month plus hosting and a reserve comes to £816 a month ^[11]. Our plan includes 4 hours of changes on top of the update, review and renewal work, which is where the difference lies.

How to build your own monthly figure

1. Start with the platform work. For an iOS app, budget for one significant rebuild a year when the new iOS and Xcode arrive, plus two or three smaller updates for Apple's rule changes and bug fixes. On a plan like ours this is what the fixed fee covers. On an hourly basis, Pixelfield's 8 hours a month at £80 is a fair planning figure for a small app ^[11], and chilliapple's £60 to £150 an hour shows the range of UK rates ^[8].
2. Add Apple's fee. 99 USD a year, or the local equivalent ^[3]. Keep it in your name.
3. Add hosting and services, if the app has a backend. Cuefold has no server of its own apart from our analytics service, so its hosting line is close to zero. An app with accounts, sync or payments is different. Nordstone suggests £100 to £300 a month for a lightweight MVP ^[9] and Pixelfield uses £60 for its small example and £250 for its complex one ^[11]. Add a line for each paid SDK or service: crash reporting, push, analytics, email, maps.
4. Add the Android version, if you have one. Most published monthly prices above include both platforms; ours covers iOS and quotes Android separately. Either way, two platforms are not twice the work but they are not one platform's work either.
5. Add a reserve for the unplanned. Pixelfield uses 15% of engineering ^[11]. We think that is sensible for the first year, when the surprises are largest.
6. Decide who does the small changes. Copy tweaks, a new screenshot, a price change, a new onboarding line. If they are in the plan, as they are in ours, the budget is predictable. If they are billed hourly, they are where the budget drifts.
7. Check the plan covers the moments that block you. The expensive failures are not the hours; they are the week the app cannot be updated because the certificate expired, the membership lapsed, or the build no longer meets Apple's SDK floor. Any plan worth paying for owns those dates.

A worked example for a small single-platform app on our plan: £450 for App care, roughly £6 to £7 a month for Apple's fee at current exchange rates, nothing or a few pounds for hosting, and a reserve of around £70 for the first year. Roughly £530 a month, or about £6,400 a year, with the first-year reserve dropping out after that. For an app with a backend and an Android version, the published UK figures above suggest £1,000 to £2,500 a month is realistic.

What happens if you spend nothing

We take over apps that have had no maintenance for a year or more, so we see the result. Usually the app still runs, which is why nobody noticed. Then one of three things happens: a new iOS release breaks something visible; the owner needs a change and finds the project will not build with current Xcode or will not upload under Apple's SDK rules ^[1]; or the membership lapses and the app leaves the store ^[4]. At that point the bill is the year of skipped maintenance plus the urgent fix, with the app offline while it is done.

The cheapest maintenance plan is the one that starts the month the app launches, when the code is fresh and the people who built it are still around. If that moment has passed, a takeover audit is the way back to a predictable monthly figure.