I don't think you are correct. For a proper release, yes, the C#/F#/VB is AOT compiled. For this "Live Player" app, the IL in the DLLs is interpreted. Basing this off of this:
"Microsoft believes its Live Player system is entirely compatible with Apple's rules and regulations for App Store apps. Behind the scenes, the Live Player includes an interpreter for .NET code. This means that running an app through Live Player is slower than it would be if natively built on a Mac, but that's not such a big deal for many aspects of user interface development."
So there are a couple of additional important limitations then, probably (beyond the speed loss of interpreting instead of compiling)
* Won't show up as a separate app on the device (so you can't test that your app icon is OK, or use push notifications, or any other apple service that needs per-app-id provisioning)
* Can't distribute through testflight
* Inconsistent iOS/UIKit behavior. iOS and UIKit enable and disable various compatibility behaviours depending on the iOS SDK used to link the native app you are launching. Obviously this will be set to the SDK that microsoft used when they distributed Live Player to the App Store. Your own application, when distributed on the App Store, may very well be built with a different toolchain version which may trigger different compatibility flags. The most user visible of this was the iOS6->iOS7 total UI redesign (old app builds retained the iOS6 look, newly re-compiled apps got the iOS7 look for everything), but there are tons of similar gotchas in every release (things surrounding table views, button tap behaviors, status bar padding, keyboard sizes, etc etc).
"iOS – C# is ahead-of-time (AOT) compiled to ARM assembly language. The .NET framework is included, with unused classes being stripped out during linking to reduce the application size. Apple does not allow runtime code generation on iOS, so some language features are not available"
Because apple does not allow runtime code generation, then obviously the Live Player preview app won't be able to make use of any ARM assembly language binary produced by .NET. The only way this Live Player preview app stands a chance of being approved by apple is by interpreting everything. Mapping memory executable is impossible for "mere mortals" on iOS, only a few specially-blessed first party apps like MobileSafari can do that (to support JIT javascript). And the whole reason for using the Live Player as a conduit is to avoid the need for a native mac xcode toolchain to package a real .ipa app.
The section you quoted is only applicable for native builds to .ipa (which you probably still need a mac for, since iOS requires the app to be code signed and provisioned even for debugging/development modes)
"Microsoft believes its Live Player system is entirely compatible with Apple's rules and regulations for App Store apps. Behind the scenes, the Live Player includes an interpreter for .NET code. This means that running an app through Live Player is slower than it would be if natively built on a Mac, but that's not such a big deal for many aspects of user interface development."
https://arstechnica.com/information-technology/2017/05/xamar...