9 ms·

The article once more reiterates the fact that Apple doesn't allow other browser engines. You cannot even fight, there is no future ;-) on iOS.

radarsat1 7y ago
How is it technically enforced though, I am curious. I mean, if I wrote an application that downloaded text files and rendered the text to the screen, I am sure that would be possible. If I wanted to add images to draw next to the text I am sure it is feasible. So how can one technically prohibit doing that? Implementation-wise, how is a web browser really that different from e.g. a video game? Or is it only policy-enforced? Reviewers see something in an app that resembles a "browser" too much and take you down?
- sharpneli 7y ago
  One cannot have writeable executable memory on iOS (apple can, we cannot). Thus one cannot make a JIT compiler for js and thus pages are slow. Game engines such as Unity use il2cpp to go from the C# stuff into C++ that can be statically compiled as running the C# as bytecode would be too slow without a jitter.
  - radarsat1 7y ago
    Ah, so it is all about the javascript engine? Ok I can see how that might put up some major technical barriers, but still it should be technically feasible to have the firefox rendering engine make use of the iOS javascript engine, no? Maybe it's not worth the effort of course. I am just trying to get a feel for what the barriers are.
    - sharpneli 7y ago
      Not via public apis. So cannot be placed into app store.
    - vbezhenar 7y ago
      I think that iOS JS engine is tied to WebView and it would be hard to re-use it with other rendering engine.
      - saagarjha 7y ago
        JavaScriptCore can be used can be used independently from the rest of WebKit, but I’d expect it to be slow.
    - KonkeyDong69 7y ago
      In addition to what the other replies said, feel free to eyeball the code required to embed SpiderMonkey in Firefox at https://github.com/mozilla/gecko-dev/tree/master/dom/bindings https://github.com/mozilla/gecko-dev/tree/master/dom/binding.... It's rather large and complex.
      - padenot 7y ago
        This is not at all the code to embed SpiderMonkey in Firefox, those are the bindings from DOM APIs to the implementation of those APIs in Firefox. Above that, calling into this layer, is another layer that transforms JS calls into C++ calls (roughly). The interface between SpiderMonkey and the rest of Firefox is here: https://searchfox.org/mozilla-central/source/js/src/jsapi.h https://searchfox.org/mozilla-central/source/js/src/jsapi.h.
  - zzzcpan 7y ago
    > One cannot have writeable executable memory on iOS (apple can, we cannot). > Thus one cannot make a JIT compiler for js and thus pages are slow. Lack of JIT doesn't slow down pages much. I believe the difference is so small that it might even be possible to be faster without JIT for most pages, especially on low power devices, it's only computation heavy pages that are going to suffer and even then it's not like you can't optimize common patterns statically ahead of time. It doesn't mean that it's a good idea to invest into it, you are still under Apple's mercy and they clearly don't want competing browser engines.
    - sharpneli 7y ago
      If I have understood correctly (I’m a C++ graphics programmer. So don’t know too much about what’s flashy in the web world) V8 only jits. As in it can only produce machine code and there is not even an option to run it as an interpreter.
      - saagarjha 7y ago
        V8 has a high performance, JIT-less interpreter that disables TurboFan and relies exclusively on Ignition: https://v8.dev/blog/jitless https://v8.dev/blog/jitless
    - chrisseaton 7y ago
      > Lack of JIT doesn't slow down pages much. So why do you think so many major companies invest such a huge amount of money in JS JITs? Google, Apple, Microsoft, Oracle, Mozilla all maintain JS JITs and spend what I guess is hundreds of millions of dollars a year on it.
      - notacoward 7y ago
        A budget of $100M, with 50% devoted to salary and a median salary of $250K, would be 200 developers. I seriously doubt any of the companies you name are devoting even a quarter of that to JS JIT development. Yes, they each make significant investments, but let's not weaken the argument by indulging a penchant for hyperbole.
  - saagarjha 7y ago
    > One cannot have writeable executable memory on iOS (apple can, we cannot). Nitpick: you can but you cannot ship it via the App Store.
    - shkkmo 7y ago
      Apple as does not allow side-loading, so wouldn't a jailbreak be required?
      - least 7y ago
        Jailbreak, enterprise certificate, testflight, or a developer account would be required to sideload an app. You can technically sideload an app without a paid developer account, but the certificate only lasts seven days, at which point you'd have to reload the application.
