9.1 When a site becomes an app
Module 8 left a site that installs a service-worker proxy, caches its own shell, stores its own data, and works offline. Add a web app manifest — a small file naming the app, its icons, and how it should launch — and the browser will offer to install it: an icon on the home screen or dock, a window with no address bar, a cold start that loads from the cache. This is a Progressive Web App, and the word that matters is progressive: the same code is a normal web page for a first-time visitor and a full application for someone who installed it. There is no separate build, no store submission, no gatekeeper. The document and the app are the same artifact at different points on a continuum.
The web app is not a different kind of thing from the web page. It is the same page, after the browser agreed to treat it like software.
9.2 Capabilities and the permission gate
An application needs to reach hardware: camera, microphone, location, notifications, USB, Bluetooth, the filesystem. The web exposes these through APIs, and Module 1 called those APIs the platform's syscall surface. But unlike a syscall, each one is gated — twice. A powerful capability requires a secure context (HTTPS, the Module 2 padlock) and explicit, revocable user permission, requested at the moment of use and scoped to the origin.
9.3 The browser watching itself, and the user's hooks
Two more platform surfaces deserve a mention before the politics. DevTools — the panels every lab in this series has used — is the browser instrumented to observe its own subsystems: the network waterfall (Module 4), the render and main-thread tracks (Modules 5 and 6), the storage and cache inspectors (Module 8), the security and origin views (Module 7). It is the rare platform that ships a complete X-ray of itself to every user. Extensions are the other hook: user-installed code that can read and rewrite pages, the one place where the person, not the site, programs the browser — powerful enough to block ads and trackers, and powerful enough to be dangerous, which is why their permissions and review are themselves a running controversy.
9.4 The false binary: app versus site
Here the module turns. We have a platform that installs, works offline, reaches hardware, and persists data — a platform, by any technical measure, capable of the things “apps” do. So why do we still speak of apps and websites as different categories of thing? The honest answer is that the distinction is mostly commercial and political, not technical. It is maintained because a great deal of money depends on it. Understanding the browser as a platform means understanding the economics that keep the platform from being treated as one.
9.5 The app store as tollbooth
A native app reaches an iPhone through one door: Apple's App Store, which historically took a commission of fifteen to thirty percent on sales and required Apple's own payment system, while forbidding apps from even mentioning cheaper options elsewhere — the “anti-steering” rule. Critics call this rent: a tax on commerce that flows through a device the user already bought, enforced by control of the only distribution channel. Apple maintains the commission pays for a curated, secure, private marketplace and the platform it is built on. Courts and regulators have spent years between these positions. The long Epic Games litigation forced Apple, in the United States, to let developers link to outside payment options; Apple's attempt to keep charging a high commission on those external purchases was found to defeat the purpose, and as this is written the permissible fee is still being fought over up to the Supreme Court. Google, facing a parallel case, settled and dropped its Play Store commission. The numbers move; the structural question does not. Whoever controls distribution controls the economics of everything distributed.
The web has no such door. A web app is published by putting it on a server, and it takes no commission and asks no permission. This is precisely why the web is a threat to the store model — and why the next fight matters so much.
9.6 The iOS engine monopoly
For most of the iPhone's life, a single rule shaped the entire web on it: every browser on iOS, including Chrome and Firefox, was required to use Apple's own WebKit engine underneath. The Chrome on an iPhone was Chrome's interface wrapped around Apple's renderer. The consequence is the quiet center of the whole story: if the only engine on the most lucrative mobile platform is one the platform owner controls, then the platform owner sets the ceiling on what web apps can do there. Hold that ceiling low — ship web capabilities slowly, leave install and notification and hardware support thin — and web apps stay a weak substitute for native ones, which keeps developers in the App Store, which protects the commission. The engine rule and the store economics are the same lever.
Apple's stated rationale is security, privacy, performance, and battery life: a browser engine is exposed to hostile content and deep in the system, so Apple argues it must control the one engine on iOS. Open-web advocates answer that the secure, interoperable alternative already exists — it is the web and web apps — and that no other platform imposes such a ban. The European Union's Digital Markets Act sided with the advocates: since 2024 Apple has been required to permit alternative engines on iOS in the EU. Yet in practice almost none have shipped, because the terms attached — a separate EU-only app, locally based engineering, missing system APIs, restrictive contracts — have kept the door technically open and practically shut, which advocates and regulators argue is non-compliance by other means. Japan's smartphone law set its own deadline; the UK is investigating; Apple is appealing. The outcome is genuinely undecided.
The phrase to sit with is if it breaks. If real engine choice arrives on iOS — a true Blink or Gecko browser, with the full web platform behind it — then web apps could match native ones where they currently cannot, the case for the store as the only door weakens, and the thirty percent looks less inevitable. That is why this is fought so hard. A browser-engine rule sounds like an obscure technical restriction. It is one of the most consequential economic policies on the internet.
9.7 The monoculture problem
There is a second monopoly, and the open web is on the wrong side of this one too. Collapse every browser to its rendering engine and the field is tiny. As of 2026, roughly four in five web sessions run on Chromium's Blink engine — Chrome, Edge, Opera, Brave, Samsung Internet, and the rest share it. Most of the remainder runs on Apple's WebKit, largely because iOS forces it. Mozilla's Gecko, the last fully independent engine, is under three percent and has declined for years.
We have been here before, and the history is the warning. The first browser war ended around 2001 with Internet Explorer holding some ninety percent of the market — and then years of stagnation, because a dominant engine with no competition has little reason to improve, and the web ossified around one vendor's quirks and bugs. The standards-based revival that followed, and the engine diversity that drove it, is much of why the modern web exists at all. A monoculture is fragile and slow by nature: when one engine defines the web, “works in Chrome” quietly replaces “follows the standard,” the standard becomes whatever that engine does, and the power to evolve the platform concentrates in one company's roadmap. That an independent engine like Gecko is endangered is not a Mozilla problem; it is a problem for everyone who wants the web to remain a commons rather than a product.
9.8 Two comfortable fallacies
The app-versus-web hierarchy rests on two widely held beliefs that do not survive contact with this series. Both are worth dismantling carefully, because both contain a grain of truth.
“Native apps are safer and more private.” Often the reverse is true. A web page runs inside the sandbox and origin isolation of Modules 1 and 7: no installation, no standing access to your files or other apps, hardware reached only through the prompted, revocable gate of Figure 9.1, and no durable device identifier by default. A native app is installed software with broad device reach, frequently bundling third-party tracking SDKs the user never sees, behind permissions granted once and rarely revisited. App-store review and platform hardening are real and do catch things — the grain of truth — but the intuition that the sandboxed, ephemeral, per-origin web is the looser security model has the architecture backwards. The web's containment is stronger precisely because it assumes every page is hostile.
“Apps are faster because the web is slow tech.” Mostly the gap is not the rendering engine; it is the network and the packaging. A native app ships its assets pre-installed and loads them from local storage; a web page has historically fetched them over the network on demand (Module 4). But that is exactly the gap a service worker and the cache close (Module 8): a well-built PWA loads from local storage too, and the render pipeline of Module 5 is the same pipeline either way — on iOS, often literally the same WebKit. Where native genuinely wins is heavy sustained computation, low-latency graphics, and the deepest hardware integration — real and fair advantages. But the everyday “the app just feels faster” is usually an engineering and caching story, sharpened by an artificial capability ceiling, not a verdict on the web as a technology.
The web is not the insecure, slow option that the app makes safe and fast. That hierarchy is mostly a story told by whoever owns the store.
9.9 The browser is everywhere, often in disguise
The final twist undoes the binary completely: a great many of the “native apps” on your machine are browsers, wearing a costume. The browser engine turned out to be such a capable application runtime that it has been embedded nearly everywhere.
The editor a developer writes in, the chat client a team lives in, the music app, the desktop client of the social network — a remarkable share of them are Chromium in a frame, web technology shipped as a download. Capacitor and Cordova do the same on mobile, wrapping a web app in just enough native shell to enter the App Store. So the app-versus-web binary collapses twice over: web apps can do what apps do, and a huge fraction of apps are web apps already, paying the store's toll for the costume rather than the substance. The browser did not lose to native. It is inside native, doing the work, frequently unacknowledged.
9.10 The cast, and what the platform owes them
This series began with a cast — the people and programs on the other end of every request — and they are the reason the politics matter as much as the pipeline. A platform controlled by one engine and one store is not just an economic problem; it is a problem for everyone the cast represents.
9.11 The series ends here
Nine modules, one claim: the browser is the operating system of the web, and every web technology is a program running on it. We traced a URL through the I/O subsystem to the first byte; watched a parser turn bytes into the DOM; followed a page's dependency tree through the loader and its render-blocking choices; ran the pixel pipeline of style, layout, paint, and composite; met the single-threaded event loop that schedules all of it against a sixteen-millisecond budget; walked the origin-based security model that decides who may touch what; opened the storage and caching layers that make the browser a filesystem; and arrived here, at the platform and the contest over who controls it. The operating-system frame held the whole way down, because it is not a metaphor. It is what the thing is.
Where this series dissected the runtime, its companions build on top of it. HTML for Programmers is the language the parser consumes; CSS for Programmers is the system the render pipeline executes; The Web for Programmers is the protocols and the history beneath all of it. The platform-first ethos they share has a sharper edge now that you have seen the machine: writing for the platform rather than around it is not only cleaner engineering, it is a small vote for the web staying a platform anyone can build on without a gatekeeper's permission. You now know what the browser is doing when it runs what you wrote. Build for it accordingly.
The browser is the operating system of the web — the most widely used, least understood, and most contested platform we have. Understanding it is the beginning of defending it.