6 ms·

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 sur

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.

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.