How to check whether the apps you recommend still exist

The problem is that nothing tells you

When an app closes, nobody writes to the pages that recommend it. There is no notification, no redirect, and no obligation on anyone to propagate the news. A page written carefully in 2022 quietly becomes wrong in 2025 and looks exactly the same.

Worse, the usual safeguards miss it. A broken-link checker tests whether a URL returns a page — and a withdrawn app’s App Store listing very often still returns a page. The failure only appears after somebody installs the app and cannot get in.

Three distinct things can go wrong, and they need different fixes:

The middle row is the one that causes real damage. Deleting a working app because its old link died removes a resource that people needed.

Step 1 — test every link against Apple’s own lookup

Every App Store URL contains a numeric ID, the part after id. Apple publishes a free lookup endpoint that needs no key and no account. If it returns "resultCount":0, the listing is not available.

curl -s "https://itunes.apple.com/lookup?id=1060691513&country=us"

To do a whole page at once, pull the IDs out of it first:

curl -s https://example.edu/counseling/apps.html \
  | grep -oE 'id[0-9]{6,}' | sort -u \
  | while read i; do
      n=$(curl -s "https://itunes.apple.com/lookup?${i/id/id=}&country=us" \
          | grep -o '"trackName":"[^"]*"' | head -1)
      echo "${i}  ${n:-*** NOT AVAILABLE ***}"
    done

Two things that will mislead you

• Check more than one storefront. Availability is per country. An app that returns nothing in country=us may be perfectly alive in gb or de. A single zero is not a conclusion.
• A single zero can simply be a blip. The endpoint occasionally returns resultCount:0 for an app that is demonstrably on sale. Re-run it before you write anything down.

Step 1b — do the same on Android, because an app can die on one platform only

This page checked Apple only for a long time, for the boring reason that Apple has a lookup API and Google does not. That was a real gap, and here is the case that exposed it.

On a university counselling page listing four apps, Breathe2Relax was alive on the App Store — current, published by the US Defense Health Agency — and its Google Play page returned 404. The iPhone link worked. The Android link did not. On the same page, two other apps were gone from both stores, and only checking both revealed which was which.

The split runs in the other direction too: on a school counselling page, an app’s Android listing had gone while its iPhone link still worked perfectly.

Neither is visible if you check on the phone you happen to be holding. And a page like yours is almost always checked on one device, by one person, once.

There is no API, so fetch the page and read the status — with a control package, exactly as you use a control ID on Apple:

curl -sL -o /dev/null -w '%{http_code}\n' \
  "https://play.google.com/store/apps/details?id=<package>"

The caveat, stated plainly, because this evidence is weaker than Apple’s. Google Play returns 404 for an app that is unavailable in your region as well as for one that has been removed. So a Play 404 is a strong signal, not a proof, and it is not as solid as resultCount:0 across five Apple storefronts. Where it matters, say “the Android listing does not load from here” rather than “the Android app is gone”.

Step 2 — check your PDFs, because nothing else does

This is the single most useful thing on this page. Handouts, printable guides and orientation packs are where dead links survive longest, because no link checker crawls a PDF, and because a printed copy cannot be corrected at all.

In one counselling-centre handout examined for this page, 11 of its 30 App Store links were dead. The same organisation’s website was in far better shape. The PDF had simply never been part of any check.

You do not need a PDF library to look. App Store links sit in the raw bytes as /URI entries:

curl -s https://example.edu/handout.pdf | strings | grep -oE 'https?://[^ )]*apple[^ )]*'

Step 3 — find every page that links a dead app

Once you know an ID is dead, search for the ID itself, in quotes, in any search engine:

"id825099621"

This works far better than searching the app’s name, because nobody writes an App Store ID anywhere except inside a link. One such search returned five separate institutions still linking the same withdrawn app.

A correction to what this page said before. It used to claim the search has “no false positives by construction”. That is wrong, and the reason is worth knowing.

The construction argument only holds if the index is current. It is often not. A search on one dead ID returned three institutional pages; none of the three actually contained it — one was unreadable, and the two that fetched cleanly had zero occurrences. The index was describing pages by content they had already removed. That has now happened six separate times during this work, on six unrelated queries.

