Which CBT apps still exist?

Why this page exists

Two apps that appear on current roundups, and on university and charity resource pages, cannot be used by a member of the public who follows the link:

• Woebot — Woebot Health retired the consumer app on 30 June 2025 and moved to an enterprise model; access now needs a code from a partner organisation. Reported at the time by MobiHealthNews and STAT, and described in Woebot Health’s own FAQ.
  The two platforms have since diverged, which is worth knowing if you maintain a page that links both. On Android it is simply gone: on 25 August 2026 both play.google.com/store/apps/details?id=com.woebot and the Woebot Health Inc developer page returned 404, checked three times, while a control app returned 200 on the same request. On iOS the listing still exists, which is exactly what lets a broken recommendation survive a link check.
• Sanvello, formerly Pacifica — removed from the App Store and Google Play in June 2024, and now AbleTo SelfCare+, open to members only.
• Youper — already out of both stores, and closing. Its own homepage says “Youper is shutting down September 30, 2026 — export your data”, and the company states that accounts, chat histories and personal data are permanently deleted from its servers and backups from 1 October. The export route is start.youper.ai/export-data, which still loaded on 30 August 2026. By that date the iOS listing had gone from the us, gb, ca and au storefronts — Apple’s lookup API returns zero results for id1060691513 in all four, and a name search returns no Youper at all. Install has closed while export is still open, so anyone who deleted the app or changed phones cannot reinstall it to rescue their writing before 30 September. Full detail, including what happens on 1 October and what to use instead, is on the Youper page.
  If you recommend it anywhere, the useful response is probably not to delete the entry but to leave it up briefly with a line about the export. Someone who never sees the notice loses their writing. It is also already out of the App Store, so it does not turn up in a search — which means people who still have it installed may not know any of this is happening.

Nobody maintains a list of which of these tools are still alive, so stale recommendations sit on trusted pages for years. This is an attempt at one.

What is on the store, and when it was last updated

Checked 25 August 2026, United States storefront, and every row re-verified on 27 August 2026. The dates are Apple’s own last updated values, not an opinion about quality. On the re-check, 26 of 28 rows were unchanged; two apps had shipped an update since, and one publisher name was wrong and has been corrected.

The list covers what university counselling centres, hospitals and helplines actually put on their resource pages, rather than what a roundup ranks — so meditation and mood trackers appear next to thought records, because that is how those pages are written.

This table is iOS. Android was not swept, because an iOS bundle identifier is not an Android package name and guessing one produces false negatives — a guessed package for MindShift returned 404 here, and MindShift is perfectly healthy. The single Android fact below is stated because it was checked directly, not inferred.

A recent date means somebody shipped a build. It does not mean the app is good, and an old date does not mean it is broken — a finished tool can sit still. What it tells you is whether anyone is still there.

Apps that moved rather than died

This is the mistake I keep finding on resource pages, and it is the expensive one. A link stops working, somebody sensibly deletes the row — and a working, free app disappears off a page that students or clients rely on.

Three apps have changed listing rather than shut down. In each case the old link is dead and the app is fine. Relink; do not delete.

The first two are suicide-prevention and safety-planning tools, which is why they are at the top of the table rather than sorted alphabetically. Both are free. Both are published by organisations that are still very much operating. Both are currently linked, and broken, on university pages I have checked this week.

The general rule, if you maintain a page like that: a dead link is a question, not an answer. Search the app’s name and its publisher’s name before removing anything. “I could not find it” and “it is gone” are different statements, and only one of them is something you know.

Apps that were renamed in place

The table above is about links that break. This one is about a link that keeps working while the text around it quietly stops being true — which is harder to catch, because nothing fails a link check.

Pocketcoach is now Stresscoach. Same App Store ID, same app, new name, and a new company name to match. The bundle identifier is still co.pocketcoach.app, which is what proves the lineage.

If your page says “Pocketcoach” and links this ID, the link is fine and nothing is broken. A reader who taps it simply lands on an app with a different name, and reasonably concludes they have been sent to the wrong place. The fix is one word in your text, not a new link.

A worse version of the same problem: the name splits in two. Pocketcoach renamed itself and left its old name unused. 10% Happier did not.

The app that pages recommend as “10% Happier” is now Happier Meditation — id992210239, still published by Happier Meditation, Inc., and its website has moved from tenpercent.com to meditatehappier.com. So far this is an ordinary rename.

But there is now also a separate, newer app called “10% with Dan Harris”, id6755701096, from a different publisher, 10 Percent Media LLC. Both are live in every storefront checked.

That combination is the trap. If your page links the old ID, the link still works and only the name in your text is stale. If your page names the app without linking it — and a great many do — then a reader searching the words on your page today finds the newer app, not the one you meant, and nothing anywhere signals the substitution. The same shape appears in the table above with MoodKit, where the original is dead and the name lives on under someone else.

The general rule this points at: a name you do not link is a search query you are handing to your reader, and you do not control what it returns next year.

