> I wish Mozilla would join them by publishing a Firefox for iOS with their own renderer and Javascript
It would likely be unusably slow if they did. Apple doesn’t allow apps in the store with the required entitlements to make an optimized JavaScript engine of entirely Mozilla’s design.
> and the fact that they refuse to allow other browser engines on iOS is the reason why we can't have nice things like progressive web apps.
Is that against the App Store guidelines? Or is that a programming limitation? I am aware all the iOS browsers are just a wrapper around WKWebView but am curious why another engine can't be implemented.
> That, and, Safari is miles ahead of any other engine in terms of performance. It’s not even close.
How is it fair to make this statement about iOS where no other engine is even allowed? Maybe Chrome(ium) and/or Firefox would be faster than Webkit on iOS if they were actually allowed to develop for it, or maybe Safari would be the best. It's impossible to know because Apple prevents any competition here.
> My understanding is that WebKit is the only rendering engine permitted on iOS as a security precaution, ostensibly taking Apple at face value and in good faith.
Look at mac. Do we have a problem with firefox on mac? Both mac and iOS share the same OS kernel. Using security as an excuse is laughable.
I once read on twitter from a mozilla dev saying they were even willing to build a browser engine without JIT just to satisfy the security requirement. But eventually they went with webkit to build Firefox for iOS.
>This makes zero sense. You can install 3rd party apps that can do whatever they want (within the limitations of the platform) power-wise. But for some reason Apple needs to limit the special case of apps that are browsers?
This objection makes zero sense. You cannot install any 3rd party app, just those that got approved. And a power hog or whatever app can always be de-approved.
> The reason Apple has always given is security. This is the reason they gave for not allowing third party access to the JIT version of the javascript engine.
This doesn't make sense. You could disable the JIT, compile WebKit to native code, and ship it on iOS without the app requiring any more technical permissions. Apple just doesn't want you to do that for business reasons.
If you want to maintain that it's a security measure, there should be a specific attack concept you can describe that preventing alternative browser engines (suitably modified to work with W^X) stops.
> It's bullshit that you can only run Safari on iOS or that the App Store is the only store you can use.
What I really want is an up-to-date browser even if iOS stops being supported on an old phone of mine. (And they seem to be dropping support faster, what with iOS 17 not supporting the iPhone X — introduced in 2017 — without any legitimate hardware reason.)
It's ridiculous that Safari and the underlying WebKit engine only get updated with every accompanying iOS release.
> The biggest technical hurdle is the inability to run external processes on iOS and iPadOS.
> Apps on iOS and iPadOS must use Apple’s Javascript interpreter, JavaScriptCore.
Both of these really suck because they are policy, not technical, decisions. Even setting aside the arguments of whether JIT code is a security concern (it is not unless your security model is one where codesigning exists to prevent the addition of new native code) that you cannot spawn a new process, nor can you ship another JavaScript interpreter, is really unfortunate.
Allowing apps to spawn new processes is easy (I mean, just inherit sandboxing rules and resource limits…) and allows for a lot of new usecases, like robust crash reporting, web servers, privilege separation, and more. That Apple allows this on macOS and even uses it for its own apps on iOS just shows how useful this can be and how little it affects the security model of iOS.
Likewise, not allowing other JavaScript interpreters is just…annoying. Regardless of your opinions of JavaScriptCore, this is an unfair limitation on an already slanted playing field. Coupled with the fact that the JavaScriptCore interpreter (which the framework uses for anything you run in-process) is literally designed for low resource consumption instead of than performance makes this even more infuriating.
> Likewise, not allowing other JavaScript interpreters is just…annoying. Regardless of your opinions of JavaScriptCore, this is an unfair limitation on an already slanted playing field.
Reading the actual policies reveals that other interpreters are in fact allowed, but they may only be used for code that is part of the app bundle.
The actual limitation is that apps must be self-contained, and only javascriptcore and webkit may be used to run code from an external source (e.g. downloaded or user input).
> IDK how it is now, but Apple used not to allow e.g. alternative Javascript engines in apps—you had to use Webkit's.
App Store guidelines say you have to use WebKit JavaScript for web browsing. I believe you are allowed to use third-party JavaScript for non-web-related purposes. That’s a rather small use case though.
Also, we have to distinguish between App Store policy and technical constraints. If you are just running your own software (e.g. developer, adhoc distribution, enterprise distribution), you don’t need to care about the former only the later-lack of entitlements to JIT is still an issue for the later.
> What MSFT did would be equivalent to Apple forcing everyone to use its apps and not allow any competing apps.
How many HTML/CSS/DOM/JavaScript rendering engines have been available on iOS compared to Android?! Has Gecko or Presto ever been available on iOS? What is the ONLY platform in wide use today that does not support Gecko or Blink?
Apple's iOS is by far worse than the Microsoft with Windows.
Is FirefoxOS more or less 'open' than iOS? You can't write a competitive javascript runtime for FirefoxOS either.
reply