Dead End: WAP and the Mobile Web

Zusammenfassung

The Wireless Application Protocol was the mobile industry’s answer to a question everyone agreed was urgent: how do you put the internet on a phone? WAP’s answer, developed 1997–1998 by a consortium of Nokia, Ericsson, Motorola, and Unwired Planet, was to create an entirely new markup language, a new browser, and a new network stack — a parallel web for phones. By 2003, WAP was widely regarded as a disaster: slow, expensive, graphically primitive, and delivering content that was barely recognizable as the web users knew from desktop computers. Japan’s competing i-mode system, built on different assumptions, worked. When Apple launched the iPhone in 2007 with a full desktop-class browser, WAP became obsolete overnight. The lesson WAP left behind is about what happens when an industry builds for the constraints it has rather than the constraints it expects.

The Problem WAP Was Solving

In 1997, mobile phones were voice devices. The GSM networks carrying calls also carried data at 9.6 kilobits per second — roughly one-tenth the speed of the slowest dial-up modem connection of the era. Display screens were monochrome, typically 96 × 65 pixels or smaller. Processors were 8-bit or 16-bit, running at frequencies measured in single-digit megahertz. Memory was measured in tens of kilobytes.

The conventional web — HTML pages with images, tables, JavaScript, and CSS — was impossible to render on these devices. An average web page in 1997 was 50–100 kilobytes. Downloading one over a 9.6 kbps connection took 40–80 seconds, assuming the phone had sufficient memory to hold it, and assuming the phone’s processor could parse and render HTML — which it could not.

The question was whether any version of internet connectivity on these devices was worth building. The mobile industry’s answer was yes, and the mechanism it chose was WAP.

The WAP Consortium and WML

The WAP Forum was founded in 1997 by Nokia, Ericsson, Motorola, and Unwired Planet (formerly Phone.com, the company that had pioneered mobile data services for carriers). The goal was to create a standard that all phone manufacturers and carriers would implement, preventing the market from fragmenting into incompatible proprietary systems.

The technical architecture WAP defined was layered:

WML (Wireless Markup Language) replaced HTML. WML was an XML application — strictly structured, with no optional end tags, no layout tables, no images (in the basic specification), and no JavaScript. Content was divided into “decks” of “cards” — a deck was the equivalent of a web page, and cards were the individual screens within it. A user navigating a WAP site moved through cards within a deck, then fetched a new deck when they clicked a link.

WMLScript replaced JavaScript but had no DOM to manipulate — it could only perform calculations, validate form inputs, and display alerts.

The WAP Gateway was an intermediary server that carriers operated between the mobile network and the internet. The phone spoke WAP’s compressed binary protocol to the gateway; the gateway fetched content from conventional web servers, converted it to WML, and sent it to the phone. This translation layer meant WAP content could be served from standard web servers, but it also introduced a significant security vulnerability: the gateway had to decrypt and re-encrypt data in transit, creating a window where content was unencrypted at the carrier’s infrastructure.

The WAP 1.x specifications were finalized in 1998. WAP 2.0, specified in 2002, aligned more closely with internet standards (using XHTML Mobile Profile rather than WML, and TCP/IP rather than WAP’s protocol stack), but by then the damage to WAP’s reputation was done.

The Experience in Practice

WAP’s theoretical capability and WAP’s actual user experience were not the same. The problems were structural:

Speed. GPRS (2.5G) mobile data, which began rolling out in Europe in 2000–2001, provided 20–40 kbps — faster than 9.6 kbps GSM data but still slow by any standard. Fetching a WAP deck required: establishing a data connection (15–30 seconds on early networks), sending the request to the carrier gateway, the gateway fetching the content from the internet, the gateway converting and sending it to the phone. End-to-end, a single WAP page load took 30–90 seconds in typical use.

Cost. Mobile data was billed per kilobyte in most European and American markets. Users who browsed WAP sites accumulated charges that appeared on their bills without clear indication of how they were incurred. The experience of being billed for minutes of data you couldn’t see arriving made WAP feel like a trap rather than a service.

Content. The WAP ecosystem never developed rich content. Major websites built WAP versions reluctantly and maintained them poorly. WAP portals — the carrier-operated starting pages that phones opened when you pressed the browser button — were filled with paid content: ringtones, wallpapers, weather, horoscopes. Organic, open WAP content from ordinary websites was sparse and often broken.

The WAP Gap. The security architecture of WAP 1.x had a structural problem that became known as the “WAP Gap”: end-to-end encryption was impossible because the carrier gateway decrypted traffic to convert between protocols. Secure transactions — e-commerce, banking — could not be conducted securely over WAP 1.x. Users’ data was potentially visible to carrier employees at the gateway. This was not a theoretical risk; it was an architectural certainty.

The WAP Gap in Practice

