Mono is a magical sauce, mixed into the Unity recipe, which gives it a lot of its cross-platform capability. Mono is an open source project that built its own framework and libraries based on the API, specifications, and tools from Microsoft's .NET Framework and common libraries. Essentially, it is a recreation of the .NET Framework, as it was accomplished with little to no access to the source code. Note that, despite Mono's libraries being an open source recreation of Microsoft's base .NET class library, it is fully compatible with the original library from Microsoft.

The goal of the Mono project is to provide a framework to allow cross-platform compatibility using the .NET Framework as a common layer. It allows applications to be written in a common programming language and run against many different hardware platforms, including Linux, OS X, Windows, ARM, PowerPC, and more. Mono also supports many languages, not just the C#, Boo, and UnityScript we may be familiar with. Any language that can be compiled into .NET's pure Common Intermediate Language (CIL – more on this later) is sufficient to integrate with the Mono platform. This includes C#, but even includes languages such as F#, Java, Visual Basic .NET, PythonNet, and IronPython.

A common misconception about the Unity Engine is that it is built on top of the Mono platform. This is untrue, as the Mono side does not handle many important game tasks such as audio, rendering, physics, and so on. Unity Technologies built a native C++ backend for the sake of speed, and allows its users control of the engine through Mono as a scripting interface. As such, Mono is merely a component of the underlying Unity Engine. This is equivalent to many other game engines, which run C++ under the hood, handling important tasks such as rendering, animation, resource management, and so on, while simultaneously providing a scripting language for gameplay logic to be implemented. The Mono platform was chosen by Unity Technologies for this task.

Scripting languages typically abstract away complex memory management through automatic garbage collection, and provide various safety features, which simplify the act of programming at the expense of runtime overhead. Some scripting languages can also be interpreted at runtime, meaning that they don't need to be compiled before execution. The raw instructions are converted dynamically into machine code and executed the moment they are read during runtime. The last feature, and probably the most important one, is that they allow simpler syntax of programming commands. This usually improves the development workflow immensely, as team members without much experience using languages such as C++ can contribute to the codebase. This enables them to implement things such as gameplay logic in a simpler format, at the expense of a certain amount of control and runtime execution speed.

Note that such languages are often called "managed" languages, which feature managed code. Technically, this was a term coined by Microsoft to refer to any source code that must run inside their Common Language Runtime (CLR) environment (more later), as opposed to code that is compiled and run natively through the target Operating System (OS). But, because of the prevalence and common features that exist between the CLR and other languages that feature their own similarly designed runtime environments (such as Java), the term "managed" has since become a little vague. It tends to be used to refer to any language or code that depends on its own runtime environment and that may, or may not, include automatic garbage collection. For the rest of this chapter, we will use the term "managed" to refer to code that both depends on a separate runtime environment and has undergone automatic garbage collection.

The runtime performance cost of managed languages is becoming less and less significant every year. This is partly due to gradual optimizations in tools and runtime environments, and partly due to the computing power of the average device gradually becoming greater. But the main point of controversy in managed languages still remains their automatic memory management. Managing memory manually can be a complex task that can take many years of difficult debugging to be proficient at, but many developers feel that managed languages solve this problem in ways that are too unpredictable, risking too much product quality. Such developers might cite that managed code will never reach the same level of performance as native code, and it is foolhardy to build high-performance applications with them.

This is true to an extent, as managed languages invariably inflict runtime overheads, and we lose partial control over runtime memory allocations. But, as with all things, it becomes a balancing act, since not all resource usage will necessarily result in a bottleneck, and the best games aren't necessarily the ones that use every single byte to their fullest. For example, imagine a user interface that refreshes in 30 microseconds via native code versus 60 microseconds in managed code due to an extra 100 percent overhead (extreme example). The managed code version is still fast enough such that the user will never be able to notice the difference, so is there really any harm in using managed code for such a task?

In reality, working with managed languages often just means that developers have a unique set of concerns to worry about compared to native code developers. As such, choosing to use a managed language is partly a matter of preference, and partly a compromise of control over development speed.

var method = typeof(MyComponent).GetMethod("MethodName");
if (method != null) {
    method.MethodHandle.GetFunctionPointer();
    Debug.Log("JIT compilation complete!");
}

using System.Reflection;
// ...
var method = typeof(MyComponent).GetMethod("MethodName", BindingFlags.NonPublic | BindingFlags.Instance);