MoodKit is the same shape, and it is the reason the rule is worth stating twice. Thriveport’s MoodKit — the CBT tool that university counselling pages have recommended for years, with activities, a thought checker, a mood rater and a journal — is gone from the App Store. The name is not. A different publisher now ships MoodKit – Mood Tracker & Diary, id6758397003, by Suradeth Chaipin. It is a mood tracker, not the CBT toolkit the descriptions on those pages are describing.

If your page names MoodKit without linking it, that is where your reader now lands.

What I could not establish here, and what I did about it

I cannot tell you Thriveport’s original App Store ID with confidence. Two plausible numbers circulate on third-party pages, both of which now return nothing from Apple in every storefront I checked — so the lookup cannot arbitrate between them, and no archived store page survives at either address to settle it.

I had briefly published one of them here as MoodKit’s. That was a guess wearing the clothes of a fact, and it is the exact mistake the rest of this page tells you to avoid: an ID is an identifier, and a nearly-right identifier is simply a different app. The number has been moved to the unnamed list below, where it belongs — confirmed dead, honestly unlabelled — and the MoodKit case is made above using only what can be shown: the original is gone, and the name is now somebody else’s.

This matters for how you use this page. Search your own text for the numbers and trust those. Treat the names beside them as my labels, useful for recognising an entry, not as evidence.

Two things here matter more than the single app.

The first is that a store title is not one thing. The same ID is “Sorgen loslassen” in Switzerland, Germany and Austria, and “Anxiety Helper” in the United Kingdom. Checking a name against a store is therefore storefront-dependent, and two people can both be right about what an app is called.

The second is a limit of this page, stated because a list that hides its gaps is worse than no list. The table further up was swept on the United States storefront, and Stresscoach is not available in the United States at all — the lookup returns nothing there. It is live in ch, de, at and gb. So this app is invisible to the method this page uses, while being actively recommended on European resource pages: it turned up here only because it was a live link in a Swiss consumer magazine’s health article.

The general rule, to sit beside the one above: a working link is not a checked link, and a US sweep is not a world sweep. If your readers are not in the United States, check the storefront they actually use.

What happened when the sweep was actually run

Update, 26 August 2026. Rather than leave that as a caveat, every app in the table above was re-checked on five storefronts — us, gb, de, ch and es. The result argues against the strong version of my own warning, so here it is:

26 of 27 apps were available on all five. For apps that are on this list, US availability turned out to predict European availability almost perfectly. The single exception is Breathwrk, which is missing in Switzerland and present in the other four.

So the caveat needs restating more precisely, because the loose version was misleading. The risk is not that a listed app quietly vanishes from your storefront — that is rare. The risk is a selection effect: an app that is not sold in the United States never enters a US-swept list in the first place. Stresscoach is exactly that case. It is live in ch, de, at and gb, recommended in European health coverage, and it is absent from the table above purely because the sweep that built the table could not see it.

A list built on one storefront is not missing entries at random. It is missing precisely the apps that storefront does not sell, and that is invisible from the inside.

One more kind of change: the publisher moved

The same re-check turned up a third variant, distinct from a dead link and from a rename. Breathwrk is now published by Peloton Interactive, Inc. The name is unchanged, the ID is unchanged, the link works, and the app is the same one — the bundle identifier is still com.breathwrk.ios. What changed is who stands behind it.

That matters if your page says “from Breathwrk, Inc.”, and it matters more if your organisation vets tools by vendor: a duty-of-care review, a data-protection assessment, or a procurement decision attached to the old publisher no longer describes the app your readers will install. Check the publisher, not only the link.

Android: a partial sweep, and a trap worse than the one above

This page has said from the start that its table is iOS, and that guessing an Android package name from an iOS bundle identifier produces false negatives. Trying it properly turned up a worse failure than a false negative, and it happened to me, on my own app.

The method was meant to avoid guessing entirely: take each app’s developer website as Apple lists it, fetch that site, and read the Play Store link the publisher themselves put there. That yielded packages for 8 of 27 apps. Seven were correct. The eighth was this app — and com.relief.relief on Google Play is “Relief: Get out of debt”, a debt-management app by an unrelated company.

Relief has no Android version at all. The package resolves, the page loads, and the listing is real — it is simply somebody else’s app that happens to share an obvious name.

That is the trap, and it is sharper than a false negative. A guessed or mis-derived Android package does not usually 404. Sometimes it returns a healthy listing for a different product — and a maintainer checking links would see HTTP 200, tick the row, and leave a mental-health resource page pointing readers at a debt app. A 404 at least announces itself. This does not.

Generic app names make it likelier, not less likely. The plainer the name, the more probable that somebody else already owns the obvious package.

What was actually checked

Stated as a partial result, because that is what it is:

