6 ms·

Interpreted languages are OK, and there are many examples of it. What Apple doesn't allow is JIT

andyjohnson0 4y ago
Good! Thanks for clarifying that.
srcreigh 4y ago
This doesn’t pass the sniff test for me. A language interpreter with downloading remote code abilities is basically a new web browser. Maybe doesn’t use HTTP/HTML/JS, but has similar dynamic abilities. That’s what apple doesn’t want on their platform. Why do you say it has to do with JIT languages?
- lilactown 4y ago
  AFAIK (maybe someone else will correct me) there are two things that people run into when implementing interpreters: 1. You can't write a JIT because you need to be able to dynamically allocate executable memory, which is typically not allowed 2. The App Store needs to know up front what native methods & behavior your app accesses so that it can allow users to observe and control what your app can access. Accessing new native methods by downloading random code over the internet is not allowed There are ways to get around (2) by ensuring you request access to everything your app could possibly access up front, but that could also lead to rejections for asking for permission for things your app doesn't actually need. It's a bit of a dice roll. There was talk that ability to do (1) might be coming in an update a couple years ago, but no official policy change ever came of it.
- Banana699 4y ago
  How would apple know that my app contains my own custom interpreter? It's just a program that takes raw strings (whatever the source may be) and behaves in some arbitrary way according to the string. How can this be detected automatically? Looking for a certain interpreter patterns (e.g. A big switch)? I imagine this would be extremely fragile to false positives and also code can be automatically obfuscated arbitrarily (convert the switch into if-else trees and spread them across subroutines).
- dreamcompiler 4y ago
  Apple even locked down the M1 and M2 machines so that user programs cannot normally produce object code and then jump to it. (IOW the compiler is active at runtime.) Lisp programmers who use Lisp compilers just call this behavior 'Lisp' but everybody else calls it 'JIT' because the only time it comes up in other languages is in interpreters that optimize at runtime. Fortunately Apple carved out an exception for runtime object code on Apple silicon to allow optimizing interpreters to work, and they call it 'JIT.' Because of this loophole it's still possible to run Lisp compilers on MacOS on Apple silicon. Apple never allowed the JIT loophole on IOS, which is why it's not possible to run a full Lisp compiler on IOS. You can run programs created with Lisp but you can't use any Lisp features that depend on the runtime compiler, so the language feels somewhat crippled.

Good! Thanks for clarifying that.

This doesn’t pass the sniff test for me. A language interpreter with downloading remote code abilities is basically a new web browser. Maybe doesn’t use HTTP/HTML/JS, but has similar dynamic abilities. That’s what apple doesn’t want on their platform. Why do you say it has to do with JIT languages?

lilactown 4y ago
AFAIK (maybe someone else will correct me) there are two things that people run into when implementing interpreters: 1. You can't write a JIT because you need to be able to dynamically allocate executable memory, which is typically not allowed 2. The App Store needs to know up front what native methods & behavior your app accesses so that it can allow users to observe and control what your app can access. Accessing new native methods by downloading random code over the internet is not allowed There are ways to get around (2) by ensuring you request access to everything your app could possibly access up front, but that could also lead to rejections for asking for permission for things your app doesn't actually need. It's a bit of a dice roll. There was talk that ability to do (1) might be coming in an update a couple years ago, but no official policy change ever came of it.
Banana699 4y ago
How would apple know that my app contains my own custom interpreter? It's just a program that takes raw strings (whatever the source may be) and behaves in some arbitrary way according to the string. How can this be detected automatically? Looking for a certain interpreter patterns (e.g. A big switch)? I imagine this would be extremely fragile to false positives and also code can be automatically obfuscated arbitrarily (convert the switch into if-else trees and spread them across subroutines).
dreamcompiler 4y ago
Apple even locked down the M1 and M2 machines so that user programs cannot normally produce object code and then jump to it. (IOW the compiler is active at runtime.) Lisp programmers who use Lisp compilers just call this behavior 'Lisp' but everybody else calls it 'JIT' because the only time it comes up in other languages is in interpreters that optimize at runtime. Fortunately Apple carved out an exception for runtime object code on Apple silicon to allow optimizing interpreters to work, and they call it 'JIT.' Because of this loophole it's still possible to run Lisp compilers on MacOS on Apple silicon. Apple never allowed the JIT loophole on IOS, which is why it's not possible to run a full Lisp compiler on IOS. You can run programs created with Lisp but you can't use any Lisp features that depend on the runtime compiler, so the language feels somewhat crippled.