Colophon

How Legacy Store is made.

Legacy Store is a preservation archive of iOS applications from the App Store's first fifteen years — the delisted, the abandoned, the quietly removed, and the merely old. It exists so that a person holding a first-generation iPad or an iPhone 3G can find an app that still runs on it, know before downloading whether it will actually launch, and install it straight onto the device. It is also a time machine: a record of how each app — and the App Store around it — looked and changed, year over year, screenshot by screenshot.

Everything here is open source, and everything about how it works is written down. This page is the long version.

What this is, and why it exists

There are more than 200,000 archived .ipa file copies on the Internet Archive, which deduplicate by content hash to roughly 160,000 distinct binaries. About 115,000 of those are genuine App Store apps; the rest are re-signed or repackaged copies the archive catalogues but keeps out of its listings — why, and how they are told apart, is further down. The archive treats the binary — identified by its hash — as the thing worth knowing about, and folds duplicate copies together.

The problem this solves is specific and, if you have ever tried it, familiar. Many archived .ipa files are still FairPlay-encrypted: they install onto a jailbroken or sideload-capable device without complaint, then refuse to launch. The old way to find a working copy is to tap link after link until one happens to run. Legacy Store answers the question up front — will this actually run on my device? — for every app, before you spend a download on it. On a listing it shows each version's copies with their install status, hides the copies that are no longer on the Internet Archive, and, when you visit on an old iPhone or iPad, reads your iOS version and can hide the versions too new to install on it.

The archive is metadata-only. It never re-hosts the app binaries themselves; those live on the Internet Archive, and Legacy Store links out to them. What Legacy Store contributes is the analysis, the history, and the index that makes the whole collection navigable.

Where the data comes from

Five public sources, used politely:

• The Internet Archive — the home of the binaries themselves, and, through its Wayback Machine, the source for nearly all of the historical record: archived App Store pages, chart feeds, rating snapshots, and reviews going back to 2010.
• Common Crawl — a complementary bulk source of archived pages where its crawl schedule adds timeline points the Wayback Machine doesn't have.
• Apple's own public endpoints and media CDN — the iTunes Lookup API for structured metadata, and Apple's still-live image servers, which turn out to hold a great many screenshots and icons that have otherwise vanished from the web.
• A 2014 App Store metadata snapshot preserved in the open-source TwitAppCheck project — a point-in-time capture (circa November 2014) of iTunes Lookup records. It fills period-authentic descriptions, developers, and genres on apps we already held, and supplied the bundle identifiers that let us record a number of apps that had delisted before we could reach them.
• A 2021 App Store crawl — gauthamp10's open Apple AppStore Apps dataset (~1.2M apps, October 2021). Its bundle-to-App-Store-id map let us recover identifiers for thousands of apps we held only by bundle, and fill their categories and developers.

New Internet Archive dumps are ingested automatically on a regular schedule. When new items appear, they are diffed against what's already known by file hash, and only genuinely new binaries enter the analysis pipeline. Nothing is scraped twice.

How each app is analyzed

This is the part the project is quietly proud of.

To decide whether an app will run, you do not need the whole app. You need the first few hundred kilobytes of its Mach-O executable — the compiled program's header. So that is all Legacy Store fetches. Using HTTP range requests against the raw .ipa on the Internet Archive, the pipeline reads the Zip archive's directory from the tail, locates the executable inside it, and pulls just enough of it to parse the header. A typical binary is understood from well under a megabyte of transfer, with no full download and no server-side extraction.

From that header it reads:

• FairPlay encryption — the Mach-O cryptid flag. This is the canary. An encrypted binary installs but never launches, so cryptid is the will-it-run answer. Every app is labelled installable or encrypted accordingly.
• CPU architectures — armv6, armv7, arm64 — read from each slice of a fat binary, so a page can tell you an app runs on an armv6 iPhone 3G, or only on 64-bit hardware.
• The minimum iOS version the binary declares, and the SDK it was built against.
• Embedded frameworks, app extensions, and Watch apps, detected from the archive's file listing.
• Languages, from the app's Info.plist localizations and its .lproj directories.

