How to tell if a Shopify app is still maintained
An app does not announce when it stops being maintained — it just gets quieter. Seven things you can check in about ten minutes, and what each one tells you.
Every app store has an app that you have been meaning to uninstall. It stopped working sometime last year. You opened a ticket, got a reply that was helpful and slightly apologetic, and then nothing. It still appears in your admin. It still appears on your P&L.
There is no moment where an app says “I am no longer maintained.” It just gets quieter, and the cost of finding out is discovered later, in the worst possible way.
Here is how to check, in the order I would.
1. The version history is the whole answer
Go to the app’s listing. Most have a version history, and the dates are the signal. You are not looking for a big number — you are looking for a recent date.
| Last release | What it usually means |
|---|---|
| Under 3 months | Actively maintained |
| 3–9 months | Maintained, but slow. Fine for a stable app |
| 9–18 months | Read the support channels before you rely on it |
| Over 18 months | Assume unmaintained and plan a replacement |
An app that releases once a quarter with a changelog is doing the same work as one that releases weekly without a changelog. The cadence tells you whether someone is paying attention, not how exciting they are.
If the listing has no version history at all, that is itself information. The maintainer is not publishing, which means you are relying entirely on support responsiveness for your only signal.
2. Send a support ticket and time the reply
This is the most direct test available and it is the one most people skip because it feels rude. It is not rude — it is the support channel, and maintainers expect to hear from users.
Ask something small and specific. Not “does this work” but “does this handle products with more than 50 variants.” You are measuring two things:
- Whether they answer — days, not weeks
- Whether the answer is real — someone who knows the product answers the question; someone who inherited an inbox asks you for a screenshot
An app with an unresponsive support channel is an app where the next API version retirement will be handled the same way: eventually, or not at all.
3. Read the recent reviews, not the total
The review count is a popularity signal. The recent reviews are a maintenance signal, and the two point in different directions.
Scroll to the newest reviews, not the most helpful ones. You are reading for:
- Recency — reviews from the last few months
- Tone shift — a run of “used to work, doesn’t anymore”
- Developer responses — a maintainer replying to a bad review within a day is showing you they are still there
A run of recent one-star reviews with no developer response is the clearest possible signal, and it costs you thirty seconds to spot.
4. Check the listing screenshots against your actual admin
App listing screenshots age. The interface in the screenshot is often two years older than the interface in your admin, which means the maintainer has not been to the listing page in a long time.
This is cosmetic on its own, but it is a proxy: the listing page is the thing that converts installs, and a maintainer who has not updated it in two years is not actively working on the product’s front door. It is weak evidence, and it is still evidence.
5. Ask whether it supports the current API version
Settings → Apps and sales channels, then the app’s detail page. Shopify shows a compatibility indicator when an app is behind.
This is the check with the highest stakes and the lowest effort, because it is the failure that takes the store down rather than just the app. If an app is more than one version behind, treat its next migration as an assumption rather than a plan.
6. Look for a public changelog
Not the listing’s version history — an actual changelog, somewhere the maintainer puts release notes in words.
This is a strong signal and an unusual one. Publishing a changelog costs an author who cares about the work. A maintainer shipping quarterly migrations under a deadline will often skip it entirely.
It also tells you what kind of maintainer you are dealing with. An app whose release notes say “fixed a bug” every quarter is being maintained. An app whose notes describe what changed and why is being run. Both are fine; only one of them is a partnership.
7. Notice whether they tell you when something changes
Price increases, new data handling, new permissions, a new required configuration — does the app tell you before or after?
This is the least mechanical check and the most revealing. An app that emails you before it changes something, with enough notice to plan around, is an app built by someone who understands that your business depends on it. An app that changes terms silently and hopes you do not notice is telling you something about the next version too.
The short version
Maintained recent releases · fast, real support answers ·
responsive to recent reviews · current API version ·
public changelog · warns you before changing terms
You do not need all six. But an app with none of them is not a product you should depend on, however much you like it — and you will find out at the worst time, on the operation that mattered most.
If you would rather not maintain this yourself, the alternative is to build something you own. That has its own costs, honestly; I wrote about those here. But the point of the checklist above is that it applies to us too: everything on this site that ships, ships with a date on it, in a public changelog.
If an app already does this, install it. These are the ones we maintain.