Local history

Before the App Store: Cataloguing Software for 190 Handsets

This address once held a catalogue of Java games for mobile phones. It is preserved here because the problem that catalogue existed to solve — matching a piece of software to a device that could actually run it — is one of the purest compatibility problems the web has ever had to model, and because almost nobody remembers how it was done.

Between roughly 2001 and 2008, if you wanted a game on your phone, you did not browse a store. You went to a website, told it exactly which handset you owned, and the site told you what would run. The catalogue that once sat at this URL listed close to 190 distinct models from fifteen manufacturers — Japanese, Korean, Finnish, German, French, Dutch, Swedish and American — across twenty-three pages of listings. The handset picker was not a nicety. It was the entire product.

Why the matrix was so large

Java 2 Micro Edition was supposed to solve this. Write once, run anywhere, on a virtual machine small enough for a feature phone. In practice the abstraction leaked at every seam, and the leaks were device-specific.

• Screen geometry. Not merely resolution — 96×65, 128×128, 176×220 and a dozen others — but the ratio between the canvas and the soft-key bar, which differed between vendors on the same nominal resolution.
• Heap ceilings. Many handsets capped the Java heap at a few hundred kilobytes. A build that ran comfortably on one model would abort on a sibling with a smaller allocation.
• JAR size limits. Some carriers and devices refused archives above a fixed size, which forced separate builds with reduced sprite sheets and fewer audio assets.
• Optional API packages. The Mobile Information Device Profile was a floor, not a ceiling. Sound, vibration, file access and 3D were bolted on as separate optional packages that a given firmware might or might not implement — and might implement incorrectly.
• Key codes. The mapping between physical keys and the values a program received was not consistent, so control schemes had to be tested per family.

The consequence was that a single title was not a single file. It was a family of builds, and the catalogue's real job was to hold the mapping from device to correct build and never get it wrong. Get it wrong and the customer paid for something that would not start.

The catalogue as a data model

Seen from twenty years later, these sites were doing something more interesting than selling games. They were maintaining a hand-curated device capability database at a time when no authoritative one existed — a need later formalised by the W3C, whose Device Description Repository Simple API became a Recommendation in 2008 and describes precisely this kind of queryable store of device properties: screen dimensions, input methods, memory and processor constraints, and supported markup and image formats.

The structure the catalogue used is recognisably the same shape a library catalogue uses. There is a work (the game), there are manifestations of that work (the per-handset builds), and there is a controlled vocabulary (the handset list) against which manifestations are indexed. Anyone who has modelled editions and printings of a book has met this problem. The mobile version simply had a vocabulary that grew by several entries a week and a manifestation set that could number in the hundreds.

Facets, and the ones this retrospective leaves out

The original listing was faceted by genre in the way catalogues have always been faceted — arcade, racing, sport, strategy, shooters, puzzle, role-playing, flight simulation and utilities among them. Faceting was doing real work here, because with several thousand items and no useful full-text search on a slow connection, the facet was the only practical way in.

Two of the original facets are deliberately not reproduced or described in any detail in this retrospective: an adult category and a gambling category. They are noted only for completeness of the historical record. This site is an editorial resource about cataloguing practice, it offers no software, and there is nothing to download here.

What the era actually got right

It is easy to read this period as a mess that app stores mercifully ended. That is only half true. The catalogues of that era had one property modern stores mostly lack: they were explicit about compatibility. The user was told, in advance and in plain terms, that this build was for that device. Nothing was silently degraded and nothing failed after purchase with a shrug.

They also demonstrated that a small team can maintain a genuinely useful device database by hand if the scope is honest. The modern equivalent of the problem has not disappeared — it has moved into browser feature detection, into codec and container support, into the long tail of Android hardware — but the practice of publishing a legible compatibility statement has largely gone. Anyone maintaining a resource that has to work across wildly varying clients is solving the 2004 problem in new clothes.

Why this page still exists

Addresses are part of the record. This one had a catalogue behind it for years, and pointing it at nothing would erase a small piece of how software distribution actually worked before it was centralised. The argument for keeping addresses alive, and the mechanics of doing so, are set out in link rot and permanent URLs. The cataloguing ideas above are developed properly in metadata and catalogues.