iOS allows alternative browser engines in Japan

Regulation and regional carve‑outs

• Commenters note Japan’s new law (and earlier EU rules) forced Apple’s change; the US is still excluded, which some see as punitive or strategic.
• Many criticize Apple for implementing “better” rules only where legally required, via region flags and location checks, rather than globally.
• Some worry this country‑by‑country patchwork is complex but others argue Apple can easily afford that complexity.

Why Apple banned other engines: security or antitrust?

• One camp says the single‑engine policy is mainly about security, battery life, and consistency (no arbitrary code/JIT outside WebKit, easier sandboxing).
• Another camp insists it’s primarily about protecting App Store revenue: preventing capable web apps/PWAs (with Bluetooth, NFC, etc.) from competing with native apps subject to Apple’s 30% cut.
• US DOJ filings are repeatedly cited by critics as evidence of wider anticompetitive behavior.

Safari’s role: modern browser or “new IE”?

• Some developers describe Safari, especially on iOS, as the “new IE”: buggy, slow to adopt standards, missing key APIs (Web Bluetooth, WebXR, orientation/fullscreen, richer PWA support).
• Others counter that WebKit has improved, is highly efficient, mostly standards‑compliant, and that Chrome is closer to the IE‑style de‑facto standard today.
• There is disagreement over whether Safari actually “holds back” web innovation, or whether Chrome’s rapid, sometimes privacy‑hostile feature push is the greater danger.

Technical and policy constraints for alternative engines

• Requirements include: memory‑safe languages or constrained C++ guidelines enforced by tooling, fast patching of vulnerabilities, blocking third‑party cookies, separate binaries, and “browser engine steward” status.
• Some argue Chrome and Firefox already meet most conditions, so the rules are reasonable “table stakes”; others call them vague, selectively applied, and clearly designed to be onerous.
• The lack of system‑wide engine replacement (only per‑app embedding) and bans on shared login state are seen as major practical limitations.

Chrome monoculture vs competition

• One view: allowing Blink on iOS will entrench Chrome further, leading to “only works in Chrome” sites and a true engine monoculture.
• The opposing view: banning competing engines cannot increase competition; users deserve choice even if Chrome gains share, and regulators should attack monopolies directly.

PWAs, adblocking, and real‑world impact

• Several developers give concrete examples of being forced into native apps or degraded UX because Safari lacks APIs like Web Bluetooth.
• Others note that PWAs are already successful on Windows/Android, and argue Apple’s hostility has suppressed their broader adoption.
• Many hope for a “real” Firefox with full uBlock Origin; current options like Safari’s uBlock Origin Lite and third‑party browsers (e.g., Orion) are viewed as partial workarounds.

Ecosystem control and user freedom

• Broader discussion touches on Apple’s “benevolent dictator” role: tight control sometimes yields good UX and privacy, but at the cost of user/software freedom and third‑party innovation.
• Some advocate abandoning Apple/Google entirely for GrapheneOS or Linux phones; others reply that mainstream users prioritize integration, polish, and convenience over openness.