There are not legitimate security reasons for Webkit only. That makes zero sense. Chrome has hands down beat every other browser on security for years. Go read the CVEs. There is absolutely zero reason to believe that iOS webkit has a better track record than webkit at large. Therefore it's nearly certain your iOS device is less secure browsing the net with webkit/Safari than if Apple allowed real chrome to run there.
Which are both control issues not security issues.
There's no actual security reason for iOS to be locked to Apple's webkit exclusively and there's no actual security reason for iOS to not allow JIT'd code. Those are both control issues, not security ones. JIT in particular is purely a control issue - the process itself is already sandboxed which is the one and only actual security boundary here. Preventing a JIT doesn't prevent arbitrary code execution, after all, especially if there's an interpreter in play which Apple sort of allows.
Google has a track record of fixing Chrome bugs far far faster than Apple fixes Safari bugs so the point still stands. You'd be safer and more secure if allowed to run real Chrome on iOS than Safari by every measurable metric. In other words it's effectively provable the restriction is not about security.
> Apple doesn't want to allow that.
Yes, that's all it's about. Apple's control. Other excuses people make up for their reasons are demonstrably false.
WinRT sandbox has always allowed for JIT'ted code, all the way back to the original Windows 8 release - all .NET Store apps back then were running on a JIT. .NET Native is a later addition that is there solely to improve performance, and it is still opt-in.
Now, Win8.x did not allow for third-party JIT compilers in the sandbox; it was only CLR or Chakra. But UWP does - look for the "codeGeneration" capability here:
WP 8.x did not JIT code on device, hence the whole MDIL and cloud compiler on the store.
WP 8.x only did dynamic linking at installation time and when OS updates were done, by replacing symbolic labels with the actual target destinations. Everything else was already compiled at the store and downloaded as binary into the devices. This was the whole point of MDIL.
There is a BUILD session and a further Channel 9 deep dive interview showing how MDIL deployment works on WP 8.x.
> You misunderstand. Apple can fix WebKit bugs, but they can't force Google to fix Chrome bugs.
If apple could make their browser the defacto browser of tomorrow in the way chrome is today then google would surely work harder to fix the pain points apple identifies