- capableweb 7y ago
  My guess would be that it's policy-enforced and what Apple really has problems with is not browsers as a concept (dynamically loading and rendering data) but rather the execution engine that websites usually use (JavaScript) and seeing that as a too-large-to-review area where they want to avoid having vulnerabilities in applications published on App Store. Or it's a anti-competitive move disguised as a "avoid vulnerabilities" but in reality they just really want to make sure iOS users keep using the one and only browser (Safari).
  - JustSomeNobody 7y ago
    interesting. But I can’t help but think by that logic Facebook should be too large to review.
    - deleted 7y ago
      [deleted]
    - extropy 7y ago
      Facebook does have code that dynamically compiles arbitrary input to machine code. That's the part Apple is not allowing in third party apps.
      - saagarjha 7y ago
        > Facebook does have code that dynamically compiles arbitrary input to machine code. Not outside of JavaScriptCore they don’t.
  - marcthe12 7y ago
    Apple uses no Turing complete policy. So you also can't bundle a python or ruby interpreter in iOS. Its still anti-competitive but in a different area which is language and api. They are basically trying to push devs to use their native OS apis. PWA are also screwed up in Safari for a reason.
    - saagarjha 7y ago
- reubenmorais 7y ago
  I don't know the details first hand, so take this with a grain of salt, but this is what I remember from talking to engineers who explored this possibility over the years: You can't ship a native JIT (execute native code from the heap), I think it's enforced automatically by the App Store. So shipping your own JavaScript engine is out. You can't download and interpret third-party code, I think this is enforced by human reviews, so shipping your own Web rendering stack is out. You can use your own network stack with WebKit on top, which would let you offer some value to users like more advanced ad/tracker blocking.
  - robin_reala 7y ago
    This is exactly what Chrome on iOS did: they embedded their own networking stack, but reused WebKit and JSC.
  - thekingofh 7y ago
    Thanks for the information. That part about disallowing third-party code interpreting is particularly painful to hear. They shut down any possibility of another browser. Could see that they do this for security reasons because a badly implemented interpreter could open up holes, but I'd imagine the sandbox is sufficient to allow at least interpreters.
- deleted 7y ago
  [deleted]
