Using alternative browser engines in the European Union
Apple’s move to allow alternative browser engines only on iOS devices in the EU, to comply with new regulations, is drawing fire for what many see as “malicious compliance” designed to preserve its App Store and WebKit dominance. Commenters debate whether Apple’s stringent security and privacy requirements for third-party engines are genuine protections or anti-competitive barriers that could still exclude Chrome, Firefox, and others. The exchange highlights broader tensions between platform control, user choice, web standards progress, and the risk of further entrenching Google’s Chrome as the de facto web platform.
Scope: EU-only and “malicious compliance”
- Apple enables alternative browser engines only in the EU because law compels it there; no similar pressure elsewhere.
- Many see Apple’s response as hostile or “malicious compliance”: lots of complexity, EU-only binaries, and feature carve‑outs rather than a straightforward global opening.
- Some argue this will eventually spread worldwide; others note EU is a relatively small share of App Store revenue, so Apple may limit changes to that region.
Security, privacy, and monopoly incentives
- One camp accepts Apple’s framing: alternative engines and app stores increase attack surface, support costs, and risk of data-harvesting browsers (e.g., social networks shipping “browser” shells).
- Others counter that:
- iOS already sandboxes apps, so browsers should not endanger the whole phone.
- Safari/WebKit and iMessage themselves have had serious vulnerabilities.
- Chrome’s security record may be stronger, and current WebKit-based browsers already sync data and “phone home”.
- “Security/privacy” is largely a pretext to protect App Store revenue and weaken PWAs/web apps that could bypass it.
Sandboxing, JIT, and Lockdown Mode
- WebKit runs with elevated privileges (JIT, multiprocess) outside normal app sandboxes; alternative engines will gain similar privileges under strict criteria.
- Lockdown Mode disables WebKit JIT system‑wide, cutting JS performance but reducing exploitability.
- Regular third‑party apps historically could not use JIT; WebViews do via separate processes.
Alternative app stores, support burden, and user behavior
- Some argue more stores/browsers will generate more breakage and support calls, with minimal upside for average users who are content with defaults.
- Critics reply that:
- Desktop OSes and macOS handle multiple stores and browsers.
- Apple already hosts malware occasionally in the App Store, so centralization isn’t a silver bullet.
- Walled gardens should be opt‑in, not mandatory; technically literate users want the option.
New engine requirements and potential gatekeeping
- Requirements include: EU-only distribution, passing web platform tests, blocking third‑party cookies, and using memory‑safe languages or mitigations for web‑facing code.
- Commenters see these as:
- Reasonable in principle for a high‑risk component like a browser engine, but
- Vague enough (“features that improve memory safety”) to let Apple arbitrarily block engines, especially smaller ones.
- Some doubt even Safari/WebKit would fully meet the stated bar; others expect Apple must at least allow Chrome/Blink and Firefox/Gecko or face further EU action.