Icons get their own care. The pipeline prefers Apple's high-resolution iTunesArtwork where present, and otherwise extracts the app's icon from loose PNGs or from the compiled Assets.car asset catalog. Apple's iOS-optimized "CgBI" PNGs — which ordinary image viewers can't read — are converted back to standard PNG. Every icon is content-addressed by the hash of its bytes, deduplicated across every app and version that shares it, and served from a CDN rather than from Apple's long-dead artwork servers. Because a single icon is tied to the exact binary it came out of, listings can show the oldest icon an app ever shipped by default, and switch to the icon closest to a given version or chart date when you're looking at a moment in time.

Because the analysis is a property of the binary, not of any one archived copy, each distinct binary is scanned exactly once. The raw artifacts pulled during that scan — the plists, the parsed header, the file manifest — are kept in object storage, so any new field wanted later can be derived from them without ever crawling the Internet Archive again.

What belongs in the archive

Not everything uploaded to the Internet Archive as an .ipa is an App Store app. The mid-2010s sideloading scene left behind thousands of modified repackages — "Snapchat++", ad-stripped YouTube builds, tweak-injected clones — almost all of which reuse the real app's bundle identifier. Ingested naïvely, they attach themselves to the real app's page as bogus "versions." At one point Snapchat's page here listed more counterfeit copies than genuine ones.

So the archive draws an editorial line:

In: anything Apple shipped. A genuine App Store binary belongs here whether it is still FairPlay-encrypted or has been decrypted. Decryption does not alter what the app is — the program, its resources, its history are Apple's original bytes — and decrypted copies are precisely the ones that still run. An archive that excluded them would be an archive of apps that no longer launch.

Out: anything altered after Apple signed it. Re-signed bundles, tweak-injected builds, sideload-store repackages, and wrapper shells are not versions of the app — they are derivative works of unknown provenance, frequently carrying injected code nobody audited. They are catalogued (their hashes are remembered, so they can never sneak back in) but quarantined: they never appear on an app's page, are never counted in its version history, and are never offered for install or download. The files themselves remain where they always were, on the Internet Archive — this index simply will not point at them.

Also out: things that were never App Store apps to begin with. Apple's own bundled system apps, jailbreak and sideloading utilities, and developer-template placeholder identities that dozens of unrelated uploads happen to share are excluded from the listings even when the binary itself is untampered — they are simply not what this archive is of. As always, the binaries are remembered; they just don't get a page of their own.

The judgment is made on the binary's own evidence, never on who uploaded it or what the file was named. Most of the tells sit right in the zip manifest and Info.plist the pipeline already keeps for every binary. An App Store download never contains a provisioning profile, so an embedded.mobileprovision means the bundle was re-signed for sideloading. A foreign .dylib the app has no business shipping — a Substrate hook, a tweak payload — means injected code; the pipeline allows the short, known list of libraries Apple and common toolchains legitimately bundle and treats anything else as injection. Sideloader wrapper shells, and the telltale bundle identifiers repackagers stamp onto their output, are caught the same way. Because every check reads from stored metadata, the whole corpus can be re-judged at any time without touching the source archives.

Some counterfeits carry no code-level tell at all: the repackager leaves the real app's frameworks intact and only swaps the app icon. Those are caught by consensus instead. Because every icon is content-addressed, the archive can notice when a single copy of a version wears an icon no other copy of that app has ever shipped — the way a repackaged build of Twitter, its bird quietly replaced, gives itself away against the hundreds of genuine copies that agree on the real one. Ambiguous cases are flagged for human review rather than auto-quarantined, and every determination is logged and reversible. Nothing is ever deleted.

The charts archive

The second half of the archive reconstructs history.

Top Charts. Historical Top Free, Top Paid, Top Grossing, and New app charts, rebuilt from archived App Store chart feeds — dense from around 2010, with near-weekly resolution in the early years and coverage continuing into the 2020s. You can pick a chart and a date and see what the App Store looked like that week — real rankings, complete with period prices, developers, and artwork, and a link to the exact Wayback capture each was rebuilt from. Device-segmented charts (separate iPhone and iPad lists) and editorial feature placements are recovered alongside them.

Rating history. By reading archived iTunes Lookup responses over time, the archive reconstructs how an app's rating count and average moved year over year — so a popular app's page can show its ratings climbing from a few thousand in 2013 to a few hundred thousand later.

Reviews. Period-authentic customer reviews, recovered from archived review feeds with their original stars, titles, bodies, authors, approximate dates, and the app version each was written against. This coverage is opportunistic by nature — it exists only where someone historically fetched the feed — so it is present for some apps and absent for others, honestly.