• 9 of 27 apps confirmed present on Google Play by taking the publisher’s own declared package and then verifying the listing’s name matched the app: Clarity, Daylio, FreeCBT, Reflectly, Rootd, Untangle, 7 Cups, and — added 26 August after widening the search beyond publishers’ home pages to their download pages — Moodfit (com.robleridge.Moodfit) and SuperBetter (com.superbetter.paid).
• Woebot is genuinely gone from Play — com.woebot returns a real 404, with a control package returning 200 on the same request.
• The remaining 17 are unchecked, and the honest routes are now exhausted. Three independent publisher-declared sources were tried for each: the site Apple lists as the developer’s, that site’s download and app pages, and the support URL plus the App Store description text from Apple’s own API. The last of those returned a Play package for none of the sixteen re-checked on 26 August.

That is a property of the publishers, not a gap in effort. These companies simply do not cross-link their Android listing from anywhere Apple can lead you to. The only remaining ways to close it are to guess the package from a bundle id — which produced a confident, wrong row about this page’s own author — or to search Play by name, which is the check this page spends a whole section explaining does not work.

So it stays open. 17 of 27 have no Android answer here, and the reason is stated rather than the number quietly being left to look like laziness. A gap with a characterised cause is more useful to a reader than a gap that might close next week.

A third false positive, and a new shape of one. The same widened search offered app.monkeytaps.moodlight for I am – Daily Affirmations. The package resolves, returns 200, and belongs to the correct publisher. It is still wrong: the listing is “Moodlight – Daily Mood Tracker”, a different app by the same company.

So reading the link from the vendor’s own site — the very fix for guessing — has its own failure mode: a publisher with several apps may promote a different one of theirs on the page you happen to read. Right publisher, right site, right link, wrong app. Only the name check separates them.

The verification step is the whole method. Resolving a package is not the check — confirming that the listing you reached is the app you meant is the check. Without it this sweep would have published a wrong row about its own author’s app.

The other half of a link: the developer’s own website

Everything above checks a store link. That turns out to cover only half the problem, because a great many resource pages never link the store at all — they link the developer’s website instead. Spanish and Italian round-ups do this almost universally: of four Italian mental-health round-ups checked on 26 August, the two that loaded carried zero App Store links between them, and one of them linked ten developer homepages in their place.

On those pages the question “does the App Store link still resolve?” has no input. The equivalent question is does the developer’s site still exist, and does it still serve this product? So that sweep was run against every developer website Apple lists for the apps in the table above — 21 distinct domains. Seventeen resolve correctly. The other four fail in three different ways, and none of the three is a dead link. Two further failure types are described below. Neither was found in this table — both came from auditing resource pages elsewhere — and they are included because they are the two a maintainer is least equipped to spot.

1. The domain answers on HTTP and refuses HTTPS

calmharm.co.uk and clearfear.co.uk — the short domains for two UK charity apps — accept no connections on port 443 at all. The exact error is Failed to connect to calmharm.co.uk port 443. That is not an expired certificate: an expired certificate still completes the connection and produces a warning. Nothing is listening.

Port 80 works perfectly and redirects to calmharm.stem4.org.uk and clearfear.stem4.org.uk, both healthy. That asymmetry is what makes it invisible. Anything that tries the plain http:// form sees a clean redirect and moves on.

Two consequences. First, Apple’s own record for Calm Harm (id961611581, Stem4) gives the developer website as https://calmharm.co.uk/ — so the Developer Website link on that app’s App Store page does not connect. Second, any page linking the https:// form — now the default habit, and what most editors auto-complete to — is sending readers to a connection failure, with no fallback for browsers in HTTPS-only mode. This was reported to the charity on 26 August; it is a setting at their domain host, not a fault in either app.

2. The link works and lands on somebody else’s homepage

thriveport.com, listed as the developer site for Moodnotes, now redirects to bendingspoons.com — a corporate homepage with no Moodnotes anywhere on it. HTTP 200, real page, wrong product. A link checker reports this as healthy, because by every mechanical measure it is.

3. The domain simply moved

wysa.io now redirects to wysa.com. Benign, and included only so the three are not confused with one another: a moved domain, a cross-brand redirect and a protocol failure look identical in a status column and need different fixes.

4. The product was acquired, and the name it was recommended under was let go

Not one of the 21 domains above — this came from auditing a US college resource page that still recommends Shine. It is included because it is the failure a link check is least able to help with.

Shine is the clearest case, and the hardest for a maintainer to reason about. theshineapp.com behaves like the domains in case 1 — nothing on port 443 for the apex, www. or the advice. subdomain — but over http it does not reach the product either. It reaches a registrar parking page that reads “theshineapp.com is unavailable”. The domain has lapsed.

The app itself did not fail. headspace.com/shine returns 200 and is titled “Shine X Headspace” — Headspace hosts the product on its own domain. Press coverage dated 8–9 September 2022 reports Headspace Health’s acquisition of Shine; that reporting is secondary and is why the date is attributed rather than asserted, but the live Headspace page is checkable now and is the part that matters to a maintainer.

Why this is its own category. In cases 1 to 3 the fix is mechanical — add a certificate, change a URL, note a new publisher. Here the entry itself is wrong. A page recommending “Shine” and linking theshineapp.com is naming a product that no longer exists under that name, at a domain somebody else may register next. Deleting the row loses a resource that is still available; leaving it sends readers nowhere. The honest edit is to say what happened.

