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 andthey 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.