[mikeash]

W^X is not some code word for "secure". It has a specific meaning, and that specific meaning is completely compatible with JIT code. All it means is that you have to call mprotect() after generating code.

One can debate the security implications of allowing programs to mark code as executable at all, but that debate is unrelated to W^X.

[0x0]

I'm guessing there are two reasons -

1. Preventing any app code from allocating memory and setting it executable: Apple doesn't seem to want to allow dynamically adding code to any app store apps. See: No .dylib support, the earlier bans on all types of interpreters, etc. It would be too easy to get a "Loader"-type app into the app store that could download and execute random app code from the internet that hasn't been vetted by the app store review team. (Emulators, plugins, addons that call private APIs, etc. etc. etc.)

2. Limiting the vulnerability surface: Reduce the risk of webkit exploits targeting app store apps (or even non-webkit random exploits in the app's code allowing loading of shellcode)

[mmastrac]

You are correct. I'm (incorrectly) using W^X here to refer to Apple's W^X, which is effectively setting W^X on pages at image load time for preventing execution of dynamic code -- and possibly for security, but I imagine that is more of a bonus from their point of view.