It is also the sub-type most likely to hit good apps. Shine was an Apple Best of 2020 pick. Being well-funded and well-reviewed is not protection — it is a precondition for being acquired, and an acquirer has no reason to keep paying for a domain it has stopped marketing. A list of recommendations decays fastest exactly where it was most confident.

5. The domain lapsed, and somebody else re-registered it

Also not one of the 21 domains above — this came from auditing a 2020 article on a major education publisher. It is the only failure on this page where the broken link looks healthier than a working one.

The article recommends an app called Atlas and links it twice: once to the App Store, once to www.atlasmh.com/schools for the offer being described.

• The store link fails loudly. Apple’s lookup API returns zero results for id1423178843 in the US, Canadian, UK and Australian storefronts, and the page 404s. A link checker catches this one.
• The website link returns 200. It redirects to the domain’s front page, which today publishes articles about barter exchanges and gift ideas, arranged under mental-health-sounding category headings. No checker catches this one, because by every mechanical measure there is nothing wrong with it.

Two facts establish what happened, and both are checkable in seconds. The domain’s WHOIS creation date is 21 November 2024 — more than four years after the article was published. The Internet Archive’s May 2020 capture of the same domain is titled simply “Atlas”. The registration lapsed, and someone else picked it up.

A second one, found a week later, on a university library guide

When this section was first written it rested on a single example. One lapsed domain can be a coincidence, and saying so was the honest limit of the evidence. It is no longer a single example.

MoodPanda is a mood-tracking app recommended on a US university library’s anxiety and depression guide, a page updated as recently as March 2026. moodpanda.com returns 200 and redirects to healthnutrition.com/pages/mood-panda — a supplements retailer, selling a product called Mood Panda. The domain’s WHOIS creation date is 19 June 2025. Same signature, different year, found the same way: on a live page that recommends it.

Two instances make the pattern legible, and it is worth stating plainly: the re-registrant keeps the name. Barter and gift articles under “AtlasMH”. Supplements under “Mood Panda”. That is not a coincidence of naming — the name is the asset, because the name is what still has inbound links and search traffic from the years the app was real. So the new owner has every reason to keep it, and keeping it is precisely what makes the link continue to look correct to a maintainer scanning their own page.

The uncomfortable implication for a health or education site: the more successful your recommendation was, the more valuable that domain becomes to somebody else when it lapses — and the traffic you send is part of what makes it worth taking.

A third, and the one most likely to survive being checked

The two above are caught the moment anybody opens them: barter articles and a supplements shop are obviously not what the sentence promised. One Mind PsyberGuide is not caught that way.

It was an app-evaluation project — the thing resource pages linked precisely because it rated mental-health apps independently. onemindpsyberguide.org returns 200 today, and the page title is still “One Mind PsyberGuide | A Mental Health App Guide”. Underneath that title, the navigation currently reads: Alpha Brain Alternatives, Alternatives to Adderall, Best Nootropics, Best Nootropics for ADHD, Best Supplements for Brain Health.

The distinction matters. With Atlas and MoodPanda the re-registrant kept the domain name. Here the original page title is kept too — so a maintainer who does the right thing, opens the link, and glances at the tab sees the name they expected and closes it satisfied. Retaining the title defeats the one check that catches the other two.

It is the whole site, not just the front page. Every original path checked — /guide/apps/, /guide/technologies/, /resources/technologies-for-mental-health/ — returns 200 and redirects to that same root. Those are the deep links an institution would have used, because the app guide itself was the useful part. All of them now land on supplements.

And the organisation says so itself. One Mind, the non-profit that ran PsyberGuide, now lists it under “Past Programs” — onemind.org/psyberguide redirects to onemind.org/what-we-do/past-programs/. So the project genuinely ended; what is at the old address is not it.

It is also not confined to one page. This domain was found still linked on a US university psychiatry department’s recommended-apps page and on an Australian university’s student wellbeing blog, two days apart, by two unrelated searches.

One caveat, kept deliberately. For Atlas and MoodPanda a WHOIS creation date proves the registration lapsed and changed hands. No such check was run here, so this is described as repurposed rather than asserted as re-registered. What is directly observable is what the domain serves today, and that is enough for a maintainer to act on.

Why this is the worst of the five. Cases 1 to 4 all produce a symptom: a refused connection, a stranger’s homepage, a redirect, a parking page. Something looks wrong to anyone who clicks. Here there is no symptom at all. The link is 200, there is no certificate warning, no redirect chain worth noticing, and the destination carries health-adjacent category names. A maintainer running a link checker over their page gets a clean report. A reader following the link from a mental-health article arrives somewhere with no relationship to the sentence that sent them.

The test that finds it costs one command. Compare the domain’s registration date against the date the recommendation was written:

whois atlasmh.com | grep -i "creation date"
#   Creation Date: 2024-11-21T21:04:58Z

