So after the EU and the UK, Japan is now putting an end to Apple's iOS alternative browser engine ban too.
Those are 3 large jurisdictions, I wonder if that's now a market big enough for Chrome and Firefox to invest into iOS versions of their browser that use Blink and Gecko under the hood. From what I heard this was one of the main reasons they haven't done it yet.
I wonder if it would make more sense and be easier for Firefox to switch to Blink, working together with Google making an alternate browser engine for iOS.
AFAIK the main reason is that only the EU+UK cared about these rules and their market share is too small for companies like Google or Mozilla to invest into.
Because of the way the App Store works, browser engines segregated by region need to be two different apps. That means maintaining two source trees (EU+UK+JP vs worldwide) and two releases with two reviews.
I expect niche browsers to have a go at porting to iOS at some point (I'd love to see a project like Ladybird be the first non-Safari browser on the app store!) but for the major companies it seems like too much of a hassle at the moment.
Culturally, the Japanese aren't likely to care. Take a look at Linux usage in Japan to get what I mean. You will have a small but very dedicated group of users who won't change for anything, and then the masses who just use what is convenient. They don't like tweaking.
This is good news, the US should join in aswell in stopping this despicable behaviour by Apple. Apple handicaps browsers because web apps are the only viable alternative to Native Apps which generate huge commission for Apple.
It's a factor in the DOJ antitrust case that's going to trial soon -
> 43. Developers cannot avoid Apple’s control of app distribution and app creation by making web apps—apps created using standard programming languages for web-based content and available over the internet—as an alternative to native apps. Many iPhone users do not look for or know how to find web apps, causing web apps to constitute only a small fraction of app usage. Apple recognizes that web apps are not a good alternative to native apps for developers. As one Apple executive acknowledged, “[d]evelopers can’t make much money on the web.” Regardless, Apple can still control the functionality of web apps because Apple requires all web browsers on the iPhone to use WebKit, Apple’s browser engine—the key software components that third-party browsers use to display web content.
More likely because otherwise companies would have no reason to support Safari, they'd tell everyone to download chrome like they do on desktop - then google would have no incentive to optimize chrome for iOS because what would you use otherwise?
Ideally, the next step is for the US FTC to break up Google. This will probably have to wait until 2028, but it could happen earlier — it doesn't seem to be hard to get on this administration's bad side.
Looks like Japan learned from the malicious compliance shenanigans Apple is pulling with the EU. I hope Apple gets served some substantial fines that really hurt when they try to pull the same shit there. And I say, "when", not "if".
I found the power of "It can be done" amazing. One country does it, everyone else thinks "It can be done, we don't want to be left behind" after 20 years of this being impossible.
I would welcome if this global legislative push would end up in a more open app ecosystem for iOS overall.
BrowserEngineKit is a thin wrapper over XPC and iOS' extension system. The system would be so much better to develop for if XPC was an open API, and JIT for isolated sub-processes was permitted without Apple's blessing.
* Messengers could have separate sub-processes for preprocessing untrusted inputs -- iMessage already does this, third-party messengers are single-process and cannot.
* Applications could isolate unstable components for better user experience and crash recovery.
* Emulators, e.g. for retro systems, would benefit from speedy emulation.
* WASM would become useful in iOS.
* Browser could use XPC without special-purpose API wrappers such as BrowserEngineKit.
But alas, all of this would make it easier to load code that runs at native speed into an iOS app after a store review happened, and as we all know that'll be the end of the world.
* in Japan. Apple has made it clear that they are willing and able to only allow consumer choice if they are in the jurisdiction where they are required to. I live in Norway, so I’m not able to sideload apps, because Norway, despite usually being lumped in with “the EU” is not actually part of the EU, and thus not covered by the EU ruling.
Of all the things that iOS could do, why browser engine is so important? Is there anything to them other than UI nowadays, especially on small form factor?
> the determination is made based on the degree of likelihood that [it will prevent alternative browser engines]
If you interpret that very liberally, doing a region-locked "you can release
alternate browser engines but only regionlocked to japanese apple accounts" could be seen as intentionally preventing alternative browsers from existing.
Why would mozilla port firefox when it can only target a tiny fraction of its users?
I know it's not super realistic, but maybe there's a path to global browser choice in there.
Japan has a funny relationship with Apple. For example, the Felica ( https://en.wikipedia.org/wiki/FeliCa ) based ticket system is built into every iPhone globally, making life in Japan significantly easier for foreign iOS users. More surprisingly actually using the tickets does not require any app at all - you just use Apple Pay.
This is all narrowing the scope of what advantages native apps have (they do still have advantages), but it's hard to argue they simply aren't moving gatekeeping to other areas.
We've got to assume that Google have internally been developing "real" Chrome for iOS for a long time, so that it'll be ready to go immediately, right?
I think this is a net good in the long term. Even if you completely exclude obvious benefits, like being able to support more APIs than Safari, it forces Apple to actually compete with other browsers and implement things if they start getting real market share.
Not that you really should, but Safari has a limit of 500 tabs. Why? It's arbitrary. Safari doesn't support WebRequest in blocking mode, so you can't have real adblockers (just MV3 style content blockers, like uBOL). There are all sorts of edge cases too, like if you want cross-browser sync and extensions. Sure, you can totally run Safari with extension support, but extensions in e.g., Orion are shaky at best.
The biggest claim that Apple made about this whole thing was that web browsers offered an attack surface increase as a result of giving JIT to other browsers, and they could be owned. Frankly, though, I would take a browser without JIT if I had a real adblocker.
Everybody is talking about Chrome, but I tell ya what I have that disabled on my Android in favor of Firefox. Firefox on mobile with full-fat uBlock Origin is the closest thing to parity with desktop web access you can get.
I don't just block ads, I block elements on sites I don't care about with :has-text RegEx rules. You can't do that on Chrome even on desktop anymore.
I'm this close to swapping to the Android as my primary device-- it's iMessage that has me chained. It's just too dang nice to respond to chats from my Mac during work so I don't need to pick up my phone.
Everything else is better on the Android. Don't get me started about the iOS keyboard or Siri.
I spent years laughing at other people’s autocorrect fails until I switched from Android. The iOS keyboard experience is unspeakably bad. There’s a point every day where I think, “maybe I’ll just sell the iPhone and get another Pixel, despite Google’s creep factor.”
45 comments
[ 4.4 ms ] story [ 45.8 ms ] threadThose are 3 large jurisdictions, I wonder if that's now a market big enough for Chrome and Firefox to invest into iOS versions of their browser that use Blink and Gecko under the hood. From what I heard this was one of the main reasons they haven't done it yet.
Because of the way the App Store works, browser engines segregated by region need to be two different apps. That means maintaining two source trees (EU+UK+JP vs worldwide) and two releases with two reviews.
I expect niche browsers to have a go at porting to iOS at some point (I'd love to see a project like Ladybird be the first non-Safari browser on the app store!) but for the major companies it seems like too much of a hassle at the moment.
> 43. Developers cannot avoid Apple’s control of app distribution and app creation by making web apps—apps created using standard programming languages for web-based content and available over the internet—as an alternative to native apps. Many iPhone users do not look for or know how to find web apps, causing web apps to constitute only a small fraction of app usage. Apple recognizes that web apps are not a good alternative to native apps for developers. As one Apple executive acknowledged, “[d]evelopers can’t make much money on the web.” Regardless, Apple can still control the functionality of web apps because Apple requires all web browsers on the iPhone to use WebKit, Apple’s browser engine—the key software components that third-party browsers use to display web content.
https://storage.courtlistener.com/recap/gov.uscourts.njd.544... (p22)
BrowserEngineKit is a thin wrapper over XPC and iOS' extension system. The system would be so much better to develop for if XPC was an open API, and JIT for isolated sub-processes was permitted without Apple's blessing.
* Messengers could have separate sub-processes for preprocessing untrusted inputs -- iMessage already does this, third-party messengers are single-process and cannot.
* Applications could isolate unstable components for better user experience and crash recovery.
* Emulators, e.g. for retro systems, would benefit from speedy emulation.
* WASM would become useful in iOS.
* Browser could use XPC without special-purpose API wrappers such as BrowserEngineKit.
But alas, all of this would make it easier to load code that runs at native speed into an iOS app after a store review happened, and as we all know that'll be the end of the world.
If you interpret that very liberally, doing a region-locked "you can release alternate browser engines but only regionlocked to japanese apple accounts" could be seen as intentionally preventing alternative browsers from existing.
Why would mozilla port firefox when it can only target a tiny fraction of its users?
I know it's not super realistic, but maybe there's a path to global browser choice in there.
This is all narrowing the scope of what advantages native apps have (they do still have advantages), but it's hard to argue they simply aren't moving gatekeeping to other areas.
Not that you really should, but Safari has a limit of 500 tabs. Why? It's arbitrary. Safari doesn't support WebRequest in blocking mode, so you can't have real adblockers (just MV3 style content blockers, like uBOL). There are all sorts of edge cases too, like if you want cross-browser sync and extensions. Sure, you can totally run Safari with extension support, but extensions in e.g., Orion are shaky at best.
The biggest claim that Apple made about this whole thing was that web browsers offered an attack surface increase as a result of giving JIT to other browsers, and they could be owned. Frankly, though, I would take a browser without JIT if I had a real adblocker.
Hope you guys like Chromium!
I don't just block ads, I block elements on sites I don't care about with :has-text RegEx rules. You can't do that on Chrome even on desktop anymore.
I'm this close to swapping to the Android as my primary device-- it's iMessage that has me chained. It's just too dang nice to respond to chats from my Mac during work so I don't need to pick up my phone.
Everything else is better on the Android. Don't get me started about the iOS keyboard or Siri.
I've been doing this on Signal for years.