They prohibit on-device dynamic native code generation (ie. no JIT and no interpreters that attempt to mark memory as executable).
They also (generally) prohibit interpreters that download code from the network and execute it.
If you're doing a workflow like: non-ObjC language -> llvm -> native code, Apple has no problem with that generally (currently).
They just want to make sure that the executable code that ships in your iOS app is all they have to worry about, that it can't generate access to system libraries/routines that were not present when submitted to them.
This is why things like Pythonista and LuaBox are in the store currently, in addition to many apps written in other languages with other IDEs (Xamarin, etc.)
They prohibit on-device dynamic native code generation (ie. no JIT and no interpreters that attempt to mark memory as executable).
They also (generally) prohibit interpreters that download code from the network and execute it.
If you're doing a workflow like: non-ObjC language -> llvm -> native code, Apple has no problem with that generally (currently).
They just want to make sure that the executable code that ships in your iOS app is all they have to worry about, that it can't generate access to system libraries/routines that were not present when submitted to them.
This is why things like Pythonista and LuaBox are in the store currently, in addition to many apps written in other languages with other IDEs (Xamarin, etc.)