So the rule is: treat every hit as a candidate to fetch, never as a confirmed carrier. Open the page and search it yourself before you write to anybody. The search is still the best way to find candidates — it just does not certify them.

The useful side-effect of the index lagging: some of those pages had already been fixed. That is worth knowing before you send a correction for something somebody dealt with last month.

If you run a large site, this is also the fastest way to audit yourself: add site:yourdomain.edu to the same query.

Step 4 — relink rather than delete, and mind the deadlines

The tidy reaction is to delete the entry. It is often the wrong one.

• If the app moved, find the current listing by searching the app name in the App Store and confirm the developer matches. Then update the ID. The resource is still good; only the address changed.
• If the app is closing but has not closed yet, do not just remove the page. People who wrote things in it may lose them. Leave the entry up briefly with a line telling them how to export, and remove it after the deadline. A user who never sees the notice loses their journal, and quietly deleting the page guarantees they never see it.
• If the app is gone with no successor, say so plainly rather than substituting something that looks similar. “This app is no longer available” is more useful than a replacement nobody vetted.

If the dead entry was free, check that the replacement still is

This is the trap waiting at the end of the job, and it is easy to walk into because the replacement genuinely was free once.

Looking for something to put in place of a closed free anxiety programme, the obvious candidates are the well-known university and health-service ones. One of them, THIS WAY UP, is excellent and widely cited. Its own page says the self-directed course is “$59 or covered by your private health insurance”, and free only “requires a prescription from a clinician”. Listing it under a heading that said “free” would have been wrong, and wrong in the direction that wastes a reader’s time when they are already struggling.

MoodGYM is the same shape of risk from the other direction: the phrase “freely available” appears on its site inside the title of a 2016 research paper. That is a citation, not a price. Its current terms could not be established from the public pages at all, so it is not listed here either.

The rule is short. A price is a fact about today, and reputation is not evidence of it. Read the provider’s own current pricing page before you write “free” next to anything — and if you cannot find one, say the cost is unclear rather than guessing in the generous direction.

Step 5 — the other links on the page, which are the ones that hurt

Steps 1 to 4 are about store links. A resource page is mostly not store links: it is charities, crisis directories, safety-plan tools, developer websites. Those fail differently, and worse, because the failures return 200.

Decode the URL before you request it

Take this one seriously, because getting it wrong causes the most damage of anything on this page.

An address written in HTML is not the address a browser sends. A URL with two parameters is written in the source with the ampersand escaped:

href="https://example.org/page.php?m=article&ID=50966"

The browser requests it with a real &. A script that scrapes hrefs and feeds them to curl without decoding requests the literal string, and a site that ignores the malformed parameter will quietly serve you its homepage with a 200. Your report then says the link redirects to the site root — which reads exactly like a page that has been removed.

This happened during an audit written up for this site. The link flagged as broken was a university’s safety-planning tool. Requested correctly, it returns 200 and the page is titled “My Safety Plan”. It works. Acting on the uncaught version would have meant persuading a counselling service to delete a working safety plan on the strength of a report that looked rigorous.

So: decode entities before you request anything, and when a link appears to fall back to a homepage, open it in a browser before you write it down.

A 200 is not an arrival — compare the URL you got to the one you asked for

The status code tells you a server answered. It does not tell you it answered with the thing you asked for. Two shapes to watch, both real, both found on live institutional pages:

• The deep link that lands on a homepage. A link to a crisis-centre directory returned 200 and dropped silently to the organisation’s front page. The directory is not at that address any more. For a crisis resource that is the worst possible failure, because it is invisible and it happens at the worst possible moment.
• The domain that answers for everything. When an organisation winds down, its site is often replaced by a single notice served for every path. /resources/, /articles/, a subdomain — all 200, all the same page. Every link you have to that organisation passes a link check on the day it stops working.

The check costs one flag. Ask curl what it actually reached:

curl -sL -o /dev/null -w '%{http_code}  %{url_effective}\n' "$URL"

If url_effective is a bare domain and you asked for a path, that is worth investigating — but do not report it until you have opened it in a browser, because there is one common case where it is completely wrong.

The exception, added after it nearly caused a 61-link false positive