- saagarjha 7y ago
  Web content must be rendered through WebKit as per the App Store Review Guidelines (https://developer.apple.com/app-store/review/guidelines/ https://developer.apple.com/app-store/review/guidelines/). This is supposed to be enforced by App Store Review by inspection. In addition to this, there are technical reasons why your “browser” will be inferior to Apple’s web view performance-wise, mainly having to do with apps that generate code dynamically in-process needing entitlements that prevent submission to the review process.
- Yoric 7y ago
  Policy-enforced. Mozilla ported the true Firefox to iOS many, many years ago and Apple just rejected it from the store.
decasteve 7y ago
Anti-trust? Or have the lawyers for Apple (and Google) found the legalese to prevent this possibility?
- Macha 7y ago
  Apple is only a monopoly if the market is iOS devices so they're quick to point out the market is all mobile devices. Google allows sideloading, and allows competitors on the play store
  - anoncake 7y ago
    > they're quick to point out the market is all mobile devices. It is not. The market is stores for Ios devices, Apple does have monopoly.
iforgotpassword 7y ago
Yes, however, even as a Firefox advocate, I think in this case it's actually a good thing, since the majority of people would probably switch to Chrome then, contributing to the Blink monoculture.
- jraph 7y ago
  It's not a good thing, only a bad thing with a good side effect ;-)
nfriedly 7y ago
If Apple allowed Firefox on iOS - real Firefox with the rendering engine and extensions and everything, just like Android - I probably would have switched already. As it stands, I stay on Android mostly for Firefox.
- notduncansmith 7y ago
  Just curious, why does using “real Firefox” hold so much weight for you? Also, what steps have you taken to secure your device? One reason I haven’t switched from iPhone is that I’m not confident in my ability to secure an Android, and I’d rather trust Apple than Google.
  - Transfinity 7y ago
    One big thing is that you can't change the default browser, so any time you click a link you end up on safari. In my experience (I tried iPhone for 2 weeks after my previous phone died, before returning it and switching back to Android) that makes installing a different browser effectively useless. The rendering engine restriction is less obvious to the average user. And, frankly, if you don't trust Apple with your data then what are you doing using their network stack?
  - nfriedly 7y ago
    A big part of it is extensions, I have a handful of extensions that I use on a regular basis, and Firefox is the only mobile browser that actually supports extensions. Another part of it is that I just trust Mozilla more. Both in terms of conflicts of interest, and just plain fixing bugs. For example, Safari on iPod touch has been unable to access the microphone for years, even though Safari on iPhones can. I will concede your point about security. I think that iPhones are probably more secure than Androids. But, I feel that the security of my Android phone is sufficient for my needs.
    - Zak 7y ago
      Extensions don't get enough attention in this discussion. They're the main reason I prefer Firefox on Android. Anything that's missing or not to my liking, I can usually find an extension to provide or change. If something annoyed me enough and there wasn't an existing extension, I could look up the API docs and write one myself.
krzyk 7y ago
I wonder why no antimonopolist issue was raised there by e.g. EU. Like they did for NFC in Germany - they forced all phones with NFC to be open to use by different apps, which might finally bring other pay solutions to iOS (or non NFC capable iphones to Germany).
- Despegar 7y ago
  The NFC issue isn't related to antitrust. If they thought they could make an antitrust case against Apple they would. But their market share is so low in Germany, and the EU, that they just passed a law instead (specifically an amendment to an anti-money laundering law). It remains to be seen if it's even constitutional.
sebazzz 7y ago
Technically I think you are free to build have other browser engines on iOS. However, JIT or other dynamically compiled code is not allowed because that's a security risk. You can't have a browser in 2019 with interpreted javascript.
- fauigerzigerk 7y ago
  But why is JavaScript JIT compilation tied to the rendering engine?
  - andrewl-hn 7y ago
    Yep. technically, Apple doesn't force Firefox to use WebKit. They could still use their Gecko WebRenderer and use Apple's JavaScriptCore to run page scripts. Same goes to Chrome: Blink + JSC instead of Blink + V8. In practice in seems like both Chrome and Firefox have their renderers and JavaScript runtimes so tightly integrated that it's very hard to replace the later.
    - fauigerzigerk 7y ago
      Elsewhere in this debate sharpneli says that there is no public API to call into JavaScriptCore and using non-public APIs violates the App Store rules. So that would explain it.
      - saagarjha 7y ago
        There is API to use JavaScriptCore in your apps: https://developer.apple.com/documentation/javascriptcore https://developer.apple.com/documentation/javascriptcore. No JIT, though, so it’s slow.
- thekingofh 7y ago
  I think you mean that you can have interpreted javascript, just not JIT compilers. They don't allow you to mark memory as executable. That syscall is completely disabled on their systems.
jrs95 7y ago
It would be a lot more difficult than it sounds for Apple to allow 3rd party browsers and allow them to be good. Even on macOS now, Chrome depends on internal OS APIs which prevent it (or Electron apps) from being in the Mac App Store -- and for good reason, those things could break at any time. So in order to allow 3rd party browser engines that can compete with Safari in terms of performance etc they would need to make the APIs that are used to optimize them public.
- EvanAnderson 7y ago
  If these non-public APIs are so useful it feels to me that Apple is acting in an anti-competitive manner. They're allowed to use them for their own applications but deny third-parties the right to sell in the "Store" if they use the APIs. Sounds a lot like MSFT in the 90's...
- deleted 7y ago
  [deleted]
ken 7y ago
That's a convenient excuse on iOS, but Firefox is doing poorly on macOS, too, where no such restriction exists. According to the first statistics I found, Firefox is only about half as popular on the Mac as it in on Windows -- and it's still under 10% there, too. Privacy-compromising systems aren't winning today because people seek out systems that compromise their privacy. They're winning because these companies focused on making the user interface good. Firefox will win big again when they stop talking about privacy and start making a UI that isn't lousy. True, Apple is talking about privacy a lot these days, but they've been focusing on UX first for decades. You can't start with "here is an abstract principle that's good for you, and you should use our systems because of it". The Free Software Foundation tried that for years. It doesn't work. Privacy is important, but it's a feature, not a product. You still need to have a great product.
- ragequitta 7y ago
  I'm trying to think of a UI difference in chrome or safari that is meaningful, can't come up with one. Can you elaborate?
  - ImprovedSilence 7y ago
    i have way too many tabs open at all times, and chrome makes it way way easier to see what I have open and get to the tab I want quickly.(it just shows more tabs than Firefox, this is my main complaint) The top bar uses less vertical real estate and is just much cleaner overall. I can see more if not all of the url. Chromes next tab left, next tab right, and close tab, automatically map to the keyboard shortcut I set in macOS, and I still haven’t even found the menu option for next and previous tab in Firefox. (I’m sure it’s there and I just haven’t found it yet, but if it’s not there, that’s a deal breaker for me) I very badly want to use Firefox as my main browser, and I have it installed and give it a go every now and then, but it’s just not all the way there yet for me.
    - kilburn 7y ago
      The vertical space you can easily fix by opening the hamburguer menu > customize > density (bottom left) > compact. It then uses less space than chrome. You can also add/remove items from the top bar there, making your address bar larger if you want to. The default hotkeys for next/prev tab are cmd+option+left/right arrow. I don't know how to change those...
Chirael 7y ago
It’s nowhere as good or fine-grained as uBlock origin, but I’m surprised no one ever seems to mention (or use?) Firefox Focus and it’s associated Safari content blocker. Seems to work really well for me on my iPad and iPhone, at least for general ad blocking.
alwillis 7y ago
As Apple has reiterated, browser engines require low-level access and for security reasons, other rendering engines aren’t allowed. You can see from Apple’s updates that keeping up with the vulnerabilities for WebKit and iOS, etc. is already keeping them plenty busy: https://support.apple.com/kb/HT210725 https://support.apple.com/kb/HT210725 https://support.apple.com/kb/HT210721 https://support.apple.com/kb/HT210721 https://support.apple.com/kb/HT210624 https://support.apple.com/kb/HT210624 https://support.apple.com/kb/HT210603 https://support.apple.com/kb/HT210603
- alwillis 7y ago
  My point is this gets dramatically worse if every browser engine has low-level access to iOS.
mr__y 7y ago
You could run the browser on other machine and use VNC to access this from a iphone (or any other mobile device). While this is rather complicated and probably less reliable solution, the bonus points would be (almost) perfect isolation of the browser process.

radarsat1 7y ago

How is it technically enforced though, I am curious. I mean, if I wrote an application that downloaded text files and rendered the text to the screen, I am sure that would be possible. If I wanted to add images to draw next to the text I am sure it is feasible. So how can one technically prohibit doing that? Implementation-wise, how is a web browser really that different from e.g. a video game? Or is it only policy-enforced? Reviewers see something in an app that resembles a "browser" too much and take you down?

sharpneli 7y ago
One cannot have writeable executable memory on iOS (apple can, we cannot). Thus one cannot make a JIT compiler for js and thus pages are slow. Game engines such as Unity use il2cpp to go from the C# stuff into C++ that can be statically compiled as running the C# as bytecode would be too slow without a jitter.
- radarsat1 7y ago
  Ah, so it is all about the javascript engine? Ok I can see how that might put up some major technical barriers, but still it should be technically feasible to have the firefox rendering engine make use of the iOS javascript engine, no? Maybe it's not worth the effort of course. I am just trying to get a feel for what the barriers are.
  - sharpneli 7y ago
    Not via public apis. So cannot be placed into app store.
  - vbezhenar 7y ago
    I think that iOS JS engine is tied to WebView and it would be hard to re-use it with other rendering engine.
    - saagarjha 7y ago
      JavaScriptCore can be used can be used independently from the rest of WebKit, but I’d expect it to be slow.
  - KonkeyDong69 7y ago
    In addition to what the other replies said, feel free to eyeball the code required to embed SpiderMonkey in Firefox at https://github.com/mozilla/gecko-dev/tree/master/dom/bindings https://github.com/mozilla/gecko-dev/tree/master/dom/binding.... It's rather large and complex.
    - padenot 7y ago
      This is not at all the code to embed SpiderMonkey in Firefox, those are the bindings from DOM APIs to the implementation of those APIs in Firefox. Above that, calling into this layer, is another layer that transforms JS calls into C++ calls (roughly). The interface between SpiderMonkey and the rest of Firefox is here: https://searchfox.org/mozilla-central/source/js/src/jsapi.h https://searchfox.org/mozilla-central/source/js/src/jsapi.h.
- zzzcpan 7y ago
  > One cannot have writeable executable memory on iOS (apple can, we cannot). > Thus one cannot make a JIT compiler for js and thus pages are slow. Lack of JIT doesn't slow down pages much. I believe the difference is so small that it might even be possible to be faster without JIT for most pages, especially on low power devices, it's only computation heavy pages that are going to suffer and even then it's not like you can't optimize common patterns statically ahead of time. It doesn't mean that it's a good idea to invest into it, you are still under Apple's mercy and they clearly don't want competing browser engines.
  - sharpneli 7y ago
    If I have understood correctly (I’m a C++ graphics programmer. So don’t know too much about what’s flashy in the web world) V8 only jits. As in it can only produce machine code and there is not even an option to run it as an interpreter.
    - saagarjha 7y ago
      V8 has a high performance, JIT-less interpreter that disables TurboFan and relies exclusively on Ignition: https://v8.dev/blog/jitless https://v8.dev/blog/jitless
  - chrisseaton 7y ago
    > Lack of JIT doesn't slow down pages much. So why do you think so many major companies invest such a huge amount of money in JS JITs? Google, Apple, Microsoft, Oracle, Mozilla all maintain JS JITs and spend what I guess is hundreds of millions of dollars a year on it.
    - notacoward 7y ago
      A budget of $100M, with 50% devoted to salary and a median salary of $250K, would be 200 developers. I seriously doubt any of the companies you name are devoting even a quarter of that to JS JIT development. Yes, they each make significant investments, but let's not weaken the argument by indulging a penchant for hyperbole.
- saagarjha 7y ago
  > One cannot have writeable executable memory on iOS (apple can, we cannot). Nitpick: you can but you cannot ship it via the App Store.
  - shkkmo 7y ago
    Apple as does not allow side-loading, so wouldn't a jailbreak be required?
    - least 7y ago
      Jailbreak, enterprise certificate, testflight, or a developer account would be required to sideload an app. You can technically sideload an app without a paid developer account, but the certificate only lasts seven days, at which point you'd have to reload the application.
capableweb 7y ago
My guess would be that it's policy-enforced and what Apple really has problems with is not browsers as a concept (dynamically loading and rendering data) but rather the execution engine that websites usually use (JavaScript) and seeing that as a too-large-to-review area where they want to avoid having vulnerabilities in applications published on App Store. Or it's a anti-competitive move disguised as a "avoid vulnerabilities" but in reality they just really want to make sure iOS users keep using the one and only browser (Safari).
- JustSomeNobody 7y ago
  interesting. But I can’t help but think by that logic Facebook should be too large to review.
  - deleted 7y ago
    [deleted]
  - extropy 7y ago
    Facebook does have code that dynamically compiles arbitrary input to machine code. That's the part Apple is not allowing in third party apps.
    - saagarjha 7y ago
      > Facebook does have code that dynamically compiles arbitrary input to machine code. Not outside of JavaScriptCore they don’t.
- marcthe12 7y ago
  Apple uses no Turing complete policy. So you also can't bundle a python or ruby interpreter in iOS. Its still anti-competitive but in a different area which is language and api. They are basically trying to push devs to use their native OS apis. PWA are also screwed up in Safari for a reason.
  - saagarjha 7y ago
reubenmorais 7y ago
I don't know the details first hand, so take this with a grain of salt, but this is what I remember from talking to engineers who explored this possibility over the years: You can't ship a native JIT (execute native code from the heap), I think it's enforced automatically by the App Store. So shipping your own JavaScript engine is out. You can't download and interpret third-party code, I think this is enforced by human reviews, so shipping your own Web rendering stack is out. You can use your own network stack with WebKit on top, which would let you offer some value to users like more advanced ad/tracker blocking.
- robin_reala 7y ago
  This is exactly what Chrome on iOS did: they embedded their own networking stack, but reused WebKit and JSC.
- thekingofh 7y ago
  Thanks for the information. That part about disallowing third-party code interpreting is particularly painful to hear. They shut down any possibility of another browser. Could see that they do this for security reasons because a badly implemented interpreter could open up holes, but I'd imagine the sandbox is sufficient to allow at least interpreters.
deleted 7y ago
[deleted]
saagarjha 7y ago
Web content must be rendered through WebKit as per the App Store Review Guidelines (https://developer.apple.com/app-store/review/guidelines/ https://developer.apple.com/app-store/review/guidelines/). This is supposed to be enforced by App Store Review by inspection. In addition to this, there are technical reasons why your “browser” will be inferior to Apple’s web view performance-wise, mainly having to do with apps that generate code dynamically in-process needing entitlements that prevent submission to the review process.
Yoric 7y ago
Policy-enforced. Mozilla ported the true Firefox to iOS many, many years ago and Apple just rejected it from the store.

decasteve 7y ago

Anti-trust? Or have the lawyers for Apple (and Google) found the legalese to prevent this possibility?

Macha 7y ago
Apple is only a monopoly if the market is iOS devices so they're quick to point out the market is all mobile devices. Google allows sideloading, and allows competitors on the play store
- anoncake 7y ago
  > they're quick to point out the market is all mobile devices. It is not. The market is stores for Ios devices, Apple does have monopoly.

iforgotpassword 7y ago

Yes, however, even as a Firefox advocate, I think in this case it's actually a good thing, since the majority of people would probably switch to Chrome then, contributing to the Blink monoculture.

jraph 7y ago
It's not a good thing, only a bad thing with a good side effect ;-)

nfriedly 7y ago

If Apple allowed Firefox on iOS - real Firefox with the rendering engine and extensions and everything, just like Android - I probably would have switched already. As it stands, I stay on Android mostly for Firefox.

notduncansmith 7y ago
Just curious, why does using “real Firefox” hold so much weight for you? Also, what steps have you taken to secure your device? One reason I haven’t switched from iPhone is that I’m not confident in my ability to secure an Android, and I’d rather trust Apple than Google.
- Transfinity 7y ago
  One big thing is that you can't change the default browser, so any time you click a link you end up on safari. In my experience (I tried iPhone for 2 weeks after my previous phone died, before returning it and switching back to Android) that makes installing a different browser effectively useless. The rendering engine restriction is less obvious to the average user. And, frankly, if you don't trust Apple with your data then what are you doing using their network stack?
- nfriedly 7y ago
  A big part of it is extensions, I have a handful of extensions that I use on a regular basis, and Firefox is the only mobile browser that actually supports extensions. Another part of it is that I just trust Mozilla more. Both in terms of conflicts of interest, and just plain fixing bugs. For example, Safari on iPod touch has been unable to access the microphone for years, even though Safari on iPhones can. I will concede your point about security. I think that iPhones are probably more secure than Androids. But, I feel that the security of my Android phone is sufficient for my needs.
  - Zak 7y ago
    Extensions don't get enough attention in this discussion. They're the main reason I prefer Firefox on Android. Anything that's missing or not to my liking, I can usually find an extension to provide or change. If something annoyed me enough and there wasn't an existing extension, I could look up the API docs and write one myself.

krzyk 7y ago

I wonder why no antimonopolist issue was raised there by e.g. EU. Like they did for NFC in Germany - they forced all phones with NFC to be open to use by different apps, which might finally bring other pay solutions to iOS (or non NFC capable iphones to Germany).

Despegar 7y ago
The NFC issue isn't related to antitrust. If they thought they could make an antitrust case against Apple they would. But their market share is so low in Germany, and the EU, that they just passed a law instead (specifically an amendment to an anti-money laundering law). It remains to be seen if it's even constitutional.

sebazzz 7y ago

Technically I think you are free to build have other browser engines on iOS. However, JIT or other dynamically compiled code is not allowed because that's a security risk. You can't have a browser in 2019 with interpreted javascript.

fauigerzigerk 7y ago
But why is JavaScript JIT compilation tied to the rendering engine?
- andrewl-hn 7y ago
  Yep. technically, Apple doesn't force Firefox to use WebKit. They could still use their Gecko WebRenderer and use Apple's JavaScriptCore to run page scripts. Same goes to Chrome: Blink + JSC instead of Blink + V8. In practice in seems like both Chrome and Firefox have their renderers and JavaScript runtimes so tightly integrated that it's very hard to replace the later.
  - fauigerzigerk 7y ago
    Elsewhere in this debate sharpneli says that there is no public API to call into JavaScriptCore and using non-public APIs violates the App Store rules. So that would explain it.
    - saagarjha 7y ago
      There is API to use JavaScriptCore in your apps: https://developer.apple.com/documentation/javascriptcore https://developer.apple.com/documentation/javascriptcore. No JIT, though, so it’s slow.
thekingofh 7y ago
I think you mean that you can have interpreted javascript, just not JIT compilers. They don't allow you to mark memory as executable. That syscall is completely disabled on their systems.

jrs95 7y ago

It would be a lot more difficult than it sounds for Apple to allow 3rd party browsers and allow them to be good. Even on macOS now, Chrome depends on internal OS APIs which prevent it (or Electron apps) from being in the Mac App Store -- and for good reason, those things could break at any time. So in order to allow 3rd party browser engines that can compete with Safari in terms of performance etc they would need to make the APIs that are used to optimize them public.

EvanAnderson 7y ago
If these non-public APIs are so useful it feels to me that Apple is acting in an anti-competitive manner. They're allowed to use them for their own applications but deny third-parties the right to sell in the "Store" if they use the APIs. Sounds a lot like MSFT in the 90's...
deleted 7y ago
[deleted]

ken 7y ago

That's a convenient excuse on iOS, but Firefox is doing poorly on macOS, too, where no such restriction exists. According to the first statistics I found, Firefox is only about half as popular on the Mac as it in on Windows -- and it's still under 10% there, too. Privacy-compromising systems aren't winning today because people seek out systems that compromise their privacy. They're winning because these companies focused on making the user interface good. Firefox will win big again when they stop talking about privacy and start making a UI that isn't lousy. True, Apple is talking about privacy a lot these days, but they've been focusing on UX first for decades. You can't start with "here is an abstract principle that's good for you, and you should use our systems because of it". The Free Software Foundation tried that for years. It doesn't work. Privacy is important, but it's a feature, not a product. You still need to have a great product.

ragequitta 7y ago
I'm trying to think of a UI difference in chrome or safari that is meaningful, can't come up with one. Can you elaborate?
- ImprovedSilence 7y ago
  i have way too many tabs open at all times, and chrome makes it way way easier to see what I have open and get to the tab I want quickly.(it just shows more tabs than Firefox, this is my main complaint) The top bar uses less vertical real estate and is just much cleaner overall. I can see more if not all of the url. Chromes next tab left, next tab right, and close tab, automatically map to the keyboard shortcut I set in macOS, and I still haven’t even found the menu option for next and previous tab in Firefox. (I’m sure it’s there and I just haven’t found it yet, but if it’s not there, that’s a deal breaker for me) I very badly want to use Firefox as my main browser, and I have it installed and give it a go every now and then, but it’s just not all the way there yet for me.
  - kilburn 7y ago
    The vertical space you can easily fix by opening the hamburguer menu > customize > density (bottom left) > compact. It then uses less space than chrome. You can also add/remove items from the top bar there, making your address bar larger if you want to. The default hotkeys for next/prev tab are cmd+option+left/right arrow. I don't know how to change those...

Chirael 7y ago

It’s nowhere as good or fine-grained as uBlock origin, but I’m surprised no one ever seems to mention (or use?) Firefox Focus and it’s associated Safari content blocker. Seems to work really well for me on my iPad and iPhone, at least for general ad blocking.

alwillis 7y ago

As Apple has reiterated, browser engines require low-level access and for security reasons, other rendering engines aren’t allowed. You can see from Apple’s updates that keeping up with the vulnerabilities for WebKit and iOS, etc. is already keeping them plenty busy: https://support.apple.com/kb/HT210725 https://support.apple.com/kb/HT210725 https://support.apple.com/kb/HT210721 https://support.apple.com/kb/HT210721 https://support.apple.com/kb/HT210624 https://support.apple.com/kb/HT210624 https://support.apple.com/kb/HT210603 https://support.apple.com/kb/HT210603

alwillis 7y ago
My point is this gets dramatically worse if every browser engine has low-level access to iOS.

mr__y 7y ago

You could run the browser on other machine and use VNC to access this from a iphone (or any other mobile device). While this is rather complicated and probably less reliable solution, the bonus points would be (almost) perfect isolation of the browser process.