That's a pretty lame exuse: if anything, OS integrated JIT engines are likely to be less secure, and a more diverse engine ecosystem makes attacks less attractive. Witness how JIT engines don't cause many problems (and never really have caused many problems) on desktop. Which isn't to say they're immune from security risks, just that there are lots of other components that pose just as many risks (or more), which are not (or cannot) be avoided - not least of which the first-party JIT.
Furthermore, many exploits don't care if their running on a JIT or on a scripting engine - that's an implementation detail. And if you really cared about security, you could design a verifiable native subset (as several systems have done) - webassembly shows that even slow standardization processes that need much more complicated cross-device compatibility can move meaningfully in that direction.
Disallowing non-first party JITs completely for security reasons is at best delusional, but more likely intentionally anti-competitive. Minor security bonuses are just gravy.
Also, as noted elsewhere in this thread, the App Store rules explicitly ban third-party browsing engines, so it doesn't help even if you go without a JIT entirely.
Yeah, but on the other hand there are only a handful of companies that make Browsers, and even fewer that make browser engines. The vendors could pay Apple to audit the codebases and it would be worth it to be on the platform.
Furthermore, many exploits don't care if their running on a JIT or on a scripting engine - that's an implementation detail. And if you really cared about security, you could design a verifiable native subset (as several systems have done) - webassembly shows that even slow standardization processes that need much more complicated cross-device compatibility can move meaningfully in that direction.
Disallowing non-first party JITs completely for security reasons is at best delusional, but more likely intentionally anti-competitive. Minor security bonuses are just gravy.