For years, one of the most unusual rules in consumer tech has quietly shaped how the web behaves on phones: on iPhones, every browser must run on Apple’s WebKit engine. That means Google’s Chrome, Mozilla’s Firefox and others are little more than skins — the browsing experiences you think come from Google or Firefox are, in most technical respects, riding on Safari’s guts. Now, Japan has put a hard date on dismantling that rule: regulators have published guidance that, by December 2025, would force Apple to stop blocking third-party browser engines on iOS — and to avoid the kinds of technical and financial hurdles that previously kept competitors out.

Apple has already faced rules in the EU and UK designed to loosen its tight grip on the iPhone ecosystem. But those rules left gaps — legal and technical wiggle room that Apple has used to keep control (a practice some industry watchers have called “malicious compliance”). Japan’s new guidance, part of its Mobile Software Competition Act (commonly discussed alongside the “Smartphone Act”), specifically calls out the kinds of workarounds that preserved Apple’s browser monopoly in Europe — and sets a clear compliance timetable that ends this year.

That matters because Japan is not just another market: it’s large enough and sophisticated enough that a regulatory change there can’t be ignored. If Apple must permit non-WebKit engines in Japan, some browser vendors and app developers will have a live market to test real, engine-level competition on iOS for the first time.

The translation circulated by Open Web Advocacy, a nonprofit that follows web-standards and competition issues, frames the rule simply: designated platform providers (read: Apple) may not impose unreasonable technical restrictions, levy excessive costs on app providers who use alternative browser engines, or steer users away from apps that run those engines. In short, Japan’s guidance doesn’t only say “allow third-party engines”; it says “don’t build a maze of technical or financial gates to make the change useless.”

That combination of requirements is consequential. Previously, Apple’s WebKit mandate wasn’t just a checkbox — it shaped APIs, performance assumptions, app store rules, and user-experience conventions. Preventing Apple from creating secondary rules that mimic a ban narrows the options Apple has to preserve the status quo in ways that look legal on paper but block competition in practice.

If enforced as written, the most obvious short-term effect is that browsers could ship on iPhone with their own engines: Chrome might actually run Blink; Firefox could run Gecko; smaller vendors might deploy lighter, experimental engines. That would let different browser makers innovate independently of Safari’s roadmap — new rendering features, different JavaScript engines, alternative privacy models and developer-facing capabilities could all arrive on iOS without having to pass through WebKit’s filter.

For developers, the change would end a long squeeze: today, if you test a website on Chrome for iOS you’re really testing on WebKit. A multi-engine world would make cross-browser testing more real, but it also raises short-term complexity: web compatibility expectations, browser bugs and performance disparities could increase while the ecosystem adjusts.

Allowing other engines is one thing on paper; shipping them reliably and securely is another. Apple will need to accommodate alternative engines at the OS and platform level — exposing APIs, memory models and system integrations without compromising security or privacy guarantees it says are core to the platform. Browser vendors will need to port engines to iOS constraints (ARM builds, battery and memory limits, integration with iOS features) and test them thoroughly. That work takes months of engineering — which is why observers caution that visible alternatives might not land instantly on December 1, 2025, even if the legal bar is met.

There’s also money. Apple benefits from default search deals and in-app economics that favor its own browser and ecosystem. Regulators in Japan apparently considered that in the guidance, by forbidding “steering” and excessive financial burdens, they’re trying to ensure that Apple’s business arrangements don’t simply replace a hard ban with a softer, more lucrative barrier.

What Apple might do — and what vendors are likely to do next

Historically, Apple has used a mix of legal appeals, phased technical changes and careful policy language to push back on regulatory pressure. Expect a familiar playbook: negotiations with Japanese authorities, possible legal challenges, and a set of proposed technical standards that attempt to balance Apple’s security claims with regulators’ openness goals. At the same time, browser vendors and smaller app makers will likely accelerate engineering work so they can hit the market quickly if the law is finally enforced.

Google, for one, has long said it wants Chrome to ship with Blink everywhere; Mozilla has argued the move is essential to the health of the open web. Those players have real incentives to show up quickly in Japan. But even for them, the work of supporting a parallel iOS engine — packaging, integrating, passing App Store review — is nontrivial.

This ruling is not an instant victory for openness — it’s a serious nudge in that direction. If Japan’s December deadline sticks and enforcement is robust, we’ll likely see a staggered rollout: early experiments and alternative engines in Japan first, legal and operational wrangling in global headquarters next, and then potential ripple effects elsewhere as regulators and markets watch what happens. For users, that could mean a more pluralistic mobile web in the years after 2025. For Apple, it means recalibrating a platform strategy that for nearly two decades has relied on a single, tightly controlled browser stack.

What to watch now

• Will Apple comply by December 2025, or seek to delay through legal action?
• Which browser vendors have working ports or prototypes that can run on iOS without WebKit?
• How will Japan enforce compliance — fines, forced changes to app review, or both — and will that enforcement be public and swift?

The next few months will be a pressure cooker for platform policy and browser engineering. If regulators keep their nerve and vendors move fast, the long-promised day of true engine choice on iPhone could finally arrive — not as an abstract victory for competition lawyers, but as a set of measurable differences in the browsers your phone can actually run.