A creation date later than the page that links it means the domain in the link is not the domain the author linked to. It is not proof of anything sinister — registrations lapse for ordinary reasons — but it is a positive signal that the thing on the other end changed hands, and it is the only cheap one available, because everything else about the link still looks fine. It is worth running on any recommendation more than about three years old.

Two milder variants turned up in the same article and generalise beyond it. A link to duo.google.com still returns 200, but redirects to the Google Meet product page — right company, right redirect, and a product name in the article that no longer exists. And a link to a school district’s resource site returns 200 while redirecting to a Google sign-in screen: a 200 that no reader of a public article can actually read. In both cases the status code is 200 and the page is not what the sentence promises, which is the same lesson as the section above, arriving from a different direction: a status code describes a response, not a destination.

The mistake that produced this section

Worth stating plainly, because it is the most useful thing here. On first pass I checked http://calmharm.co.uk, saw the clean redirect, and told a publisher their two links were fine and to leave them alone. Their page linked the https:// form. I had to write back within the hour and correct it.

The scheme is part of the identifier. Checking http://x tells you nothing about https://x when nothing is listening on 443. Check the URL exactly as the page writes it — not a form of it you consider equivalent.

The same mistake has now happened to me three times, each at a different layer, and the third one is the tidiest illustration. Auditing a college resource page I recorded Happy as gone, because www.happythemovement.com has no A record at all. That is true. It is also not the whole hostname:

• www.happythemovement.com — no A record. Nothing loads.
• happythemovement.com, without the prefix — HTTP 200, redirecting to frictionlessmentalhealth.com, whose page title is “Happy: Frictionless Mental Health”. The company rebranded.

So the app is alive, the fix is a new URL rather than a deletion, and I had written the opposite. The resource page happens to link the www. form, so its link really is broken — but “this is dead” and “this moved, here is where” lead a maintainer to opposite edits.

The pattern, stated once for all three: a scheme, a hostname prefix and an id are all part of the identifier, and none of them can be swapped for something you consider equivalent. http is not https. www.x is not x. A searched id is not the id on the page. Each time, the substitution felt too small to matter, and each time it inverted the answer.

The practical form is short: check the exact string the page publishes — and when it fails, check the obvious variants before concluding anything, because a failure on one variant is not a failure of the thing.

The same discipline applies one layer up. Resolving these 21 domains meant first matching each app on the page to Apple’s record for it, and a first pass that took the top search result mapped Youper to Wysa’s listing and Relief to an unrelated app. Requiring Apple’s returned publisher to match the publisher claimed here fixed it: 26 of 29 verified, and 3 left unmatched rather than guessed.

The app outlived the organisation that vouched for it

Every failure above is some version of the app is gone and the link is not. This one runs the other way, and it was found by auditing this site's own pages rather than someone else's.

MindShift CBT is one of the most widely recommended free anxiety apps in North America, and it is in excellent health: id634684825, updated 20 August 2026, still free. Nothing about the app needs fixing.

What changed is the sentence around it. Resource pages almost never write “MindShift CBT” on its own — they write “MindShift CBT, from Anxiety Canada”, because the non-profit is the reason a reader should trust it. That clause is now false. anxietycanada.com serves a single notice: “as of April 1, Anxiety Canada has officially ceased operations and is no longer available.”

The year is not stated in the notice, so it was pinned rather than assumed: the Internet Archive's capture of 16 March 2026 is the full working site, titled “Self-help Resources, Programs & Services”; the capture of 10 April 2026 is the closure notice. April 1 is 2026. The App Store now lists the publisher as 247 Labs Inc.

Why this deserves its own heading. A recommendation has two parts — the thing and the reason to trust the thing — and they can expire independently. Every check on this page tests the first part. Nothing tests the second. An app can be updated last week while the clinic, charity or research group cited as its warrant has been wound up for months, and no link check, store lookup or version date will ever say so.

It is also worth noticing how the closure hides. Every path tried on that domain returns 200 — /resources/, /about/, even /resources/mindshift-cbt/. The notice is served for everything. So a resource page linking deep into Anxiety Canada passes a link check today exactly as it did in March, and the only way to notice is to read what comes back.

The check, since there is one: for any app recommended because of who stands behind it, open that organisation's own site occasionally — not the app's store page. The store knows who publishes the binary. It does not know whether the charity in your sentence still exists. The notice does name where some material went: a subset of Anxiety Canada's resources is said to remain at the Vancouver CBT Centre and Here to Help BC.

Found by auditing this site's own recommendation list, which described MindShift CBT as “from Anxiety Canada's programme” four months after that stopped being true. The page has been corrected; the mistake is left described here because it is the whole point.

Searching for an app is not checking that it exists

This is the one worth knowing even if you read nothing else here, because searching is how most people verify a recommendation — and on a dead app it fails without looking like failure.

Therapeer, a peer-support app, closed. Its own site says so: every path on therapeer.app now redirects to a farewell page reading “we have made the difficult decision to close Therapeer.” Both stores agree — Apple’s lookup on id1463843436 returns nothing in the US or Canadian storefronts, and the Play package app.therapeer returns 404.

