▲ | Tokumei-no-hito 4 days ago | ||||||||||||||||
it's interesting that a lot of innovation happened on mobile runtimes to deal with apples JIT restriction. what was that about and why didn't android have the constraint? of course i can look it up, but you probably have a better insight than the slop i'll find off google. thanks for the article. these days it's rare to see something so well researched and written while still being able to tell it was authored by a human. cheers | |||||||||||||||||
▲ | toast0 4 days ago | parent | next [-] | ||||||||||||||||
Apple has a JIT restriction because JIT introduces native code that was not present during app review, and app review is where they prohibit calling non-public APIs, at least historically. Android doesn't have a JIT restriction. API restrictions are expected to be enforced at runtime, not through review time checks. | |||||||||||||||||
| |||||||||||||||||
▲ | LinguaBrowse 4 days ago | parent | prev [-] | ||||||||||||||||
The other reploies seem to have answered it! I've never understood why iOS allows JIT inside WKWebView yet not inside bare JavaScriptCore. Maybe because WKWebView runs in its own separate process while a JavaScriptCore instance would run in-process? As for Android, guess Google are just a little more gung-ho? > thanks for the article. these days it's rare to see something so well researched and written while still being able to tell it was authored by a human. cheers Really appreciated, thanks! I do despaire that the ease of generating content with AI disincentivises (and discourages) authors from expending real effort, but there's a satisfying inflection point at which you can be sure you've written something that an LLM couldn't possibly have come up with. |