A browser-first plan for the iPhone
When the first iPhone arrived, Apple had not opened the door for outside developers to install ordinary native apps. The intended alternative was a web app: software built with web technologies and opened in Safari, more like a capable website than a program installed on the phone.
That approach offered Apple a narrower, more predictable way to expand what the iPhone could do. Developers could build experiences without Apple distributing a new kind of software, and users would access them through the browser. It also limited what those programs could do: they depended more heavily on the web and had less direct access to the phone’s features than native apps could have.
Why the compromise changed
The tradeoff became harder to ignore as developers and users wanted software that felt fully at home on the device. A native app could be designed around the iPhone’s interface and use its capabilities more directly; a browser-based version could feel constrained by the browser’s boundaries. Jobs’s concern about poorly made software pointed toward control, but keeping third-party apps out also meant giving up much of the creativity they could bring.
Apple eventually introduced tools for building native iPhone software and a centralized App Store for distributing it. That changed the problem from “Should outsiders make apps?” to “How should Apple manage the apps they make?” The store gave developers a route to reach iPhone owners while giving Apple a role in reviewing and distributing software—an arrangement that expanded the phone’s possibilities without surrendering all control.
The shift mattered because the iPhone became more than a device with Apple’s built-in features: its usefulness could grow through software made by people outside Apple, while the company still shaped how that software reached users.
