As far as I know, JIT is disabled on iOS at the moment, so one thing developers would notice right away is abysmal JavaScript performance. (Early versions of V8 didn't even have an interpreting or bytecode path, to my knowledge, so it wouldn't even run without major modifications!)
Even if Firefox and Chrome used Gecko and Blink with JSC, that's still a marked improvement from the state of things today. Most of what I dislike about Safari are its weird rendering issues, which would be solved.
Given how vast the modern web specifications are, you could really be 99% compliant but provide a pretty mediocre experience to your users, or vice versa.
For example, I use Firefox as my main browser, and the lack of e.g. proper WebAuthN support on macOS has a much, much higher impact to me (and is making me consider switching), whereas I couldn't care less about e.g. WebUSB (which I do occasionally use, but I'm fine switching to Chrome for that use case).
To get an accurate picture, you'd have to somehow weigh all of these various standards and features in a way that not only accurately presents actual users, but also their relative importance (i.e. do websites trying to use something fail gracefully, or do I effectively have to use another browser to get achieve what I'm there for).
Ideally or potentially Firefoxes or potentially say Servos or any other browser of choice. As opposed to the very-low not-so-common denominator of this anti-invested in naughty stepchild of the Apple 30% rent-stealing profit-garden that is modern Apple.
Can you show a source, then? I‘m also pretty sure JIT (i.e. write+execute) permissions are enforced at the process level.
Some apps work around this by running JavaScript in an invisible WebKit view, but that approach has IPC overhead, so is probably only worth it for processes that interact with the UI and rest of the app infrequently (which is the opposite of what you‘d want from a JS engine interacting with the DOM).
a-Shell uses it for performant WASM execution of CLI executables, for example.
I've seen some reports of it also becoming available for iOS, but it seems to come and go between minor version upgrades and I'm not sure what the current status is.
Not an iOS developer; what does available mean in this case? Are you talking actual OS support, or simply that Apple has never approved any app attempting to do it? Because Safari obviously does it so my thinking is the OS must support it, but I guess Apple has a policy not to approve it.
Apps that want to JIT need an “entitlement” from Apple (in other words they have a signature from Apple that the operating system validates before letting the APIs work). So the OS supports it, Apple grants that entitlement to Safari so it can use it, but no third party app can get this entitlement.
But surely once "sideloading" (I hate that term, we used to just call it "installing"...) is enabled, apps not installed through the App Store will be able to utilise this entitlement?
Hope so. There should be some developer capability somewhere. And we should build for the reasonable good future, & show whats possible. Not what we can mete from the iron mailed fist of Cupertino in the real world if this or that, but what actual good is.
It'd be a mean spirited system to simply mark everything no-execute, always forever in any env. But that'd be distinct Apple flavored. Think Different, R.I.P..
Yes. On iOS you can only use the JIT through an out-of-process web browser (WKWebView or SFSafariViewController) so it’s likely Firefox and Chrome would use non-JIT in-process engine (even if that were JSC!) unless the JIT restriction is lifted.
>so one thing developers would notice right away is abysmal JavaScript performance
That's actually a good thing! If a substantial chunk of iOS users would use third-party browsers without JS JIT, then webdevs would be forced to better optimize their sites, because the perf ceiling would be lower on these browsers. This then would lead to stellar performance for those who stick with Safari which does have JIT! Kind of how using an M1 is so good today, because there's still a large number of Intel machines out there, so devs can't yet afford releasing software that's only usable on M1 from a cpu/energy point of view.
In 2021, Microsoft added the "no JIT" option to Edge for additional security [0], and here's the quote in their blog post:
>We see that most tests see no changes with JIT disabled. There are a few improvements and regressions, but most tests remain unchanged. Anecdotally, we find that users with JIT disabled rarely notice a difference in their daily browsing
Because Google would be pushing it hard? E.g. when you click a link in the YouTube app, it doesn't open it in Safari, rather it shows you a "helpful" dark-pattern prompt about opening it with:
- Chrome (mind you, I don't have it installed, so this would send me to the AppStore)
- the "Google" app (again, not installed)
- Safari (which does not open Safari, rather an in-app WKWebView, so that Sundar can still milk your precious eyeballs)
- and finally at the bottom the "Default browser app" (this is what you want)
Of course, there's no setting to save this choice once and for all, so this is done each and every time you try opening a link in the YouTube app. Wait, actually, I'm 99% sure it would suddenly remember your choice if you had installed one of their browsers. From that moment they would duly open all links in Chrome/Google, without this annoying prompt.
I bet every Google app does this on iOS to get you install their crap. Disgusting practice.
Google is incredibly aggressive in promoting Chrome yes, but every time I've seen "Safari" as an option in a Google app it isn't WKWebView, but SFSafariViewController which is for all intents and purposes real Safari — it's essentially an out-of-process Safari tab with its own separate cookies, storage, etc. Apps using it can't snoop on your browsing session and they can't dig around in your cookies, etc from standalone Safari.
It’d be useful to see the difference clearly as a user. Personally I try really hard not to use any in-app browser because I have no clue how trustworthy the developer is (except for Facebook and Google, for which the answer is “absolutely not”).
> Because Google would be pushing it hard? E.g. when you click a link in the YouTube app, it doesn't open it in Safari, rather it shows you a "helpful" dark-pattern prompt about opening it with: Chrome
Ironically the reason this dark pattern exists is because Apple refused to implement support for user-controlled URI handlers in the first place.