Many library catalogues, repositories and databases route entirely on the client. The permalink is real, but the page that resolves it is JavaScript: the server returns the application shell, and the record is fetched afterwards. To curl this looks identical to a deep link collapsing to a homepage.

Auditing a college library’s health and wellbeing guide, every one of its 61 catalogue permalinks appeared to drop to the catalogue root. By the rule above, that is 61 broken links and an alarming email to a librarian. Opened in a browser, the first one resolved instantly to the right record — a different URL again, carrying the document id. Nothing was broken. Nothing had ever been broken.

So the rule needs its exception stated plainly: a drop to the root is a signal to look, not a finding. If it happens to one link on a page, it is probably real. If it happens to every link that shares a host, you have found a single-page application, not sixty-one faults — and the fastest way to tell the difference is to open one of them yourself.

Two smaller ones, from the same sweeps

• The scheme is part of the address. Two well-known charity apps publish short domains that answer on http and refuse connections on https. Checking one scheme tells you nothing about the other — and pages usually write https.
• Check the organisation, not only the app. A recommendation has two parts: the thing, and the reason to trust the thing. They expire independently. An app can be updated last week while the charity your sentence cites as its warrant has been wound up for months. No store lookup will ever mention it.

Step 5 — check the developer’s website, not just the store link

Steps 1 to 4 check one link. Most resource pages carry a second one — the developer’s own site — and it fails in ways the store never shows you. Apple publishes that address as sellerUrl, which is also what the Developer Website button on the listing uses, so it comes out of the same lookup you already ran:

curl -s "https://itunes.apple.com/lookup?id=1019230398&country=us" \
  | grep -o '"sellerUrl":"[^"]*"'

Then fetch that exact address and look at where you land. Three failures show up here and nowhere else:

• The 200 that is the wrong company. The ID above is Moodnotes, whose listed site thriveport.com redirects to bendingspoons.com — a corporate homepage that does not mention the app anywhere. Nothing is broken. The destination has simply stopped being about the product, and no link checker will ever tell you.
• The domain that is held but dark. A domain can keep its nameservers and serve nothing at all. That is neither alive nor expired, and it is indistinguishable from a network problem at your end unless you resolve DNS separately from the fetch.
• HTTPS refused while HTTP works. Your browser quietly falls back and the site looks fine; a link to the https:// form does not open. Check both schemes explicitly — http://x tells you nothing about https://x when nothing is listening on port 443.

Two cautions, both learned the hard way while compiling the list. A 403 is not a dead site — it is the site refusing your script, and it belongs in your notes as unknown rather than broken. And a status code is a moment, not a fact: on this sweep one perfectly healthy site returned 504 on the first pass and 200 twenty minutes later. Re-check anything you are about to delete over.

Worked results for every app on the list, including which sites fail and which only look like they do, are on the checked list.

A worked example that trips every trap at once

Virtual Hope Box is a coping-skills app for service members and veterans, published by the US Defense Health Agency. It appears on a great many institutional resource pages under the ID 825099621. Checked on 26 August 2026:

Three separate lessons fall out of one app:

• Had you checked only the US store, you would have called it dead. It is not dead; it is withdrawn from most storefronts and still listed in Australia.
• Had you checked only Australia, you would have called it fine. It resolves — to a build last touched in 2018. A link that returns a page is not the same as a maintained app.
• The right fix is neither delete nor leave alone. A current, maintained listing exists under a different ID. Relink to it.

This is also why the search in step 3 matters. Every page still pointing at 825099621 is sending people to something withdrawn or eight years stale, and nobody has told any of them.

The “(new)” tell

Some publishers do not update an app. They publish a second one beside it and abandon the first, which leaves the old listing’s ID alive in every page that ever linked it while all the maintenance happens somewhere else.

You can often spot it in the app’s own name. Listing the US App Store catalogue of the Defense Health Agency on 26 August 2026 returns six apps, and three of them are named “(new)”:

• Virtual Hope Box (new) — id6477622019
• Dream EZ (new) — id6744124763
• Provider Resilience (new) — id6758460542

Each of those names implies an older listing that pages are still pointing at, and these are among the most widely recommended apps on counselling, veteran and student resource pages.

Check a publisher’s whole catalogue in one request

