Mobile won the platform war on distribution, not capability

Table of contents
A small figure stands inside an iron-and-brick archway, holding a glowing 'update' envelope. The gate in front is closed with a heavy padlock. Through the archway, a city of stylised app-icon tiles.

The platform fight in one frame. The maintainer holds the update; the gatekeeper holds the key.

The narrative says mobile won and the web lost. Until the early 2020s, the narrative was simply correct. Mobile was the winner, top to bottom. Then the developers shipping inside the store started taking one too many rounds of platform hardening, and the question quietly changed: not whether mobile had won the platform war, but what it had won on.

For most of the last decade the rest of us, the ones writing the apps, treated the platform war as settled. Mobile is where the users are. Mobile is where the install button is. Mobile is where attention compounds. Some of that is true. Most of it points at something quieter than “mobile won on the merits,” and that quieter thing is worth naming, because it changes what you think the platform fight was actually about.

What mobile did not win on

Mobile did not win on capability.

Location, offline storage, push notifications, camera access, background sync. Every one of those is a table-stakes feature a competent web app handles in 2026. The set of apps that exist only because of irreplaceable device capability is a thin residue, and the residue is honest, not a hand-wave.

  • UPI and payments in India. You walk to the shop, you scan the QR, you pay. The phone is the physical artifact in your hand and the channel for the transaction. A web app cannot meaningfully be a UPI client because the channel is the device. This is a genuine native-strong category, not a quibble.
  • A handful of games. Frame-budget competitive games. AR-heavy games (Pokémon GO, Snap-style lenses) where the GPU and the sensors are the product, not the wrapper.
  • Delivery and on-demand apps, with a tell. Swiggy, Zomato, Uber, Ola all have web versions that technically work, but the web experience is consistently thinner than the app, and the app gets the offers, the notifications, the loyalty hooks, the friction-free re-order. Whether that is deliberate channel-suppression or just where engineering attention has been the whole time, the effect is the same. The operators end up with users on mobile, which is where push, location, and the install button live. The channel control is the outcome. The capability gap is the cover story.
  • Deep hardware and pro creative. RAW camera apps, sustained background GPS like Strava, pro audio. The corners where the sensor or the silicon is the product.

That is the residue. Name it, respect it, and then state the claim plainly. For the class of software where the value is the maintainer’s evolving logic rather than irreplaceable device capability, centralized delivery wins. The narrower claim is the stronger claim, and the UPI and delivery beats above strengthen it by showing exactly where the line sits.

What mobile actually won on

Distribution. Store lock-in. The gatekeeper.

The web’s structural advantage was always that the maintainer owns the update channel. Ship a fix on Tuesday, every user has it on Tuesday. No review queue, no fragmented install base, no waiting for the next approval cycle. The maintainer sits at the steering wheel of the runtime.

The store offset that advantage completely, by owning the discovery surface and the install button. Mobile did not beat the web on the merits of the runtime. It beat the web on the merits of the channel. The 30 percent tax was the visible part. The invisible part was that the store owned where new software entered the user’s life, owned the payment rails, owned push-notification registration, owned the install button itself. Everything you needed to acquire and re-engage users sat behind one door, and the door had a key, and the key belonged to two companies.

Electron is the keystone, not the defensive aside

If web-versus-native were the deciding axis, the entire web-shell desktop category should have failed.

It did not fail. It is dominant. Look at the apps you spend the workday in:

  • Slack. Electron.
  • VS Code. Electron.
  • Postman. Electron.
  • Bruno. Electron.
  • Spotify desktop. Chromium-Embedded-Framework rather than strictly Electron (the distinction matters to a pedant and not at all to the argument). Same shape, web-shell desktop app shipping the maintainer’s evolving logic on the maintainer’s cadence.

These are not web apps cosplaying as desktop apps. They are the bridge case. They prove the deciding axis is not “web rendering versus native rendering” but update friction. The desktop has connectivity that mobile envies and patience the App Store never grants, so a 40-megabyte Electron update overnight is fine. The user does not notice. The maintainer ships when the maintainer is ready. The store does not adjudicate. The channel is open.

The lived test is whether you can name when each of these apps last updated. I cannot. I do not check. They silently update overnight, I open them the next morning, the new feature is just there. That is the maintainer’s seat working as designed.

A 2x2 chart titled 'Where the maintainer sits, by surface'. X-axis: channel openness (closed on the left, open on the right). Y-axis: maintainer update autonomy (low at the bottom, high at the top). Top-right quadrant (high autonomy + open channel): Pure web, Electron desktop, Super-apps - the winning quadrant. Top-left (high autonomy + closed channel): a handwritten note 'no class lives here' - a gatekeeper-controlled channel cannot grant the maintainer autonomy. Bottom-left (low autonomy + closed channel): Native mobile app (amber-accent dot) and PWA on iOS (dashed outline indicating channel suppression). Bottom-right: empty.

The diagonal carries the argument: top-right wins, bottom-left loses. The off-diagonal is empty by structural logic, not by accident. A closed channel does not grant the maintainer autonomy; an open channel rarely chooses to ship slowly.

PWAs are the other proof, in reverse

The naive read of PWAs is that they did not win because the technology was inferior.

The accurate read is that Apple deliberately suppressed the delivery channel.

A two-line refresher on why Apple is the gatekeeper here, because the argument depends on it. The iPhone is the only Safari device that matters at the population scale a platform fight is decided on. Every browser on iOS is forced to use WebKit under the hood (the long-standing iOS rule that recently got dented by EU regulation but still describes most of the world’s iPhones). So when Safari ships a capability late or partially, every “Chrome” and “Firefox” user on iOS ships it late or partially too. There is no escape hatch.

