An App Decays Even When Nobody Touches It
Web software sitting on a server you control can be left alone for years. A mobile app cannot. It lives on two platforms that ship a new major version every year, inside two stores that change their rules on their own schedule, on hardware that changes shape — and none of that waits for your roadmap.
Nothing You Did Caused This. The Ground Moved.
The most common support call we get starts with “we haven’t changed anything”. That is usually true, and it is also the problem. Six things move underneath a live app whether or not a single line of your code changes.
A Major OS Release Every Year
Apple and Google each ship a major version annually, and on iOS a large share of users are on it within weeks. Every release quietly retires an API, tightens a permission, changes how a system control is drawn, or alters when the operating system is willing to wake your app. The usual symptom is not a crash — it is one screen that now looks wrong, or a background refresh that silently stops running.
New Device Sizes and Aspect Ratios
Each hardware generation brings a screen a little taller, a cutout in a different place, a foldable that changes size mid-session, or a safe-area inset that was not there before. A layout that was pixel-perfect two years ago starts clipping a button behind a rounded corner or stranding a call-to-action below the fold on a tall handset. Nobody reports it; they just stop completing the flow.
Certificates and Profiles That Expire
Signing certificates, provisioning profiles, push notification keys and Android upload keys all have expiry dates, and they rarely expire at a convenient moment. The failure mode is nasty because it is invisible from the outside: the app in the store keeps running, push notifications stop arriving, and you discover the problem when you try to ship an urgent fix and cannot produce a build at all.
Store Policy and Target-API Deadlines
Both stores publish policy changes with compliance dates attached, and Google sets a minimum target API level that ratchets upward each year. Miss one and the punishment is not a warning email — it is your next update being refused, or in the worst case the listing becoming invisible to new devices. These deadlines are knowable months ahead, which is precisely why missing one is avoidable.
Third-Party SDKs Going Unmaintained
Every app carries someone else’s code: analytics, crash reporting, maps, payments, a chart library, an image loader. Some of those projects get abandoned, some get bought and relicensed, and some publish a breaking major version that the next OS release forces you onto. A dependency that has not been updated in two years is not stable, it is stranded, and the cost of moving off it grows every month it is left.
Backends and APIs Changing Underneath
Your own server gets deployed, a payment provider versions its API, a partner sunsets an endpoint, an SSL certificate rotates, a cloud function gets a new minimum runtime. On the web a bad deploy is reversible in minutes. On mobile the client is already on a hundred thousand phones and can only be changed by shipping a new build and waiting for people to install it, so backwards compatibility stops being a nicety and becomes a hard requirement.
A Year in the Life of a Live App
This is the rhythm of a typical year for an app in both stores. None of it is triggered by anything you do, and all of it arrives whether you have someone to handle it or not.
Conference Season — The Betas Land
Apple and Google announce the next OS versions and put developer betas out. This is the first moment you can find out whether next autumn breaks anything, and it is the cheapest moment to find out. We install the betas and run the app through its main journeys.
Summer — Beta Testing and Deprecation Notices
The beta cycle runs for months and the deprecation notes get more specific with each build. Anything that will need reworking is scheduled now, while there is no deadline attached, rather than in October when there is.
Autumn — The New iOS Ships and Adoption Is Fast
iOS adoption moves quickly, so an incompatibility that affects one screen can reach a large share of your users inside a fortnight. We ship a compatibility release close to the public launch rather than waiting for the reviews to tell us.
Autumn — New Flagship Handsets, New Geometry
New devices bring new screen dimensions, new safe areas and new display behaviours. Screenshots in your store listing may also need regenerating at the new sizes, which is a small job that only looks small until it is due in the same week as everything else.
Late Autumn — The Holiday Submission Slowdown
Both stores get slower and less forgiving around the end-of-year holidays, and Apple historically pauses new submissions for a stretch. Anything you want live before the new year has to be submitted with genuine slack in front of it, not on the last possible day.
Winter — Android Rollout Reaches the Long Tail
Android upgrades arrive device by device and manufacturer by manufacturer, so the new version keeps reaching new segments of your user base for months. This is usually when manufacturer-specific battery optimisation and background-work behaviour shows up in crash reports.
Annually — The Target API Level Ratchet
Google raises the minimum target API level that apps must build against in order to keep publishing updates. It is a fixed, published deadline and it is one of the most common reasons an otherwise healthy app suddenly cannot ship a fix.
Any Month — An Expiry You Forgot Existed
A distribution certificate, a provisioning profile, a push key, an API token, a domain, an SSL certificate. We keep a dated inventory of every one of them and renew ahead of the date instead of discovering it during an incident.
Any Month — A Policy Update With a Compliance Date
Privacy declarations, data-safety forms, permission justifications, account deletion requirements, advertising identifier rules. Each one is a small piece of work, each has a date, and the consequence of missing one is a rejected update at the worst possible time.
Continuously — Dependency Drift
Libraries publish patches, some of them security patches. We batch routine upgrades into a scheduled maintenance release every few weeks so the app never accumulates a two-year gap that has to be crossed in one terrifying jump.
Three Sizes, One Fixed Monthly Figure
All figures are indicative monthly amounts in US dollars and are confirmed in writing after we have seen the app. Each band is a fixed monthly fee, not an hourly meter, and the developer account fees and paid third-party services stay billed directly to you.
Upkeep
$750/month
Roughly 8 development hours. For a stable app with modest usage that mainly needs to stay publishable and watched.
- Certificate, profile and key inventory, renewed ahead of expiry
- OS compatibility testing against each new major release
- Store policy and target-API deadline tracking
- Crash reporting configured, watched and triaged
- Dependency and security patch releases, batched quarterly
- Defect fixes within the agreed scope
- A written monthly note on what changed and what is coming
Iterate
$2,200/month
Roughly 25 development hours. For an app with real users where small improvements ship continuously rather than once a year.
- Everything in Upkeep
- A scheduled release roughly every month, submitted by us
- Small features and copy, layout and flow changes
- Phased rollout on Android with monitored staged percentages
- Store listing refreshes and screenshot regeneration
- Performance work on cold start, app size and crash-free rate
- A monthly call plus a written update every working day we are on your app
Roadmap
$4,400/month
Roughly 50 development hours. For an app that carries revenue, where a bad release costs money and the backlog never empties.
- Everything in Iterate
- A named developer and a named point of contact
- Two-week cycles against a backlog you prioritise
- Beta channel maintained for your testers on both platforms
- Release-health monitoring with a rollback or halt plan per release
- Backend and API maintenance for services we built
- Quarterly review of analytics, retention and store performance
Indicative figures for planning. The hour counts are a guide to capacity, not a timesheet you get billed against — the fee is fixed and the work is prioritised with you.
What We Will Actually Commit To
Two numbers get confused in most support contracts. Response time is how long before a human reads it and tells you what is happening. Resolution time is how long before it is fixed. Only the first is fully within our control, so only the first is a promise.
| Severity | What it looks like | First response | Realistic resolution |
|---|---|---|---|
| Critical | App will not launch, sign-in is down, payments fail, a crash is hitting a large share of sessions | Within 4 working hours | Work starts the same working day and does not stop; a store release still has to clear review before users get it |
| High | A main feature is broken on one platform or one OS version, push notifications have stopped, a build cannot be produced | Within 1 working day | Typically inside the same week, shipped with the next release |
| Normal | A defect with a workaround, a layout problem on specific devices, a slow screen | Within 2 working days | Scheduled into the next planned release |
| Low | Cosmetic issues, copy changes, small requests, questions | Within 2 working days | Batched into a future release |
Where the Honesty Matters
We can commit to when we start. We cannot commit to when a fix reaches your users, because a mobile fix has to go through a store before anyone can install it. An expedited review can help in a genuine emergency and we will request one, but it is a request, not a lever. This is the single biggest difference between supporting an app and supporting a website, and anyone quoting you a guaranteed end-to-end resolution time for a store-distributed app is quoting you something they do not control.
What We Will Not Claim
- No staffed 24/7 on-call rotation. There is no overnight pager here.
- No uptime percentage for the store listing — that is Apple’s and Google’s infrastructure, not ours.
- No guaranteed review turnaround. We can prepare a clean submission; we cannot schedule a reviewer.
- No promise that a policy change will not force unplanned work. We can only see it coming early.
Most Users Never Report a Crash. They Just Leave.
A tiny fraction of people who hit a broken screen will write to you about it. The rest uninstall, or leave a one-star review three weeks later that says nothing useful. That is why crash reporting is the first thing we set up on any app we take over, and why the retainer includes someone actually reading it rather than simply switching it on.
- Crash and non-fatal error reporting wired into both platforms, with release and device dimensions attached
- Crash-free session rate tracked per release, so a regression is visible as a drop rather than as a review
- New issues triaged by how many real users they affect, not by how alarming the stack trace looks
- Android vitals and iOS metrics watched for ANRs, excessive wakeups, battery and cold-start regressions
- Store reviews scanned for the reproducible bug reports buried among the ratings
- Every release rolled out in stages on Android and halted if the crash rate moves the wrong way
Inside the Retainer, and Outside It
The line is drawn before you sign rather than argued about later. If something sits on the boundary we tell you which side we think it falls and why, before starting.
Always Included
Keeping the App Publishable
- Certificate, profile and signing key renewals
- Compatibility work for new iOS and Android releases
- Target API level and store policy compliance
- Defect fixes inside the accepted scope
- Crash monitoring and triage
- Security patches for dependencies
- Submitting releases and answering review feedback
Sized by Band
Improvement Capacity
- Small features and changes to existing flows
- Copy, layout, iconography and onboarding tweaks
- Store listing and screenshot refreshes
- Performance work on start-up time and app size
- Additional device coverage in testing
- Analytics events added as questions come up
Quoted Separately
Work With Its Own Shape
- A new module or a major feature needing its own design pass
- Adding a second platform to a single-platform app
- A full visual redesign or a migration to a new UI framework
- Wearable, tablet or TV companion apps
- A new backend, or a significant rework of an existing one
- The initial handover review on an app we did not build
Not a Retainer Item
Outside Our Control or Our Remit
- Apple and Google developer account fees
- Paid third-party APIs, maps, SMS and payment processing fees
- Cloud hosting, storage and bandwidth bills
- Paid user acquisition, ad spend and influencer work
- Customer support for your end users
- Overnight, weekend and public holiday cover
Support Questions, Answered Straight
Do you offer 24/7 emergency cover?
No, and we would rather say so plainly than bury it. There is no staffed on-call rotation here and no overnight pager. We work Monday to Friday, 10:00–19:00 IST, and a genuine production outage raised outside those hours is picked up at the start of the next working day. If your app carries payments or clinical data and you need a human awake at 03:00, you need a provider with three shifts and a formal on-call roster, and we will tell you that on the first call rather than sell you a plan that cannot deliver it.
What is the minimum term, and can we stop?
Retainers run month to month after an initial three months, and the three months exist because the first month is mostly discovery — reading the code, wiring up crash reporting, checking what is expiring and building the release pipeline. Give us thirty days of notice and the plan ends. There is no exit fee and nothing is withheld: the accounts, the signing keys, the repository and the release documentation are already yours and already in your name.
Do unused hours carry over to next month?
One month forward, and no further. A quiet month can lend its unused capacity to the month that follows it, which covers the normal case where a feature slips a couple of weeks. What we do not do is let six quiet months bank into a six-month project, because the retainer pays for a team holding capacity for you, not for a block of hours sitting in a drawer. If you know a larger piece of work is coming, it is cheaper to scope it as a fixed-price project alongside the retainer.
Will you take on an app your team did not build?
Usually yes, after a paid handover review. We spend a fixed number of days reading the codebase, building it from a clean checkout, checking which dependencies are abandoned, confirming that the signing keys and store accounts actually exist and are reachable, and writing up what we find. Sometimes the verdict is that the app is in good shape and the retainer starts the following week. Sometimes it is that the build cannot be reproduced at all, in which case a rebuild is cheaper than maintaining something nobody can compile. You get the written verdict either way.
What counts as a defect fix and what counts as a new feature?
A defect is the app not doing what it was specified and accepted as doing — a crash, a screen that will not load, a payment that fails, a layout that breaks on a device we agreed to support. Those are fixed inside the retainer at no additional charge. A feature is the app doing something new: a screen that did not exist, an integration that was never in scope, a second language. Small features fit inside the monthly capacity on the larger bands. Anything that needs its own design pass and more than a couple of weeks becomes a quoted project, and we say which it is before starting rather than after.
Does the retainer cover the App Store and Play Store fees?
No. Apple and Google each charge their own developer account fees directly to you, on their own renewal cycles, and those accounts stay in your company name so the billing relationship is yours. The same goes for paid third-party services the app depends on — maps, push infrastructure, error reporting above the free tier, SMS, payment processing. We will tell you what they cost before you commit to any of them, and we will warn you when a renewal is due, but we do not mark them up and we do not pay them on your behalf.
What happens if we let the retainer lapse?
Nothing dramatic on day one, which is exactly what makes it dangerous. The app carries on working for a while, then a certificate expires and push notifications quietly stop, or a store deadline passes and updates get refused, or a new OS release breaks a screen and the reviews start. Twelve to eighteen months without maintenance is usually when it becomes visible to real users. If you stop the plan we hand over a written state-of-the-app note covering what is expiring when, so whoever picks it up next is not starting blind.
Can we start a retainer before the app is finished?
It is better to start it at launch rather than before. Everything up to store approval is covered by the build engagement and its defect-fix window, so paying a retainer on top of that is paying twice for the same cover. The sensible sequence is to agree the plan during the final build sprint and have it begin the day the app goes live, which is also the point where crash reporting starts producing data worth looking at.
Put Someone Behind Your Live App
Tell us what is in the stores now — whether we built it or not — and we will come back with what is expiring, what is out of date and which band actually fits.