Apple's intentional crippling of Mobile Safari

Original Article ↗ Hacker News Discussion ↗

Apple’s limited support for modern web and PWA APIs in Mobile Safari is described as either a privacy‑focused safety feature or a deliberate strategy to protect App Store revenue by keeping web apps weak on iOS. Commenters argue over whether capabilities like Bluetooth, NFC, WebUSB, and push notifications belong in browsers at all, noting that many are Google/Chromium-led and not widely standardized, while others stress that Apple’s WebKit-only policy on iOS effectively lets it dictate what the mobile web can do. The broader concern is whether this slows meaningful web innovation and entrenches native app silos, or instead prevents a repeat of the “one-engine rules the web” era under a new Chrome monopoly.

Safari feature gaps and user reactions

  • Many commenters like that Mobile Safari omits APIs such as vibration, background sync, Bluetooth, NFC, WebUSB, WebMIDI, and Web Push, seeing the omissions themselves as a “feature.”
  • Others find specific gaps painful, especially Bluetooth/NFC for configuring hardware (ESP32, radios, MFi devices) and Web Push/notifications for communities or utilities that don’t justify a full native app.
  • Some note that several APIs on the referenced comparison page are experimental, Chrome-only, or misrepresented/outdated (e.g., Safari’s existing web push support for home-screen PWAs).

PWAs vs native apps

  • Strong camp preferring native apps: better performance, UX, and clearer permission boundaries; disdain for Electron-like bloat and “webapps everywhere.”
  • Counter-argument: PWAs reduce duplication (one codebase vs separate iOS/Android/web), avoid App Store rules and fees, and give small devs a realistic distribution path. Many key desktop experiences are already web-based.

Standards, Chrome APIs, and browser politics

  • Repeated tension over whether missing features are “web standards” or Blink-only experiments.
  • Some liken Chrome’s behavior to IE-era proprietary APIs, citing Mozilla’s public objections to Web Bluetooth/NFC on security/privacy grounds.
  • Others argue Apple leverages W3C influence to stall APIs that threaten App Store revenue, blocking broader standardization.

Apple’s iOS control and antitrust concerns

  • Core complaint: iOS forces all browsers to use WebKit, so Safari’s limits become hard platform limits. Developers cannot tell users to “just install another engine.”
  • Critics frame this as abusive, more extreme than Microsoft’s IE bundling, and link to ongoing antitrust action.
  • Defenders say this helps resist full Chrome dominance and preserves privacy/security.

Security, privacy, and hardware-access APIs

  • Many see exposing Bluetooth, NFC, contacts, sensors, etc., to the web as unnecessary attack surface and tracking vectors.
  • Others insist consent dialogs plus OS mediation are enough, and that blocking entire classes of capability “for security” is overreach that stifles innovation.

Safari UX and PWA ergonomics

  • Complaints about iOS Safari discoverability: Add to Home Screen and in-page search buried behind ellipses/share; PWA installation flows seen as intentionally clumsy.
  • Some developers describe real bugs and crashes (canvas, Web Audio, Media Session) that make Mobile Safari feel neglected, reinforcing the perception of intentional PWA sabotage.