Take the developer ID out of any apps.apple.com/…/developer/…/id… URL and ask the same endpoint for everything they publish:

curl -s "https://itunes.apple.com/lookup?id=1264687017&entity=software&limit=60&country=us"

If an app on your page is missing from that list, or appears there with “(new)” appended, your link is almost certainly the abandoned one.

Do this once per publisher rather than once per app. One agency, one request, and every app of theirs on your page is checked at once.

What this method cannot tell you

• Whether an app is any good. This checks existence, not quality, evidence base or data handling. Those are separate questions and harder ones.
• Whether a listing that resolves is still usable. An app can remain in the store while its service is closed to new users, which no automated check will catch. That one needs a human to read the developer’s own announcements.
• Anything about Android. Google Play needs its own pass; the two platforms diverge, and an app can be alive on one and gone from the other.

Who wrote this, and why that matters

I make Relief, a CBT thought record for iOS. That is a conflict of interest and it is the reason I started checking these pages at all, so you should know it before you use anything here.

The method itself does not care what the answer is, which is why it is worth publishing. It will tell you a competitor of mine is alive just as readily as it tells you one is dead, and several of the checks above exist specifically because I got the answer wrong the first time and had to correct it.

If you find an error in this, or you run it and get a result that does not make sense, write to me. I would rather fix it than be quoted saying something wrong.

Step 6 — check what the directory you link to is selling now

Every step so far has been about apps. This one is about the intermediaries: the curated app libraries that resource pages link to instead of listing apps themselves. They look like the safe option — somebody else does the vetting, and the link points at an organisation rather than at a store listing that might vanish. That is exactly why nobody re-checks them.

Here is what I found on one, on 27 August 2026.

my-therappy.co.uk is a UK app library for stroke, brain-injury and speech-and-language rehabilitation. It presents itself as clinician-assessed — its app pages carry a “Clinician Rating”, and the site describes testing by a network of NHS clinicians. The library is intact and still working: two dozen app pages, real write-ups, the aphasia and speech-therapy apps you would expect to find.

The site also now carries gambling affiliate sections. Its navigation links to pages titled Non UK Casinos, Non GamStop Casinos and Betting Sites Not on GamStop, and that navigation appears on the app pages too, alongside the clinician ratings.

And the front door is gone. Requesting the site root does not return a homepage at all — it issues a redirect to the casino page:

$ curl -sIL "https://www.my-therappy.co.uk/"
HTTP/2 301
location: https://www.my-therappy.co.uk/non-uk-casinos
HTTP/2 200

Every form goes the same way — with www or without, over http or https, with a trailing slash or without. The app library is still there at its deeper paths, so a link to a specific app or condition page still lands where it should. But anyone who linked the site itself — which is how most resource pages link a directory — is now sending readers straight to a page of casino offers.

A link checker sees 200 and moves on. So did I, at first: I fetched the root with redirects followed, saw casino promotions, and wrote it up as “the homepage carries gambling adverts.” It does not carry them. It is them — and I only found that out by printing the redirect chain instead of the final page. If you take one habit from this section, make it -I and -L together: where a link ends up is a different question from what it returns.

I am describing what the pages contain, not who put it there or why. A domain can change hands; a section can be added by an operator who needs revenue; none of that is knowable from outside. What is knowable is what a reader arriving from your page sees.

Why this is worse than a dead link. GamStop is the United Kingdom’s gambling self-exclusion scheme: someone who wants to stop registers once and is blocked across licensed operators. “Not on GamStop” is a category defined by that block not applying. The audience routed to a site like this through rehabilitation resource pages includes people recovering from stroke and brain injury — a population in which changes to impulse control are a recognised clinical consequence.

A dead link fails visibly and wastes somebody’s time. This one works perfectly.

What to actually do

Fetch the directories you link to, not only the apps, and read what is on them now — including the navigation, which is where this appeared rather than in the body text:

curl -sL "https://example.org/" | grep -oiE '>[^<]{0,40}(casino|betting|gambling|bonus)[^<]{0,40}<'

That grep is deliberately narrow, and the general version is simply to open the page. The point is not this keyword set. It is that an intermediary is a page like any other, and the reason it feels safe to link is the same reason nobody looks at it twice.