4 ms·

That's not a fact. All browsers on iOS use the same rendering engine. The differences between them are all in the UI and other front-end features. That doesn't

That's not a fact. All browsers on iOS use the same rendering engine. The differences between them are all in the UI and other front-end features. That doesn't make Safari superior to them, especially since they're all starting off with the same base rendering. Anything outside of that can easily be better than Safari.

gameoverhumans 3y ago
Rather than just downvote you for stating incorrect things with such conviction, I'll refer you to Apple's own website :) https://support.apple.com/en-eg/guide/security/sec15bfe098e/web https://support.apple.com/en-eg/guide/security/sec15bfe098e/... > Memory pages marked as both writable and executable can be used only by apps under tightly controlled conditions: The kernel checks for the presence of the Apple-only dynamic code-signing entitlement. Even then, only a single mmap call can be made to request an executable and writable page, which is given a randomized address. Safari uses this functionality for its JavaScript Just-in-Time (JIT) compiler. In other words, Apple only allows Apple to do Javascript JIT on iOS.
- btown 3y ago
  While this is technically true, WKWebView (which I believe is used by all non-Apple browsers on iOS) does allow Javascript JIT, because the renderer runs in a subprocess with these permissions. See: https://news.ycombinator.com/item?id=19379739 https://news.ycombinator.com/item?id=19379739 . But there are many other reasons besides JIT to want to have non-Apple-Webkit-based rendering engines (including wanting different JS engines with their own JIT) - and so IMO it's very much a restriction that regulators should force Apple to relax. The security considerations should be no different than those on a desktop platform.
  - gameoverhumans 3y ago
    Interesting, thanks. Didn't realise there was ways to embed WebKit views that also got JIT (escaped the walled garden a while ago!) Still, my original point still stands. As you note, you can't have Spidermonkey running on iOS doing JIT. But you also couldn't have Gecko doing rendering and using WebKit JIT, either. ... Right? > The security considerations should be no different than those on a desktop platform. Completely agree. The "it's for your own security" angle is just usual Apple FUD to make their anti-competitive stance seem pro-consumer.
    - saagarjha 3y ago
      Your control over the web process is very limited, correct.
cal85 3y ago
Third party browsers are forced to use a slower JavaScript engine than Safari. They also can't support extensions or PWA features.
- callalex 3y ago
  The JIT thing hasn’t been true for several years thanks to WKWebView.
deleted 3y ago
[deleted]

gameoverhumans 3y ago

Rather than just downvote you for stating incorrect things with such conviction, I'll refer you to Apple's own website :) https://support.apple.com/en-eg/guide/security/sec15bfe098e/web https://support.apple.com/en-eg/guide/security/sec15bfe098e/... > Memory pages marked as both writable and executable can be used only by apps under tightly controlled conditions: The kernel checks for the presence of the Apple-only dynamic code-signing entitlement. Even then, only a single mmap call can be made to request an executable and writable page, which is given a randomized address. Safari uses this functionality for its JavaScript Just-in-Time (JIT) compiler. In other words, Apple only allows Apple to do Javascript JIT on iOS.

btown 3y ago
While this is technically true, WKWebView (which I believe is used by all non-Apple browsers on iOS) does allow Javascript JIT, because the renderer runs in a subprocess with these permissions. See: https://news.ycombinator.com/item?id=19379739 https://news.ycombinator.com/item?id=19379739 . But there are many other reasons besides JIT to want to have non-Apple-Webkit-based rendering engines (including wanting different JS engines with their own JIT) - and so IMO it's very much a restriction that regulators should force Apple to relax. The security considerations should be no different than those on a desktop platform.
- gameoverhumans 3y ago
  Interesting, thanks. Didn't realise there was ways to embed WebKit views that also got JIT (escaped the walled garden a while ago!) Still, my original point still stands. As you note, you can't have Spidermonkey running on iOS doing JIT. But you also couldn't have Gecko doing rendering and using WebKit JIT, either. ... Right? > The security considerations should be no different than those on a desktop platform. Completely agree. The "it's for your own security" angle is just usual Apple FUD to make their anti-competitive stance seem pro-consumer.
  - saagarjha 3y ago
    Your control over the web process is very limited, correct.

cal85 3y ago

Third party browsers are forced to use a slower JavaScript engine than Safari. They also can't support extensions or PWA features.

callalex 3y ago
The JIT thing hasn’t been true for several years thanks to WKWebView.

deleted 3y ago

[deleted]