When a user accessed a “secure” WAP site (using WTLS, WAP’s equivalent of SSL), their data was encrypted between the phone and the carrier gateway, then decrypted at the gateway for protocol conversion, then re-encrypted for transmission to the origin server. At the gateway, the data existed in plaintext. In the UK, regulators investigated whether carriers were actually reading this plaintext traffic. The WAP Forum acknowledged the gap and addressed it in WAP 2.0 by supporting end-to-end TLS, but by 2002 the market had moved on.

i-mode: The Japanese Alternative

While WAP failed in Europe and the United States, Japan’s mobile internet succeeded spectacularly — using a different architecture built on different assumptions.

i-mode, launched by NTT DoCoMo in February 1999, was designed by Mari Matsunaga (content strategy) and Takeshi Natsuno (business development). It used a subset of HTML rather than WML — content was served in cHTML (compact HTML), which stripped out unsupported features but maintained enough compatibility that existing web tools and expertise could be used to create i-mode content.

More significantly, i-mode used a different business model. DoCoMo took a 9% commission on content sold through i-mode and passed 91% to content providers, which were vetted and approved by DoCoMo before appearing on the official i-mode menu. This created a walled garden — but one where content providers had a direct commercial relationship with the carrier and a direct path to billing. Ringtones, news, sports scores, restaurant reservations, banking, and games all appeared quickly on i-mode because the economics worked for content providers.

i-mode reached 10 million subscribers in Japan within a year of launch. By 2001, it had 30 million subscribers. The contrast with WAP’s stagnation in Europe was stark.

The reasons i-mode succeeded where WAP failed:

Packet-based pricing (users paid per data volume, with flat-rate options, rather than per minute of connection time)
Faster networks (PDC-P data in Japan was cleaner than GSM data in Europe)
A closed content ecosystem with clear commercial relationships
HTML compatibility that leveraged existing web development skills
DoCoMo’s willingness to subsidize handset development to ensure capable devices

i-mode’s walled garden was also its limitation. When smartphones arrived, i-mode’s closed content model could not accommodate the open web. DoCoMo was late to smartphones, and i-mode entered a long decline; DoCoMo announced its end in 2019 and finally shut the service down on March 31, 2026, alongside its 3G network — nearly three decades after launch.

The Browser That Changed Everything

WAP’s fundamental premise was that the mobile web needed to be a different web — simpler, smaller, structured for small screens and slow connections. This premise was wrong, or at least premature. It assumed that the constraints of 1997 hardware and networks were permanent rather than temporary.

Opera Mobile (launched 2000) and later Opera Mini (2005) demonstrated that a real web browser could run on mobile hardware using server-side transcoding — Opera’s servers fetched full web pages, compressed them, and sent the compressed versions to phones. The result was recognizable web content, not stripped-down WAP decks, on the same phones that ran WAP. Opera Mini reached 100 million users by 2010.

Apple’s Mobile Safari, launched January 9, 2007 with the iPhone, did not transcode or simplify. It rendered full desktop websites on a 480 × 320 pixel screen, using pinch-to-zoom for navigation. Jobs’s demonstration of the iPhone browser at the 2007 Macworld keynote — loading the full New York Times website, zooming to individual articles — was the moment WAP’s obituary was written.

The iPhone showed that a mobile device with sufficient processor speed (a 412 MHz ARM), sufficient memory (128 MB), sufficient battery (managed by aggressive power management), and a sufficiently capable browser could provide the real web, not a simulacrum of it. The constraints WAP had been designed around — slow processors, tiny memory, high latency — were constraints that would eventually be overcome, and a system designed for those constraints became obsolete when they were.

Dead End: Building for Today’s Limits

WAP’s failure is a case study in what happens when an industry builds for the present and architects permanently in constraints that are temporary. The WAP consortium was correct that 1997 phones could not render HTML. It built a replacement web for 1997 phones. By the time those phones were replaced — within five years — by devices capable of rendering real HTML, WAP was locked into carrier infrastructure, content development practices, and user expectations that made it hard to abandon.

The deeper failure was economic. WAP put carriers at the center of the mobile internet: they operated the gateways, they curated the content portals, they billed for data. This was comfortable for carriers because it replicated the control they had over voice services. It was wrong for users because it made the mobile internet a toll road with limited destinations rather than an open network.

i-mode preserved carrier centrality while providing richer content, which is why it worked in the short term. The iPhone removed carrier centrality entirely, which is why it worked permanently.

The companies that dominated the PC web — Google, Amazon, eBay, the New York Times — had no presence in the WAP ecosystem. The companies that dominated WAP — ringtone vendors, SMS quiz services, carrier portal operators — had no presence in the smartphone web. The mobile internet did not evolve from WAP; it was built from scratch on the architecture the internet had always used, once the hardware caught up.