Everyone talks about sideloading as something to circumvent 30% tax. While maybe true, I'm interested to see if sideloading would allow new browser engines, like gecko or chromium. This will open a ton of possibilities weakening even more the walled garden
Worth noting that side-loading and rooting are not the same thing. Various aspects of the OS (APIs) would still be locked down, whether you can sideload apps or not. So you would not see all the cool tweaks that were (are?) available to jailbreakers.
A simple way to answer that question is – is the only roadblock to building a custom browser in iOS that Apple will reject it during the review process? Or are there some fundamental missing APIs or piece of functionality in the platform itself? The latter gap will not be fixed even if you are able to bypass the App Store.
Varenc below is right. Side loading only bypasses the App Store, all the iOS security controls are still in effect.
That means there is no way to do things current apps can’t. You can’t make a JIT, so no good alternate browsers. You can’t install other apps, so no making your own store. You can’t make background services like a web server that will always run. You can’t make widgets that are more interactive than what exists now. Nor can you get GPS data without or force the microphone on, the user still has to agree.
Side loading gets you side loading. You don’t get expanded privileges without exploits. And expect Apple to be working really hard right now at putting stronger enforcement on private APIs and preventing sandbox escape or limiting access if you do.
> [...]Furthermore, the gatekeeper shall allow business users and alternative providers of services provided together with, or in support of, core platform services, free of charge, effective interoperability with, and access for the purposes of interoperability to, the same operating system, hardware or software features, regardless of whether those features are part of the operating system, as are available to, or used by, that gatekeeper when providing such services. - Digital Markets Act
So you’re right about stores. You have to be able to side load and install new spa from your side loaded store.
That seems to be the only restriction being lifted.
Nothing in there seems to say any of the other stuff has to be allowed for side loaded apps. As long as Apple doesn’t let App Store apps do it, they don’t appear to have to allow any new functionality outside that necessary to allow working app stores.
> The gatekeeper shall not require end users to use, or business users to use, to offer, or to interoperate with, an identification service, a web browser engine or a payment service, or technical services that support the provision of payment services, such as payment systems for in-app purchases, of that gatekeeper in the context of services provided by the business users using that gatekeeper’s core platform services.
Section 43 :
> Certain services provided together with, or in support of, relevant core platform services of the gatekeeper, such as identification services, web browser engines, payment services or technical services that support the provision of payment services, such as payment systems for in-app purchases, are crucial for business users to conduct their business and allow them to optimise services. In particular, each browser is built on a web browser engine, which is responsible for key browser functionality such as speed, reliability and web compatibility. When gatekeepers operate and impose web browser engines, they are in a position to determine the functionality and standards that will apply not only to their own web browsers, but also to competing web browsers and, in turn, to web software applications. Gatekeepers should therefore not use their position to require their dependent business users to use any of the services provided together with, or in support of, core platform services by the gatekeeper itself as part of the provision of services or products by those business users. In order to avoid a situation in which gatekeepers indirectly impose on business users their own services provided together with, or in support of, core platform services, gatekeepers should also be prohibited from requiring end users to use such services, when that requirement would be imposed in the context of the service provided to end users by the business user using the core platform service of the gatekeeper. That prohibition aims to protect the freedom of the business user to choose alternative services to the ones of the gatekeeper, but should not be construed as obliging the business user to offer such alternatives to its end users.
Disentangling JIT surely hasn't been an easy task, but they have had years to prepare and I don't think Apple will risk a recurring 20% annual global revenue fine.
This is the big one that I think people don’t fully appreciate!
Without using JIT (just-in-time compilation), your browser’s JavaScript will be terribly slow. But allowing JIT compilation (allowing an app to mark memory pages as executable, i.e. turn data into machine code) will also allow an app to introduce arbitrary new behavior after the app review and make it much easier for it to break out of the iOS sandbox.
Stuff like calling private iOS APIs or security sensitivity APIs using machine code downloaded from an external source that an app reviewer will have no way of foreseeing. This isn’t possible otherwise.
Even if the app/browser with JIT permissions isn’t malicious, it still opens up way more attack surface area. (Of course Safari already has the same risk)
That said, I of course really want more genuine browser options on iOS. But there are real security reasons for Apple’s reluctance, though I’m sure this can solved. But alternative browsers come with different security concerns that don’t apply to just allowing app side-loading (since even now side-loaded apps can’t implement JIT compilation)
And there's ways forward - iOS already has a "web-browser" entitlement. Apple could use it, or a similar one, to give approved applications access to JIT. I think it would be fine for just a select few developers (Firefox, Chrome) to get ability to JIT. https://developer.apple.com/documentation/bundleresources/en...
Which is the reason the JIT runs in its own sandbox connected through IPC IIRC.
Breaking the JIT isn’t supposed to even get you access to the parent process (Safari), let alone anything more, assuming you don’t have a kernel exploit too.
Agreed! I didn't mean for my comment to imply otherwise. (even Apple's refusal to allow other browsers, which would require JIT to be performant, illustrates Apple is aware the risk)
Current browser research suggests you don’t need JIT, as evidenced by the ability to disable it on iOS. Wonder how close you could get to “great” performance with a Firefox port without JIT.
If Google were allowed to publish Chrome, not based on Safari, but without a JIT tomorrow I think they’d get review bombed by normal users complaining about how it suddenly got slower than the current WebKit implementation.
It’s mostly developers who care about the engine, end users are going to care far more about the performance.
In my experience, disabling the JIT on iOS (via Lockdown mode) results in slow performance and greatly increased battery drain on JS heavy websites and web views. The battery drain being the worst part. But of course with a site like HN there’s no noticeable difference.
You also need a JIT entitlement for the application. Otherwise your browser engine will only be able to interpret JavaScript instead of JIT compiling it. Good luck getting any modern JavaScript framework running with only interpretation available.
Some JavaScript frameworks will work, others will randomly break with timeouts and other weird failures. While we'd hope we'd get less JavaScript abuse all that would happen is no one would use that browser.
So theoretically you should be able to grab an .ipa package with a native browser today and load it on your device in developer mode or through your enterprise program. The fact that not a single one actually exists seems more due to a technological limitation than the fact that no one has bothered to build it yet.
there is no roadblock to it besides no developers being interested in doing it, you can sideload anything you want (though you are limited to an absurd degree unless you pay apple $100/yr for a developer license), you can even do things like enable JIT for sideloaded apps so even that limitation doesn't exist for sideloading browsers. several emulators, like dolphin, already have working JITs on ios devices.
it's already competing, and quite successfully (hello battery life and ram usage). but when google.com displays a "better in chrome" message, or when they adopt some proposal instead of waiting on the process, then it's no longer about competition.
It doesn't work _anywhere_, as iPhone does not currently have sideloading. It's been reported that sideloading could come in iOS 17 later this year, in EU, but unannounced so far.
I'd argue that legislation like GDPR had more positive impact on user privacy than any walled garden managed by any for-profit entity. See Uber using the device ID even against App Store policy for years and not getting immediately kicked out after discovery [1]
Apple's clampdown on Facebook came after GDPR and apparently wasn't a problem for years until Apple decided it was beneficial to their marketing and a way to push their own ads better.
Rule of thumb is: when you are big enough, you can do basically anything you want when you don't talk about it.
