When should you kill an app?
Every indie portfolio eventually grows one: the app that still works, still gets a download or two a week, and hasn't been meaningfully touched in a year. Killing it feels like admitting failure. Keeping it feels free. Both instincts are wrong — and both stores have quietly taken a side.
The stores already vote against zombie apps
The old mental model — ship it, forget it, let it earn a trickle forever — stopped being true years ago. Apple's App Store Improvements process flags any app that hasn't been updated in three years and has been downloaded rarely or not at all over a rolling twelve-month period. You get an email and 90 days to ship an update; otherwise the app comes off the store. (It keeps working for people who already have it.)
Google is stricter and quieter about it. Play's target API level policy means an existing app that falls more than two years behind the latest Android release simply stops being shown to new users on newer devices — no email drama, it just fades out of reach for most of the market. And staying inside the window isn't a checkbox: each year's deadline means a real update against a new SDK, new build tooling, and whatever permission behavior changed underneath you.
Add the $99-a-year Apple developer fee, the annual privacy-form ritual, and the crash report from an OS version you no longer own a test device for, and the honest accounting is this: an untouched app now decays by policy, not just by entropy. "It costs nothing to leave it up" is no longer one of your options. The real choice is between maintaining it and ending it.
Dead or just unmarketed?
Before you decide, separate the two verdicts a quiet app is serving you, because they call for opposite responses. One question is whether anyone finds the app. The other is whether the people who find it stay. Downloads answer the first. Retention of the organic trickle answers the second — and the trickle is a real sample, even at ten installs a week. Open your analytics and look at just those users: do any of them come back in week two? Do any ever pay?
If strangers who wander in keep using the thing, the app isn't dead — it's unmarketed. That's a distribution problem, and distribution problems respond to deliberate effort: a listing rebuild, a channel you haven't tried, a keyword set that matches what people actually type. Killing a retaining app because it's invisible is burying a patient with a curable disease.
If they don't stick, no channel will save it. Marketing multiplies exposure to whatever experience exists; it can't change what that experience is. This is the case where "I just need to promote it more" becomes an expensive way to avoid a conclusion you already have the data for.
What keeping it actually costs you
The line item that never shows up in the spreadsheet is attention. Every dormant app is a standing subscription of interruptions: the target-API deadline email, the OS beta that breaks a plugin, the one-star review you can't answer with a fix because rebuilding the toolchain would eat a weekend. Each interruption is small; the context switch out of the project you actually believe in is not. Three quiet apps add up to a recurring part-time job of compliance that pays in guilt.
One honest swing before you decide
If the retention data says "unmarketed" — or if you genuinely don't have enough arrivals to read it — give the app one timeboxed swing before the funeral. Six weeks, defined in advance. Rebuild the listing like it's launch week: screenshots that lead with the outcome instead of raw UI, a name-and-subtitle pair that says what the app does, and one external channel you haven't burned yet to push a real sample of strangers through it. (The listing rebuild is the cheap half — a full screenshot set is an afternoon in ShotCanvas, not a month of your life.)
Then read the two numbers the experiment was designed to produce. If page conversion improved and the new arrivals stick, you've found an app worth maintaining — the problem was always upstream of the product. If conversion improved and they still leave, you've bought certainty: it's the product, and you can close the case without wondering.
How to kill one properly
Removing an app from sale is gentler than it sounds. On Apple's store, people who already have the app keep it, and it keeps working. On Google Play, previous installers can still re-install it. Pulling the listing mostly means no new strangers wander into a product you've stopped standing behind — which is the responsible outcome, not the cruel one.
Wind it down in this order. Stop paying for new users first — ads, referral links, anything still funneling people in. Then turn off new purchases and subscriptions and let existing paid time run out; nobody should start paying for a product that's ending. Put a plain notice in the app with a date and, if you hold user data, an export path. Only then remove it from sale. And keep the account-deletion flow alive after the listing is gone — the delete-account requirement attaches to the data you hold, not to whether the app is still on sale.
Decide with data, not guilt
The reason quiet apps stay up for years isn't strategy — it's that killing one feels like retroactively deleting the months it took to build. But the build was the tuition, and it's already paid. The only live question is whether next year's maintenance buys anything. If the answer is yes, treat the app like it matters, starting with the page that sells it. If the answer is no, closing it well is its own kind of shipping.