Hacker News Reader

Comment by radarsat1 | Hacker News Reader

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?

View on HN

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).

interesting. But I can’t help but think by that logic Facebook should be too large to review.

Facebook does have code that dynamically compiles arbitrary input to machine code.

That's the part Apple is not allowing in third party apps.

> Facebook does have code that dynamically compiles arbitrary input to machine code.

Not outside of JavaScriptCore they don’t.

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.

> So you also can't bundle a python or ruby interpreter in iOS.

You can if it’s for educational purposes.

That’s surely absurdly difficult to test, and provably impossible to prove the negative (i.e. my app is not Turing complete.) Is a calculator app not Turing complete? What about Google Sheets?

As long as it uses Apple's WebView, it's OK. This was the case for Firefox, they had to ditch Gecko in favor of using Apple's webview for iOS.

Pythonista is a full(-ish) offline Python IDE and has been on the App Store for years.

This is not true. There is for example the Pythonista IDE for iOS, which ships a full Python interpreter. https://omz-software.com/pythonista/

Is there an example of a non development/learning tool?

If I remember correctly there’s an exception for learning and development tools.

Kivy bundles Python in iOS apps, and the apps are accepted on the App Store. Do you have a link for this policy?

That likely falls under the “educational” exemption: https://developer.apple.com/app-store/review/guidelines/#sof...

That's unlikely, Kivy is also used for commercial apps. Bundling interpreters is allowed, but you must not use them to execute arbitrary code, unless you do it for educational purposes. Kivy doesn't load remote code, so it's not affected by this policy.

Then apps using it must ship all of their Python code in the app bundle to meet the App Store Review Guidelines.

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.

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.

Not via public apis. So cannot be placed into app store.

I think that iOS JS engine is tied to WebView and it would be hard to re-use it with other rendering engine.

JavaScriptCore can be used can be used independently from the rest of WebKit, but I’d expect it to be slow.

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/binding.... It's rather large and complex.

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.

> 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.

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.

V8 has a high performance, JIT-less interpreter that disables TurboFan and relies exclusively on Ignition: https://v8.dev/blog/jitless

> 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.

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.

About 200 seems about right to me across all these companies. Have you worked on one of these teams?

> let's not weaken the argument by indulging a penchant for hyperbole

Please don’t be so dismissive and snide - there’s no need for that.

> About 200 seems about right to me across all these companies.

Then your initial estimate was way off, because you were suggesting multiple hundreds of millions and the average salary probably isn't that high.

> there’s no need for that

Honest argument wouldn't require such forceful correction.

I didn't say a hundred million per company.

> Honest argument wouldn't require such forceful correction.

Please try to tone it down.

> One cannot have writeable executable memory on iOS (apple can, we cannot).

Nitpick: you can but you cannot ship it via the App Store.

Apple as does not allow side-loading, so wouldn't a jailbreak be required?

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.

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.

This is exactly what Chrome on iOS did: they embedded their own networking stack, but reused WebKit and JSC.

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.

Web content must be rendered through WebKit as per the 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.

Policy-enforced.

Mozilla ported the true Firefox to iOS many, many years ago and Apple just rejected it from the store.

Reply on news.ycombinator.com