A web search for it, run on 26 August 2026, returned both store pages as ordinary results, with titles and descriptions:

• apps.apple.com/ca/app/therapeer-peer-support-groups/id1463843436 — 404
• play.google.com/store/apps/details?id=app.therapeer — 404

The index outlives the listing. A search result is a memory of a page, not a check that the page is still there, and nothing in the result says which one you are looking at. Someone updating a resource page, seeing a confident result with a real title and a real store URL, has every reason to believe the app is fine.

This is a large part of the answer to why do so many resource pages recommend apps that no longer exist? It is not carelessness. The verification method most people reach for is the one that cannot detect this failure, and it stays wrong for as long as the index takes to catch up — which, for a low-traffic store page, can be a long time.

The check that does work costs one request: open the store URL and read the status code, or query Apple’s lookup API by id and read resultCount. Both are linked in the method note below. Neither can be satisfied by a page that no longer exists.

A withdrawal is not global, and the leftovers sit in small storefronts

An earlier note here reported that a US sweep predicts European availability almost perfectly — 26 of 27 apps present in all five storefronts checked. That is still true, and it is about apps that are on sale. Removal behaves differently.

Youper (id1060691513) was withdrawn from the stores in April 2026 and is closing on 30 September 2026. Checked by id across fourteen storefronts on 26 August 2026:

• Thirteen return nothing — us, gb, es, de, ca, ie, au, nz, in, pl, za, sg, ph.
• ag — Antigua and Barbuda — still lists it. Youper, YOUPER, INC., bundle br.com.youper, v12.07.004, free, last updated 27 February 2026. Confirmed on three separate requests, with us and gb re-queried alongside as controls and still returning nothing.

So “it was pulled from the App Store” is a sentence that needs a storefront attached to it. A removal is not one event; it is a set of them, and the set is not always complete. The residue lands in storefronts nobody sweeps — which is also where it is least likely to be noticed and fixed.

Two practical consequences. If you maintain a list, a hit in one small storefront is not evidence an app is healthy: this one is live, free, and shutting down in weeks. And if you are checking whether something is gone, one storefront returning nothing is not proof either — it is proof about that storefront. The claim you can defend is the one you can name the storefronts for.

Worth stating plainly against our own earlier wording: everything written here about Youper being “removed from both stores” was correct for every major storefront and for every reader likely to see it, and still not literally true. It has been made precise rather than left as a convenient approximation.

What could not be confirmed

Sintelly, Bloom, Thought Challenger, Togetherall, and the original Thriveport MoodKit (a US listing exists under that name but with a different publisher), did not come back on a US store search under those names. That is not evidence that they are gone. A search misses apps for renaming, regional availability, or a store title that differs from what people call it.

They are listed as unchecked rather than quietly dropped. A list that hides its gaps is worse than no list. Happify used to sit here and no longer does: it is in the table above as Dario Mind (Twill), which is published by Happify, Inc. under the bundle com.happify.kabinet and describes itself as formerly Twill. Renamed, not gone — which is why a name search alone was never enough to say.

How often is a page actually broken?

Everything above is a catalogue of things that go wrong, because things going wrong are what produce findings. That gives a misleading impression, and it is worth correcting directly: plenty of these pages are perfectly fine.

Some pages checked link-by-link during this work, with the counts as measured:

• A city crisis service’s app library — 26 store links, 11 dead.
• A teen crisis line’s recommendations page — 5 apps, 3 unreachable.
• A community college library guide — 32 links, 3 faults (one of them an app that was closing while its link still worked).
• A university counselling self-help page — 1 dead, and it was one of only two apps the page featured.
• A college student-services page — 11 store links, all healthy.
• An academic depression centre’s toolkit — 28 links, none dead. Several redirects, all resolving to live successors.
• A national education publisher’s 2020 feature — 26 outbound links, 2 outright dead (a store listing and a PDF), plus the re-registered domain described in case 5. Three more could not be checked at all, because the publications they point to refuse automated requests.
• A university library’s app recommendations tab — six faults, the worst set found on one page: two URLs that were malformed and had therefore never worked, two apps that no longer exist, a domain now redirecting to a supplements shop, and a link that redirects to itself in a loop.
• A medical school library’s health and wellness apps page — 29 links, nothing meaningfully wrong. One government tool has moved and issues a redirect; three sites refuse automated requests, which is not a fault.
• A university self-care guide — 14 links, all clean.
• An Irish university wellbeing guide — 42 links, one dead, one server not answering, one redirect into a maintenance path, and an app that has been renamed. The dead one is an app closing at the end of September.
• A university counselling service’s app list that names apps without linking them — about 31 apps, five gone from the store, one renamed, and one that is current on iPhone while its Android listing does not load. No link checker can see any of it, because there are no links to check.
• Three addiction-recovery pages run by treatment providers and a hospital system — 15 store links between them, every one live, and every one updated within the last six months.

