Apple reverses course on death of Progressive Web Apps in EU

Original Article ↗ Hacker News Discussion ↗

Apple’s decision to restore Progressive Web App (PWA) support in the EU after briefly moving to disable it is widely seen as a response to looming enforcement of the EU’s Digital Markets Act (DMA) and public backlash. Commenters debate whether the initial removal was a good-faith legal precaution or “malicious compliance” aimed at protecting App Store revenues by keeping the web as a weaker alternative to native apps. Many argue that limiting PWAs to Apple’s WebKit engine remains anti-competitive and expect further regulatory pressure and potential fines over browser engine lock-in and Apple’s broader DMA compliance strategy.

Apple’s motives and regulatory context

  • Many see the quick reversal as evidence the PWA removal was a tactical or punitive move around DMA compliance, not a hard technical constraint.
  • Others argue it plausibly reflects evolving legal advice and conservative risk-avoidance: disabling features is often the lowest‑risk path when rules are unclear.
  • Several point out Apple has invested in PWAs in recent years, suggesting they don’t literally want to “kill” them, but want them constrained and under WebKit.
  • There’s debate whether this episode will strengthen EU enforcement; some expect more fines and “U‑turns,” especially around Apple’s fee structures.

DMA interpretation and legality

  • One camp argues the DMA clearly requires that any capability Safari/WebKit has (including PWAs) must be equally available to 3rd‑party engines, and that restricting PWAs to WebKit is self‑preferencing and non‑compliant.
  • Others say the text is more ambiguous: PWAs may be considered an OS feature, not a “browser engine” obligation; web developers may not qualify as “business users” under DMA definitions; and PWAs are not a designated “core platform service.”
  • Several note the EU has only said it’s “looking into” PWAs; there’s no explicit sign-off on WebKit‑only yet. Any “back-channel approval” is speculative.

Technical and security arguments

  • Apple’s stated rationale: its current PWA architecture assumes a privileged WebKit runtime (Web.app); re‑architecting for multiple engines, secure app‑level isolation, push infrastructure, and background behavior would be large, rushed work.
  • Supporters emphasize iOS’s tighter security and battery constraints vs macOS, and argue arbitrary engines with background service workers, storage, and notifications expand the attack surface.
  • Critics counter that Android, Windows, and macOS support multiple engines and PWAs without catastrophe; they see “security” as a pretext to protect App Store revenue and control.

Browser competition and the open web

  • Many worry Apple’s WebKit lock‑in has stalled PWA capabilities for a decade and prevented real browser competition on iOS; Safari’s PWA support is seen as years behind Chromium.
  • Others claim a WebKit baseline on iOS actually restrains Chrome’s dominance and protects users from more invasive tracking.

Developer and user impact

  • Some developers rely heavily on iOS PWA features (especially push notifications) and saw the removal as existential; the reversal is a relief but trust is shaken.
  • Several predict future fights: third‑party engines wanting equal PWA capabilities, scrutiny of Apple’s “core technology fee,” and broader antitrust pressure on App Store and Safari policies.