Posted on

Mobile apps that cannot be reinstalled after delisting

Flappy Bird left the App Store and Google Play in February 2014, pulled by the developer who designed it and then watched it climb to the top of both download charts. It had been downloaded more than 50 million times. New players could no longer get it, and as the LA Times reported, phones with the game preinstalled were briefly listed on eBay, one reaching a bid of nearly $100,000 before the auction was pulled. The game was not destroyed. The stores just stopped handing it out, which for most people was the same thing.

Why a working copy stops being enough

A delisted app lives on a device, but it reaches new devices through a store, and the store is the first point of failure. For years, a previously purchased iOS app stayed downloadable from the Purchased tab even after it vanished from search. That was policy, though, not physics, and policies get revised.

They were revised on a large scale with iOS 11. Apple’s 64-bit transition notice was precise: support for 32-bit apps was gone, and 32-bit apps already installed on an upgraded device would not launch. That is a compatibility failure rather than a simple delisting failure, but for preservation the result is similar: keeping the binary is not enough if the current operating system refuses to execute it. A working old app may require a compatible old device and operating system.

Android reaches a similar place by different routes. Android 14 blocks ordinary installation of apps targeting below API 23, and Android 15 raises that floor to API 24; Google’s Android 15 behavior documentation records the change and notes that already-installed older apps remain after an upgrade. Google Play has a separate distribution policy: as of August 31, 2026, stale apps that do not meet the current target-API requirement become unavailable to new users on newer Android versions. The store and the operating system therefore impose two different kinds of aging.

And none of that touches the backend. A delisted app that needs a login, a feed, or a marketplace is a corpse in a chair even when it installs cleanly. Plenty of apps survived delisting only to die when a company shut down its servers or let its certificates expire.

What preservation actually keeps

The two platforms recover differently. Android packages can often be preserved and installed on compatible systems outside Google Play, although newer Android versions increasingly block very old targets by default. On iOS, Apple still provides a purchase-history redownload path, but redownload does not solve incompatibility and it depends on Apple continuing to serve a compatible copy. A preserved binary, a compatible operating system, and any required backend all matter separately.

A preserved copy is therefore evidence more than it is a working program. Archives hold the binary, the screenshots, the documentation, and the review threads — a fair record of what the app was and who used it. Getting it running again requires a compatible-enough operating system, an acceptable signature, and sometimes a live server that no longer exists.

A previous download was never an archive. Delisting removes the reinstall, update, and trust channels along with the store page, so the software does not die so much as become unreachable — and unreachable is how most software now goes extinct. If you have an app you care about, keep the file, keep the version that matches your device, and assume the store will not be holding it for you.

Posted on

Browser extensions removed from official distribution catalogs

On August 31, 2026, Google removed the remaining Manifest V2 extensions from the Chrome Web Store, including uBlock Origin. Google’s own Manifest V2 timeline now records that date as the final store removal. The code had never left GitHub. What the catalog took away was the normal Chrome distribution path around the code.

A listing is more than a download button

A catalog entry is where a tool is discovered and trusted. It carries the package, automatic updates, install counts, ratings, reviews, screenshots, permission disclosures, and a stable installation path. Remove it and new users lose the normal route to the software. In this case the runtime changed too: Chrome disabled Manifest V2 everywhere with Chrome 138, and the enterprise escape hatch disappeared with Chrome 139. A preserved store package therefore does not restore normal operation in current Chrome.

Why uBlock Origin left

uBlock Origin did not disappear because its source vanished. It became incompatible with Chrome’s extension platform transition from Manifest V2 to Manifest V3. The current uBlock Origin repository explicitly notes that its Chrome Web Store listing was removed on August 31, 2026 while the full extension remains available for Firefox. A different project, uBlock Origin Lite, targets Manifest V3 with a reduced architecture suited to Chrome’s newer rules.

A precedent, not a novelty

None of this is new. Firefox 57 removed support for legacy XUL extensions, leaving preserved add-on files dependent on old Firefox versions or ports to the newer WebExtensions system. Catalog removal and runtime incompatibility are related problems, but they are not the same problem.

The parts that survive separately

An extension is at least three things: source code, a packaged artifact, and documentation. uBlock Origin’s source lives on GitHub, installable releases ship alongside it, and its wiki and filter lists live in their own repositories. None of it sat in the store. What the catalog controlled was the review history, the user base, the update channel, and a single trusted URL.

A preserved copy isn’t a working install

Holding a .crx or .xpi file is not having a working extension. The browser is the gatekeeper: current Chrome rejects MV2 outright, so even a faithfully archived copy is inert there; Firefox and older Chromium are what still run it. The extension also expects an update server and, on Firefox, a signed package — a sideloaded copy loses both. And uBlock Origin refreshes its block lists from several third-party hosts on a schedule, so an offline copy eventually blocks only whatever lists were last cached. For software whose whole job is to stop untrusted content, an unverified preserved copy also means trusting whoever packaged it — the kind of decision that deserves source you can inspect.

That is the real loss when an extension leaves its catalog: not the code, which survives wherever its project publishes it, but the context that made it discoverable, updatable, and trustworthy. A store listing was never a backup.