My understanding is that Xamarin's Ahead-of-Time (AOT) Compiler compiles Xamarin.iOS applications directly to native ARM assembly code (How Xamarin works).
What I don't get, however, is why it needs to be called "Ahead-of-Time" as opposed to just being an ordinary compiler. Is there any distinction between Xamarin's AOT compiler and a traditional compiler or is this just a marketing term?
AOT stands for Ahead of Time compilation, and compiles your code, to the native platform, dependent upon the architecture. The reason you would use AOT, is because it has a drastically reduces startup time, and app performance. You can see some results from Improving Xamarin.
Apple has put a security feature on iOS where it disallows any dynamically generated codes on that device. Xamarin. iOS understands this safety restriction and uses Ahead of Time compiler also known as AOT and compiles the managed codes of Microsoft Intermediate Language (MSIL) and produces a native iOS binary code.
UITest is the Automation Library that allows the NUnit tests to execute on Android and iOS devices. The tests interact with the user interface as a user would: entering text, tapping buttons, and gestures - such as swipes. Typically, each Xamarin. UITest is written as a method that's referred to as a [Test] .
Xamarin is an open-source platform for building modern and performant applications for iOS, Android, and Windows with . NET. Xamarin is an abstraction layer that manages communication of shared code with underlying platform code.
How AOT compares to a traditional JIT compiler
Ahead-of-Time (AOT) compilation is in contrast to Just-in-Time compilation (JIT).
In a nutshell, .NET compilers do not generate platform specific assembly code, they generate .NET bytecode, instructions which are interpreted by the .NET virtual machine. This bytecode is portable, any .NET VM can run it, be it Windows Phone, Mono on Linux, or a JavaScript-based implementation. Unfortunately, because the code has to be interpreted by the VM it is slower than native code which can be executed by the processor itself. That's where JIT and AOT come in.
When a .NET application starts up, the JIT compiler analyzes the bytecode, identifies areas that could be sped up by being translated to native code, and compiles them. During execution, the compiler can also identify hot paths for compilation.
Unfortunately for .NET, Java, and any platform that would benefit from JIT, dynamic code generation is disallowed by the App Store terms of service. Since Xamarin can't perform JIT on the device and they know they're shipping to ARM devices, they can run a JIT-type compiler ahead of time (AOT) and bundle it into the binary.
How AOT compares to a machine code compiler
As mentioned above, AOT translates part of an interpreted bytecode to machine code. It doesn't eliminate the need for a virtual machine bytecode interpreter. The VM will run just as it would if, but occasionally see an instruction that says "Execute this chunk of machine code".
Is this just a marketing term?
No. The message that Xamarin was conveying in that paragraph was that their code performs faster than a simple byte code based language. For both iOS and Android, they are able to execute native code on hot code paths to improve performance. The terms AOT and JIT are technical details about how they do that.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With