A JIT generally means it compiles parts of the program to machine code on the fly before running them, as needed.
To support that, the environment must allow the JIT to write machine code to memory, and then execute that same code.
CPUs have memory protection flags to control which memory areas can be written, and which can be executed. The OS is in charge of setting those flags, on request from the application. Eg. mmap and mprotect system calls.
iOS denies requests for memory that is both writable and executable at the same time. So applications cannot get the type of memory area a JIT needs. There are indirect methods where a file is written then mapped, like generating a small program or shared library on the fly. But iOS restricts these as well.
There are workarounds for a developer's personal applications, used on their own registered iOS devices. But these workarounds cannot be run by everyone else, except people with a jailbroken iOS. They cannot be used in applications on the App Store.
W^X is not the issue here. JITs can deal with that, and in fact should do so even when it's not OS-enforced for security reasons. The problem on ios specifically is code signing, which is a problem for both JIT and AOT.
"There are indirect methods where a file is written then mapped, like generating a small program or shared library on the fly. But iOS restricts these as well."
Note that it is possible to JIT even with W^X. What these platforms do is prevent memory that has been mapped writable and overwritten with new code from ever being mapped executable again.
Comments
How can a platform not support j.i.t. compilation?
In what way does a platform need to coöperate with that?
A JIT generally means it compiles parts of the program to machine code on the fly before running them, as needed.
To support that, the environment must allow the JIT to write machine code to memory, and then execute that same code.
CPUs have memory protection flags to control which memory areas can be written, and which can be executed. The OS is in charge of setting those flags, on request from the application. Eg. mmap and mprotect system calls.
iOS denies requests for memory that is both writable and executable at the same time. So applications cannot get the type of memory area a JIT needs. There are indirect methods where a file is written then mapped, like generating a small program or shared library on the fly. But iOS restricts these as well.
There are workarounds for a developer's personal applications, used on their own registered iOS devices. But these workarounds cannot be run by everyone else, except people with a jailbroken iOS. They cannot be used in applications on the App Store.
W^X is not the issue here. JITs can deal with that, and in fact should do so even when it's not OS-enforced for security reasons. The problem on ios specifically is code signing, which is a problem for both JIT and AOT.
"There are indirect methods where a file is written then mapped, like generating a small program or shared library on the fly. But iOS restricts these as well."
Some platforms are enforcing https://en.wikipedia.org/wiki/W%5EX because malware also wants to create novel machine code within a running process.
Note that it is possible to JIT even with W^X. What these platforms do is prevent memory that has been mapped writable and overwritten with new code from ever being mapped executable again.