Per-version store pages. For each app, the archive assembles a sequence of its App Store listing as it changed release to release: descriptions, screenshots, "What's New" notes, prices, and release dates. Reading these in order is like flipping through the app's own changelog as its makers wrote it.

Screenshots that came back. Many old screenshot URLs are dead in the web archive. Apple, however, rarely deletes the underlying images. Legacy Store checks Apple's live CDN first — often recovering an original-resolution image from a URL the archive only ever saw as a thumbnail — and falls back to the Wayback Machine's raw capture, recording an honest miss only when an image is genuinely gone. Recovered images are content-addressed and deduplicated like everything else.

Version history and downloads

Every version of every app carries the App Store download identifier Apple assigned it (the externalVersionId). Because those identifiers are handed out in order over time, they can be dated by calibration: given the known dates of the identifiers around it, any version's release moment can be placed on the timeline even when no dated archived page survives for it. That is what lets the archive line up a moment in history with the exact .ipa you'd want to install to match it.

Downloads themselves go two ways. On a legacy iOS device, Legacy Store serves an itms-services:// install manifest for true over-the-air installation straight onto the hardware. On a desktop browser, it hands you the .ipa directly. In both cases the file itself is fetched from the Internet Archive — Legacy Store points the way, it doesn't hold the goods.

How it's built

• The site is an Astro application deployed on Cloudflare Pages. It is deliberately server-rendered with essentially no client-side JavaScript, and its interface is built from the original iOS UIKit image slices, so that it stays usable on genuinely old versions of Mobile Safari — the same devices the archive is for.
• Structured data lives in Postgres (hosted on Supabase), with public, read-only access: the tables that describe apps, versions, binaries, charts, ratings, and reviews can be queried directly.
• Files — normalized icons, recovered screenshots, and the raw metadata artifacts of every scan — live in Cloudflare R2 object storage, content-addressed throughout.

The analysis pipeline that feeds all of this runs continuously and unattended, scanning new binaries and folding in new archived pages on a schedule.

Ethics, privacy, and method

A few principles govern the whole thing:

• Metadata only, never the binaries. Legacy Store analyzes and indexes; it does not re-host the apps. Those remain on the Internet Archive, which the site links to directly.
• No personal data. Genuine purchase copies carry the original buyer's Apple ID and account details in their metadata. Those fields are stripped out on ingest — removed entirely, not merely hidden — so nothing personally identifying is ever stored or served.
• Polite crawlers. The pipeline is rate-limited and backs off hard when a source signals it should slow down. The archives this project depends on are a shared resource, and range requests, hash-based deduplication, and a scan-once policy exist in part so the project asks as little of them as possible.
• Content-addressed and deduplicated everywhere, so the same bytes are never stored or fetched twice.

Acknowledgements

Legacy Store stands on other people's work and is glad to say so.

• The Internet Archive and its Wayback Machine, without which almost none of this would exist — both as the home of the binaries and as the memory of the App Store itself.
• Common Crawl, for the complementary view of the archived web.
• Apple's public metadata endpoints and long-lived media CDN, which keep far more of the past reachable than one might expect.
• The broader iOS preservation and jailbreak community, whose collecting, documenting, and tooling made a project like this thinkable.
• ePirat's TwitAppCheck, whose 2014 metadata snapshot filled gaps and recovered app identities the live endpoints no longer return.
• gauthamp10's Apple AppStore Apps dataset, a 2021 crawl that helped reconnect thousands of apps to their App Store identities.
• The open-source ecosystem the whole thing is built on.

About this design

The site is dressed as the iTunes Preview website as it appeared in November 2010 — the pages iTunes generated when you followed an App Store link in a browser. The layout, palette, and imagery are rebuilt from Apple's original web-storefront stylesheets (htmlResources revision 5B73) and the page's image assets, all recovered byte-for-byte from the Wayback Machine's captures of 2010‑11‑04. The star ratings, the glossy icon masks, the blue listing panels, and the footer chrome are the original PNGs; the dark Charts room is rebuilt from the same era's apple.com/itunes/charts stylesheet, and the wordmark was re-set in Myriad Pro to the same metrics and gradient as the iTunes Preview logo.

One liberty was taken: the 2010 site was a fixed 980-pixel desktop layout, and this one is responsive — the same chrome collapses for iPad and iPhone widths. Apple never shipped that; consider it a what-if.

The project's codename, if you were wondering, is Jangle — Apple's codename for the iTunes Store was "Jingle," and alliteration is fun.