(Some obviously work better than others)
It's far from just the render engine that's being constrained. The whole virtual machine is restricted. The DOM, the js engine, the wasm engine, anything at all running or touching web code is locked the heck down.
There's a couple places browsers can add or supplant web platform features, but it largely prevents browsers from doing much at all to add to the web platform in any way.
In the rendering case, there's always work on css features & especially tuning that the browsers are up to. Just being faster, lighter weight, having more or better tuning is a great capability, a place where more than one small in-group should be able to experiment & improve & explore.
It is unclear whether this would still even be the case.
My understanding is that it's a _policy_ limitation preventing third party browsers on iOS. But there's also iOS security policies preventing JIT to have a fast browser.
I cannot imagine Apple opening up JIT-capabilities to all developers on the app store. I wouldn't be surprised if they didn't relax this at all. Perhaps they will they grant entitlements for JIT to a select few.
The security argument to not allow a JIT is that mapping code segments as executable+writeable opens up a lot of interesting attack vectors, and therefore allowing JIT weakens security. This is true of course, but the argument is a bit dubious for a few reasons. The first of which is that the OS is supposed to have sandboxing mechanisms that don't allow escape from the sandbox even if something goes wrong, and therefore prohibiting a JIT shouldn't be required in the first place. Furthermore WebKit itself has a JIT (whatever Apple calls their JS implementation), so iOS is already vulnerable to these kinds of issues in some sense. Finally, in general you can write and link in arbitrary code into your program (in read-only sections of memory), so attackers can already write exploits in C/C++/asm/whatever.
Obviously Apple needs special consideration for WebKit itself since the WebKit rendering engine is linked into a ton of applications, so a security issue in WebKit is a major problem because it affects many programs on the phone, including a lot of first party applications. But this wouldn't be the case with a third-party iOS browser, since even if Apple allows you to install a third party browser, they're not going to allow you to replace the system webview implementation with a third party one. Therefore a bug or security problem in Firefox/Chrome/whatever should be limited to just that app, and wouldn't have the same scope as a WebKit vulnerability.
Apple is notoriously restrictive so maybe they won't change their policies. On the other hand I think the current technical argument for not allowing third party programs to have JIT code is pretty weak, so I could definitely see a different decision being made at some point in time, especially if there was pressure from the legal team (e.g. due to things like EU anti-trust regulations).
Edit: in fact, you can’t even use the in-process UIWebView any more - App Store doesn’t accept submissions with them since 2020 https://developer.apple.com/news/?id=edwud51q
The replacement WKWebView enables JIT because it’s in a separate process, with the view painted back into your app.
I don't want to be slanted in only one direction, so let me share the other side of the coin: in the new Web Extensions spec that Google has built from the ground-up by fiat (mv3), they too ban dynamic code of any kind: all code must be built in to the extension. And the extension can't be any kind of virtual machine, can't execute any kind of programmatic system within itself. Because Google too is a murderous shitty coward that hates the world, that hates potential, that wants to limit freedom, that curbs what is possible, under exactly the same premises of being for our security, but which also obstructs massive classes of very basic very simple very generic software that poses a threat to these sizable corporations ability to stay in absolute control. Generally I'm pretty ok with Google's behavior, but this particular vicious turn of events deeply deeply against the web & possibility makes me lower them to the same low dog piece-of-shit fuckwad coward shitsmear con-man that I have long seen as a fairly distinclty Apple low lying cowardice. For your protection is a vicious piece of shit lie, and end of basic liberty. Shame, you vicious piece of shit fucks, shame!! You call it security, but you are just not willing to actually do the work to understand or look at & investigate: you make an easy fiat rule that excludes countless valid & good uses, because it makes your life easy & benefits your systems of control, lowers user-agency. It's directly agains the end-user, and yet they say it's for our benefit: this is the worst kind of lie.
- Push notifications
- Offline storage that doesn't disappear after 7 days.
In other words it could actually make "PWAs" viable for a lot of use cases.
If you personally don't want to use a feature, that's fine, but you're putting out a statement like that as if no one should be allowed to use that feature because some devs tend to use it for spam. It just takes like 2 or 3 clicks to remove rights of notification from a specific app, so it's not a big deal either way.
Basically anything that Apple tries to ban for anti-competitive reasons. Once this blocker is removed, no one will care about Apple bans anymore.
Opus support:
Firefox: 2012
Chrome: 2014
Safari: Unsupported
Firefox: Oct 2021
Chrome: Aug 2022
Safari: Oct 2022 (but incomplete and buggy)
Firefox: 2019
Chrome: 2018
Safari: Unsupported
Firefox: 2019
Chrome: 2014
Safari: 2022
Firefox: 2014
Chrome: 2013
Safari: 2022
Firefox: 2009
Chrome: 2010
Safari: Unsupported
Firefox: 2017
Chrome: 2017
Safari: 2019
I agree it's annoying on occasion.
This is provably false though. For example, they support Opus bitstreams either through WebRTC (because it's required) or inside their own buggy special-snowflake .caf container (so they do support the more "expensive" encoding/decoding part of Opus that could benefit from hardware acceleration), but they don't support Opus audio files (that is, the '.opus' Vorbis container which everyone uses to hold Opus audio, which is the "easy" part of supporting Opus and doesn't benefit from having hardware acceleration because there's nothing to accelerate there).
And they control their own hardware for how many years now? Their A4 silicon first appeared in 2010; they could have easily added whatever hardware acceleration they want to, but they chose not to.
Frankly I'm not sure what their motivations are. I guess they just don't care?
WebGPU is key. Apple has been dragging their feet here while their AR / ML teams catch up to the rest of the industry.
8thwall (https://www.8thwall.com/projects) has some pretty good demos of completely cross-platform AR/VR stuff. All this gets a ton better if iOS somehow supports WebGPU.
And then there is user fingerprinting and ads stuff. A ton of fingerprints today are from CSS quirks and the like. Renderers can favor or disfavor these things.
But on the other hand, if you care about your privacy, why would you trust a third party to intercept all of your web traffic?
uBlock Origin is free and open source, and its code is thoroughly reviewed by many contributors every release. I trust uBlock Origin over a filtering mechanism built into a closed source browser such as Safari.
But did you personally download the open source version review the code and install it?
Yes, I have personally downloaded the uBlock Origin source code. I have also reviewed the code and suggested improvements. However, I don't even need to download the code to realize the benefits of uBlock Origin being free and open source. Even if I hadn't downloaded the code, there are many other users and contributors who have reviewed the code, and you can confirm this by taking a simple look at the activity in the GitHub repos.
What are you talking about? You are the one who accused other developers of that. Let me quote you again:
> But on the other hand, if you care about your privacy, why would you trust a third party to intercept all of your web traffic?
https://news.ycombinator.com/item?id=34699213
My point is that because uBlock Origin is free and open source, anyone can see that it is not tracking users maliciously. On the other hand, Safari is closed source, so your FUD would be more applicable to Safari. There is no easy way for users to verify how a closed source browser such as Safari implements its content blocking. In terms of transparency, uBlock Origin is strictly superior to Safari.
Until you use an app with a web view…
But tell me what can’t I block in your experience with 1Blocker on Safari?
If we are comparing ad blocking extensions. We know that there is no possible method for a third party ad blocker on iOS to intercept your traffic.
You’re comparing an ad blocker to a browser.
The fact is that your ad blocking extension won’t work at all within embedded web views.
We know for a fact that a third party ad blocking extension can not intercept your web browsing history on iOS whether it is open source or closed sourced. It has no access to your web browsing history.
Your assurance comes from open source, mine comes from knowing that my third party as blocker doesn’t have any access to my web browsing.
You have been spreading FUD about fully-featured content blocking extensions like uBlock Origin, which is not a very good argument because Safari itself is closed source and its behavior is opaque. A combination of Firefox + uBlock Origin is fully free and open source, and its behavior is fully and easily verifiable. It is absurd for you to criticize combinations such as Firefox + uBlock Origin when the combination of Safari + a Safari-compatible content blocking extension is clearly less transparent due to Safari being closed source.
Apple's anti-competitive App Store restrictions are preventing the superior combination of Firefox + uBlock Origin from existing on iOS. Fortunately, regulations will soon make some of Apple's anti-competitive restrictions illegal in some major markets.
uBlock Origin not being able to protect web views on iOS is yet another restriction imposed by Apple. If browsers on iOS were able to supply web views to other apps and activate extensions in those apps, as the Custom Tabs feature works on Android, uBlock Origin would have no issues blocking content in iOS web views. Don't blame uBlock Origin for a restriction that Apple created.
What you meant to say: Chrome implements its own non-standards against strenuous objections if both Firefox and Safari.
I guess in your world "every other browser" is Chrome. And, sure enough, there are some parts of the API that are only implemented by Chromium-only browsers, and are not implemented by either Safari or Firefox.
So, what other untruths you're going to tell us?
Viewport units have been around for a decade now, and Safari still can't get them right.
For example:
Let's say we want to make a chat window, where a user can type in an input field at the bottom and little message bubbles appear above. Sounds like a job for flexbox and viewport units.
Okay, we'll have one flexbox div container with it's children being the chat messages and the input which get aligned to the bottom. Now we'll position the container so it takes up the full page using viewport units (e.g. take up 100% of the viewport's width, and take up 100% of the viewport's height).
Oh no! When the user scrolled through the messages, the browser's tab bar appeared and instead of calculating that 100% of the viewport is 100% of the viewport, the viewport isn't being updated, and now the input field has been scrolled out of the page.
That's okay, we'll just use the new dynamic viewport units which specifically account for the problem that Safari had invented, and which only took 8 years to come out.
Okay looks good, time to send a message.
Oh no! When tapping on the field input, now the keyboard covers up field so we can't see what we're typing.
>_<
Good work Safari... Real good work...
When I say I want something to take up 100% of the viewport, I mean 100% of the viewport.
- Web USB
- Web NFC
- Web Notifications
- Web Midi
- Offline Storage
- Gryo, Accelerometer, Magneto, Proximity
- Vibration feedback
If all you want is an app for your users to use, you won't pay a dime outside of the developer fee. If you want people to discover your app in the app store, download it, and then pay you then it's a 30% cut.
Anyway nowadays apps are even built with web technologies (such as React Native), would just be simpler to have only the web version, a single codebase that can be used with an iOS device, an Android device, a PC, a smartwatch, a TV, whatever. Distributing an app is a pain, especially for iOS, you have to submit it for review, Apple has to approve it, you cannot do certain things, why? I get that on Android is simpler, just install the APK and done, but unfortunately there are a ton of iOS devices out there.
Oh. And Web Midi? The moment Firefox implemented it they discovered its used for fingerprinting, and Chrome allows it by default: https://twitter.com/denschub/status/1582730985778556931