My app works fine. Why would I pay for this?

Because the ground under it moves whether the app changes or not. iOS ships a major version every year and Apple periodically requires new builds against a current SDK. Google raises the target API level annually and stops accepting your updates if you fall behind. Certificates expire, developer accounts renew, dependencies break. None of that is caused by your app and all of it lands on your app.

What is included and what costs extra?

Included — crash fixes, security and dependency updates, store compliance work, OS compatibility, and small text and image changes within an agreed number of hours a month. Billed separately — new screens, new features, new integrations and the annual major-OS review. That split is written into the agreement rather than left to be argued about later.

How quickly do you respond when something breaks?

The standard commitment is a business-day response, with a faster window available at a higher rate because it changes how the work has to be staffed. Whichever you choose is written down with a number in it, so there is never a discussion about what was implied.

Can you take over an app someone else built?

Yes, and it starts with a paid review rather than a quote. We read the project files, work out how far behind the dependencies and the target API level are, check the state of both store accounts and the signing keys, and come back with a staged plan. An app untouched for a year is a different proposition from one left in good order.

What if you find something serious in that review?

We tell you, with the risk graded, before any work starts. Occasionally the honest answer is that a very old codebase costs more to drag forward than to replace, and if that is the case you should hear it from us at the review stage rather than three months into a retainer.

What do I get each month?

A release where one is warranted, and a one-page report — how many crashes there were, which were fixed, how many people are using the app, what changed in the stores' rules, and what is coming next month. Short, readable, and specific enough to act on.

Mobile & App Development

Keeping a live app alive

Crash triage, dependency and OS upgrades, store compliance and monthly releases — on a retainer with a written line between what is included and what is billed separately.

From: $300–$2,000/mo
Typical time: ongoing
Usually bought by: Any app owner

What this actually solves

An app is not a sign on a wall. It is software living inside two other companies' platforms, and those platforms change every year without asking you. Apple releases a major iOS version annually and periodically requires that new submissions be built against a current SDK. Google raises the target API level an app must meet on a schedule, and when your app falls below it, Play simply stops accepting your updates - the version already installed keeps running, but you are frozen out of fixing anything. Signing certificates expire. Provisioning profiles expire. The Apple developer membership renews annually, and if it lapses the app is removed from the store.

None of that is triggered by anything you did. It happens to a perfectly good app that nobody touched. And because it happens quietly, the first sign is usually a customer or a family member saying the app will not open — by which point the fix is urgent, several deferred upgrades have stacked on top of each other, and it costs several times what the scheduled version would have.

That is the case for a retainer. Not because software rots, but because the ground it stands on moves on a published schedule, and someone has to be watching the calendar.

What we do, and in what order

Takeover review. The project files, the dependency tree, the build configuration, the state of both store accounts, the signing keystore and certificates, and how far behind the target API level and the SDK versions are. Each risk graded low, medium or high. This is a paid piece of work in its own right and it is what any sensible arrangement starts with. Three to five days.
Stabilise, in stages, not all at once. The upgrade plan is sequenced so the app runs after every step and there is always a working state to return to. Where a framework has skipped several versions, the intermediate releases are gone through in order rather than jumped, because the breaking changes accumulate. One to three weeks, depending on how far behind things are.
Instrumentation and a renewal calendar. Sentry or Firebase Crashlytics reporting properly, and a dated calendar of everything that expires — certificates, provisioning profiles, the annual developer membership, and the published deadlines for target API level changes. It sounds administrative. It is the single item that prevents the worst failures in this service. Two days.
The monthly cycle. Read the crash reports and fix the top few by impact rather than by ease. Review dependencies and apply the updates that matter. Check what changed in each store's rules — this is quietly the most valuable half hour of the month. Ship a release. Send the one-page report. Two to five days a month, depending on the tier.
The annual major-OS pass. When a new iOS and a new Android arrive, the app is reviewed end to end against them, deprecations dealt with, and the target API level raised ahead of the deadline rather than after it. Scoped and billed separately from the retainer because it is a genuinely different piece of work. One to two weeks, once a year.

Tools — Sentry or Firebase Crashlytics, both store consoles, the build service the app already uses, git, and a shared calendar with the expiry dates on it.

What moves the price

The retainer runs $300–$2,000/mo and it is ongoing, because the platform deadlines it answers to are annual and never stop arriving. Three things decide the tier.

Size and usage. A five-screen app used by a few hundred people generates a different volume of crash reports, support questions and edge cases than a large app with tens of thousands of sessions a day. More usage means more real-world states, and more real-world states means more to keep working.

Response commitment. A business-day response and a same-day response are different products, because the faster one has to be staffed for it. If you need the shorter window, it is priced accordingly rather than promised and then quietly missed.

Included change hours. Retainers here include a set number of hours a month for small changes — copy, images, a tweak to an existing screen. A larger allowance costs more, and anything beyond it is billed at an hourly rate that is agreed in advance.

What usually goes wrong

Maintenance is never defined. You assume new features are included. The developer assumes only repairs are. By the third month there is a disagreement neither side can win, because nothing was written down. The fix is three explicit lists in the agreement — what is included, what is billed separately, and how fast a response is promised. It takes an afternoon to write and it prevents the most common falling-out in this entire category.

Nobody owns the renewal calendar. The Apple membership lapses and the app vanishes from the store overnight. Or a signing certificate expires the week an urgent fix is needed and the release cannot be built. These are diary entries, not engineering problems, and they cause more outright outages than bugs do.

Every dependency is updated in one go. It feels efficient — one big upgrade, one test pass. Then the app breaks and there are forty candidate causes and no way to isolate one. Upgrades here go one meaningful step at a time with a defined set of things to exercise after each, so that when something does break, the culprit is the change you just made.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

My app works fine. Why would I pay for this?: Because the ground under it moves whether the app changes or not. iOS ships a major version every year and Apple periodically requires new builds against a current SDK. Google raises the target API level annually and stops accepting your updates if you fall behind. Certificates expire, developer accounts renew, dependencies break. None of that is caused by your app and all of it lands on your app.
What is included and what costs extra?: Included — crash fixes, security and dependency updates, store compliance work, OS compatibility, and small text and image changes within an agreed number of hours a month. Billed separately — new screens, new features, new integrations and the annual major-OS review. That split is written into the agreement rather than left to be argued about later.
How quickly do you respond when something breaks?: The standard commitment is a business-day response, with a faster window available at a higher rate because it changes how the work has to be staffed. Whichever you choose is written down with a number in it, so there is never a discussion about what was implied.
Can you take over an app someone else built?: Yes, and it starts with a paid review rather than a quote. We read the project files, work out how far behind the dependencies and the target API level are, check the state of both store accounts and the signing keys, and come back with a staged plan. An app untouched for a year is a different proposition from one left in good order.
What if you find something serious in that review?: We tell you, with the risk graded, before any work starts. Occasionally the honest answer is that a very old codebase costs more to drag forward than to replace, and if that is the case you should hear it from us at the review stage rather than three months into a retainer.
What do I get each month?: A release where one is warranted, and a one-page report — how many crashes there were, which were fixed, how many people are using the app, what changed in the stores' rules, and what is coming next month. Short, readable, and specific enough to act on.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about App maintenance & releases All Mobile & App Development services