Apple controls the runtime, controls the install button, and controls the notification permission. Three brakes on one channel.

The receipts:

  • iOS push notifications for web apps shipped in March 2023 with iOS 16.4, years after Chrome on Android had shipped equivalent support a decade earlier. Apple withheld the single most important re-engagement primitive on the web from the iPhone for the entire formative period of the PWA story.
  • Service worker support on iOS arrived in 2018 with Safari 11.1 but stayed partial and quietly broken for long stretches, with reliability quirks production teams could not engineer around.
  • “Add to Home Screen” was buried so deep in the share sheet most users never discovered it existed. The single discoverable affordance that would have turned PWAs into installable apps was hidden by interface design.
  • App Store review policy actively rejected PWA wrappers from being submitted as App Store apps, closing the workaround.

Maximiliano Firtman has been keeping the receipts on iOS PWA support for years; his Progressive Web Apps on iOS tracker is the canonical reference if you want to see the capability matrix laid out year by year.

A gatekeeper contesting channel control beat a technical advantage. PWAs failing is evidence for the maintainer-seat thesis, not against it. When the channel is suppressed, even the maintainer’s update advantage does not save you.

The honest counter-points

A few things press on the thesis and deserve the breath of an acknowledgement, not a section.

Super-apps (WeChat, KakaoTalk, parts of what Line has tried) bypass the store by being the platform themselves. That is a real exception to “the store owned distribution,” and notice the exception still confirms the lens. The super-app is just a different seat for the same channel control.

Some Electron-first apps have partially returned to native shells for battery, RAM, and animation feel. That move is UX-driven, not update-channel-driven, and those apps still ship as fast as the web-shell crowd.

Apple is slowly loosening the iOS brake under EU regulatory pressure. Web push has finally landed; third-party browser engines are nominally allowed in the EU. The thesis depends on the gatekeeper being real for the decade that decided the platform, not on the brake persisting forever.

The years it was fun, and the year it stopped being fun

I shipped Android apps for roughly a decade, starting around 2010, and I left for backend in 2021. I wrote about the move at the time in from mobile to backend developer. This essay is the second half of why I left, the half I was not ready to write then.

For most of those years it was fun and it paid. The tooling was raw. The libraries were half-baked. The official samples disagreed with each other. None of that mattered, because the platform was a place you could land on with a half-formed idea on a Friday night and have an installable build by Sunday. People wrote weekend apps and made rent off them. Including me. The openness made hobbyists into shippers, and the floor of “what you needed before your first install” was low enough that a curious person could clear it.

Then came Cambridge Analytica in 2018 and the multi-year platform-hardening cycle that followed it. Stricter permission models. Runtime permissions, then background-location separation, then nearby-devices, then a forced photo-picker indirection. Scoped storage, then locked-down scoped storage. Background-execution clampdowns: Doze, App Standby, broadcast limits, foreground-service mandates that kept getting stricter through Android 8, 12, and 14. Play Store policy waves: a target-SDK floor raised every year, Play App Signing made mandatory, attestation through Play Integrity, deprecation of side-loadable APIs. On iOS the equivalent pattern: App Tracking Transparency in 2021, IDFA gating, background-mode purges, notarisation, hardened entitlements.

A horizontal timeline 2010 to 2024 with the title 'Platform hardening, 2010 to 2024'. Six events plotted, labels alternating above and below the line: Open Android, hobbyist era (2011); Doze and App Standby (2016); CAMBRIDGE ANALYTICA (2018, drawn as the amber pivot marker with a vertical guideline crossing the timeline); Scoped storage (2019); App Tracking Transparency (2021); Target-SDK floor escalation (2023). The right half post-2018 has a gray background tint suggesting the platform-hardening era.

The post-Cambridge-Analytica hardening cycle, plotted. Everything right of the amber pivot narrowed the channel on the developers already inside it.

None of these changes was individually wrong. Cambridge Analytica was a real failure of the channel, and most of the hardening was a sane response, or at least a defensible one. Collectively, though, they killed the hobbyist-developer long tail stone dead. The Sunday-afternoon app stopped being shippable. The floor of “what you had to do before your first install” became enterprise floor. The fun went, and so did the hobbyist economy on top of the platform.

That is the second receipt for the thesis, and it is the one I keep coming back to. The gatekeeper does not only control the install button. The channel itself keeps narrowing on the people inside it. You can be in the store and the store can still progressively decide what kind of software you are allowed to ship. The hobby-app death was not a market outcome. It was a channel outcome.

A related observation from inside that decade, honestly framed because the number is mine, not anyone’s research. In roughly ten years of shipping Android apps and watching other teams ship, I can count on one hand the teams who built genuinely new mobile-platform surface area. Widgets that did anything interesting. Shortcuts that worked. Assistant intents. Chat bubbles. The other ninety-nine percent shipped a native version of the website or the iOS app. This is not a complaint about those teams. It is a measurement of where the value in those products lived. The value lived in the maintainer’s logic. The native shell was packaging. Packaging is what the store taxed, and packaging is what the platform hardenings progressively re-priced.

The bridge

The web’s structural advantage was always the maintainer controlling the update channel. Mobile did not beat that on the merits of the runtime; it captured the channel itself, and then it tightened the channel on the people standing inside it. The web-shell desktop category is the proof, because every app on that list ships on the maintainer’s cadence and survives entirely on that fact. PWAs are the proof in reverse, because when the channel is suppressed even the maintainer’s advantage does not save you.

In mobile, the brake we couldn’t control was the gatekeeper.

See Also


Tags