Hacker News Reader

Comment by codedivine | Hacker News Reader

You can distribute interpreters. However restrictions remain:

1. You cannot distribute an interpreter that can be used for running program code downloaded from the internet. So, for example, your user can save their script and use it themselves but they cannot give it to others (except perhaps through the app store bundled as an app itself).

2. Your interpreter cannot dynamically generate binary code so JIT compilers that generate binary code on-the-fly are not allowed.

edit: For example, LuaJIT cannot do JIT compilation on iOS but it can do JIT compilation for higher performance on Android.

View on HN

Aren't JIT compilers technically pretty infeasible on iOS anyway because of security restrictions?

Yes. 1st restriction above is more for business reasons, so that there are no ways to circumvent the app store, while 2nd is a technical restriction on 3rd party apps for security purposes. Apple apps (like Safari) can obviously do JIT compilation.

However, I speculate even the 2nd restriction is partly for business reasons because it prevents some third-party toolkits (such as those compiling to LLVM) from achieving high performance. You might remember that Adobe was compiling Flash to LLVM to allow devs to port their Flash apps to iOS, but since LLVM cannot do proper JIT compilation on iOS, it will reduce performance.

FWIW: WinRT imposes both the restrictions above. Android technically doesn't impose either for sideloaded apps. But if you want to distribute app through Google Play, the 1st restriction is indeed imposed.

>Apple apps (like Safari) can obviously do JIT compilation.

I hadn't considered this before, but that means that you could potentially use JS as an intermediate representation for other languages in order to leverage Safari's JIT under iOS. Probably too inefficient to be worthwhile for any language that isn't a dialect of JS, but an intriguing concept nonetheless.

The ability to execute from writable memory is enforced at the process level, and only Safari and a few other Apple apps get that permission.

Javascript in Safari is jitted - but JS in a UIWebView used by a third-party app is not.

Gotta love android, you can cheerfully mprotect away the write-protection on executable pages. I've done some dynamic stub code removal that way. Worst case, you can only hose your own process.

Well that's a relief. Now I don't have to feel bad about not turning that idea into a proof of concept.

Reply on news.ycombinator.com