To make the explanation short, if you have a hundred times more powerful processor that is small enough to fit inside the mobile device or any devices, then we are wasting our time on the invention of the new compilation technology. Since the processor inside the mobile devices like the phone or tablet are much weaker than the desktop computer, and you already know the problem of the slow startup time of Windows application due to the use of dynamic compilation where it means it compiles on-demand. So let's assume the small device's processor can run the same app, it will take a very long time to do things on the mobile devices, which is unrealistic. So to minimize the work that the weak processor needs to do, ahead-of-time compiled or static compiled files are packaged along with minimal sets of CLR needed to run on the processor. But if it is compiled ahead of time, how about those dynamic .NET features such as reflection or getting the correct types only at runtime? There are two things make the static compilation possible. One is that in the Visual Studio, there is a .rd.xml file that contains runtime directives configuration file that can tell the .NET Native tool chain to make your application reflectable at runtime. Another thing is the ILC.exe inside the tool chain has the heuristics built-in that predicts what are the things you need to reflect on and what types you want to keep until runtime, and rd.xml files are served as hints for ILC.exe in which that the developers gave.
In summary, the .NET Native tool chain made the entire build process possible where it processed the logic and complexity ahead of time before it reached to the device's processor. In the end, applications start faster and smooth even on the weaker processor.