Those last two are worth putting side by side, because they were audited on the same morning and came out opposite. The recovery pages belong to organisations that sell treatment; the app list belongs to a counselling service that gives its recommendations away with an explicit no-endorsement disclaimer. The commercial pages were the current ones.

Three pages is not a pattern and should not be treated as one. But it points at something duller than institutional carelessness: a page tends to stay current when somebody’s ongoing work routes through it. A treatment provider’s resource page is on the path somebody walks every week. A student wellness list is written once, carefully, by people whose actual job is seeing students — and then nothing brings anyone back to it. The disclaimer at the top of such a page (these are provided for informational purposes only) is doing real legal work, but it cannot tell a reader which entries still exist.

That is a small and deliberately unrepresentative sample — pages were picked because something suggested they might be stale, so the failure rate here says nothing about pages in general and should not be quoted as if it did. The clean ones are listed for the same reason the broken ones are: a list that only records finds is a list that will eventually find things that are not there.

What it does show is the shape of the problem. Breakage is not universal and it is not rare; it is unpredictable. Two pages of similar age, from similar institutions, can differ completely — and nothing visible from the outside distinguishes them. The page that turned out to have eleven dead links did not look worse than the one with none. Nor does institutional weight help: the entry above with the hardest fault to detect belongs to the best-resourced publisher on the list.

That is the actual argument for checking. Not that these pages rot — most of the ones here did not — but that you cannot tell which have without looking, and looking costs one request per app.

The links that matter most are the ones nobody audits

Everything above concerns app links. There is a smaller set of links on these pages that carries far more weight and gets checked far less often: crisis lines.

An app entry that 404s is an inconvenience. A crisis number that has changed, or a helpline link that no longer resolves, fails someone at the worst possible moment — and it fails silently, because nobody reports a dead link they found while in distress.

They are also unusually easy to get wrong. Numbers get reassigned. Services merge. A national short code is meaningless one border away. And unlike an App Store id, a phone number gives you no error to notice — there is no 404 for a line that now belongs to someone else.

The proof is that I did it myself, on a page I had already audited

Everything above is easy to agree with and hard to act on, so here is the demonstration, with me as the negative example.

On 25 August I audited a university psychiatry department’s recommended-apps page and wrote to them about three entries that had changed — a retired chatbot, a withdrawn app, and a domain that now sells nootropics under the title “A Mental Health App Guide”. All three findings were correct.

Two days later I went back to check whether anything had changed and, this time, looked up every App Store id on the page rather than the ones I had a story about. One was dead: an app the page describes as putting someone in direct contact with a Lifeline counsellor, with a 911 alert and three chosen contacts, for when they are having thoughts of suicide. The link 404s. The id returns nothing in seven storefronts. There is no successor — searching the App Store for its name returns unrelated telecoms apps from other publishers, so anyone relinking by name lands somewhere completely wrong.

It had been sitting there through my first audit. I had walked past it to write about a supplements website.

The mechanism is worth naming, because it is not carelessness. I checked the entries I had a reason to check — the ones a news story or a shutdown notice had told me about. Crisis entries generate no news. Nothing tells you they broke. So an audit driven by what you have heard about will systematically skip exactly the entries that matter most, and will feel thorough while doing it.

The correction is one line of practice: audit the crisis entry first, before the entries you already have a reason to suspect — and sweep every id on the page, not the interesting ones.

Then the claim was tested, because an anecdote is not a mechanism. Five pages that had already been audited and written to were re-swept, this time looking up every store id rather than the entries there was a story about. The result splits cleanly along the method used the first time:

• The three audited by sweeping every id from the start came back exactly right — 16 dead of 29 on one page, 3 of 10 on another, 2 on a third. Nothing missed.
• Both audited by checking the entries there was news about were under-reported. One dead entry became three; three became four. And in both cases the entry missed was the crisis-adjacent one — a suicide safety-planning app on the first, and on the second an app the page itself describes as offering “safe spaces for those who might be in a vulnerable state”.

So the failure is not attention or care. It is selection: an audit driven by what you have heard about will reliably skip the entries nothing is ever written about, and those are disproportionately the crisis ones. Two for two, on the two pages where that method was used. The fix costs one extra request per app.

Checking our own, since this page asks others to check theirs

It would be poor form to publish a page about stale links without auditing the ones in our own app. Verified 26 August 2026:

• 988 — US Suicide & Crisis Lifeline. Correct.
• Text 741741 — Crisis Text Line. Correct.
• 1-866-488-7386 — The Trevor Project. Checked against their own Get Help page, where it appears eight times. A number is only verifiable against the organisation that owns it; nothing else counts.
• findahelpline.com — the international finder, HTTP 200.

Region handling is the part most likely to be wrong, so it is worth stating explicitly. US short codes are useless outside the US, and a device that cannot report its region is not a US device. Our app treats unknown as its own case: the international finder leads, and any US line shown is labelled as such. The failure mode being avoided is answering “we do not know where you are” with “call this American number.”

What the dead app turned out to be

Following the id from the section above produced something worse than one stale entry.

The app is MY3 — Support Network, id709651264, a safety-planning tool built around three chosen contacts. It is not an indie project. According to the organisations that list it, MY3 was owned by Vibrant Emotional Health, the administrator of the 988 Suicide & Crisis Lifeline. It is recommended by hospital systems, by suicide-prevention bodies, and in consumer round-ups.

Checked on 27 August 2026, Apple’s lookup returns zero results in fifteen storefronts — us, gb, ca, au, de, jp, ag, sa, in, za, nz, ie, mx, br and ph — against a control app that returned normally on the identical request. The App Store URL a university publishes for it returns 404.

Two things are not claimed here, because they could not be established. my3app.org returned 503 when checked, which is a server error and not proof of anything — it may be back tomorrow. And no claim is made about Android, because the package name would have been a guess, and a guessed identifier is exactly the mistake this page keeps documenting.

The part that should worry a maintainer is what happened when the surviving recommendations were checked. Of the pages still listing MY3, a hospital network’s safety-planning page and a national suicide-prevention resource database both return 403 to every tool available — curl and a fully rendered browser alike. They cannot be audited from outside at all. A consumer round-up from a large technology publisher can be read, but it names its eight apps in plain text with no links, so there is nothing to check mechanically and a name search cannot prove absence either way.

So the highest-consequence category of recommendation is also the one that is hardest for anybody outside the institution to verify. If your organisation publishes crisis or safety-planning app recommendations, you are very likely the only person who can check them. Nobody is coming to tell you.

If you maintain a page with crisis numbers on it

The check is short, and unlike the app checks above it cannot be automated — a phone number has no status code:

• Verify each number against the owning organisation’s own site, not a directory, not a search result, and not another resource page. Directories inherit errors.
• Check that region-specific lines are labelled by region. A US short code listed without qualification is wrong for every reader outside the US.
• Include an international finder for the readers your national numbers do not serve.

This is the one section here where “probably still fine” is not an acceptable answer, and where the cost of checking is a few minutes once a year.

The IDs, so you can check your own page in one pass

Everything above is narrative. This is the part you can actually use: the App Store IDs that have come up dead while auditing other people’s pages. Search your own page for these numbers. You do not need my name for an app — you have your own label sitting next to the ID.

All checked 27 August 2026. Each returns no result from Apple’s lookup API in five storefronts — us, gb, ca, au and ag — on requests where a control app returned normally. Twenty-nine of them:

Fifteen more IDs are confirmed dead by the same check but were recorded without a name I can vouch for, so they are listed as numbers only rather than guessed at: 1065632442, 1293721589, 427064423, 1440060534, 1471316212, 1472393066, 1524433775, 1535250944, 507357193, 512241001, 538010611, 6473211317, 6475393761, 804271492, 912632260. If one of them is on your page, your own label tells you what it was.

And the opposite list: gone from the US store, alive elsewhere

These are the ones a US-only sweep will wrongly delete. Each returns nothing in the US and resolves normally in at least one other storefront:

• 825099621 — Virtual Hope Box. Nothing in the US, live in au. There is a current US listing under a different ID: 6477622019.
• 1469216793 — Stresscoach (formerly Pocketcoach). Not available in the US at all; live in gb, de, at and ch.
• 1060691513 — Youper. Already withdrawn from every major storefront, still resolving in ag. Separately, the service closes on 30 September 2026, and anyone journalling in it should export before then.

Why this list exists in this form. Every audit this page describes had to rediscover the same handful of dead IDs from scratch. Publishing them turns each one into a single grep for anybody else, and the crisis-related ones — MY3 above all — are the entries least likely to be found any other way, because an app that quietly disappears generates no announcement for anyone to notice.

Method, and its limits

• Apple’s public iTunes Search API, US storefront, 25 August 2026. Every name, publisher and date above comes straight from that response.
• Rows were matched by hand. An automated match put “Pacifica” against a high school’s app on the first pass — which is precisely the error this page would otherwise have shipped.
• The two withdrawals are the only claims resting on anything other than the store, and both are supported by contemporaneous reporting and by the companies’ own pages.
• One storefront for the table. Availability differs by country; the five-storefront check and its result are described above.
• The developer-website sweep (26 August 2026) checked DNS resolution and the final URL after redirects, over both http and https, for every developer site Apple lists for these apps. A status code alone was not treated as an answer: two healthy domains and two failing ones returned the identical transport error, and only DNS separated them.
• Case 5 rests on two records rather than a fetch: the domain’s WHOIS creation date, and the Internet Archive’s dated capture of the same domain. Both are quoted above so they can be re-run. WHOIS creation dates are reset by a lapse-and-re-registration but not by an ordinary transfer, so a date later than the linking page is evidence of a handover and not of the buyer’s intent — the page says what is served there now and leaves it at that.
• This is a snapshot, and it will go stale — which is the problem it describes. The check date sits above the table for that reason.

Relief is in the table because leaving it out would have been the tell. If something here is wrong, it is worth more to me corrected than flattering — tell me and I will change it and say the date it changed.