Introduction to scripting back ends
Understand the available scripting backends and their effects on your project.
Read time 5 minutesLast updated 6 days ago
Scripting back end is the Unity term for the runtime technology that compiles and executes your C# scripts. It determines how your code is turned into executable instructions and what runtime manages it on target platforms.
The choice of a scripting back end can impact various aspects of your project, including:
- Build times and iteration speed.
- Runtime performance and memory.
- Platform support and requirements.
- Support for some .NET features such as reflection and dynamic code generation.
- Debugging and profiling experience.
Unity supports the following scripting back ends:
- CoreCLR: CoreCLR is the open-source, cross-platform .NET runtime maintained by the .NET Foundation as part of the modern .NET platform (the successor to .NET Core). It provides the execution engine, garbage collector, and Just-In-Time (JIT) compiler that power .NET applications across Windows, macOS, and Linux.
- IL2CPP: A Unity-developed scripting back end that converts your C# code and assemblies into C++ code, which is then compiled using a platform-native C++ compiler to produce a binary file for the target platform. IL2CPP uses ahead-of-time (AOT) compilation to convert your code before runtime.
Platform support
CoreCLR is supported on the following platforms:
- Windows x86/x64/Arm64
- macOS Arm64
- Linux x64
IL2CPP is supported on all platforms.
Any platform not mentioned in the previous list of CoreCLR platforms is IL2CPP-only. On platforms that support multiple back ends, CoreCLR is the default.
Note
Scripting back end support can change between releases. For the latest information, refer to the platform-specific Player settings for your target platform and Unity version.
Changing the scripting back end
You can change the scripting back end Unity uses to build your application in one of two ways:
-
Through themenu in the Editor. Perform the following steps to change the scripting back end through the Player Settings menu:Player Settings
?
- Go to Edit > .Project Settings
?
- Click on the Player Settings button to open the Player settings for the current platform in the Inspector.
- Navigate to the Configuration section heading under the Other Settings sub-menu.
- Click on the dropdown menu, then selectScripting Backend
?
, or CoreCLR.IL2CPP?
You can also open the Player Settings menu from the Build Profiles window; go to File > Build Profiles and click on the Player Settings tab. - Go to Edit >
-
Through the Editor scripting API. Use theproperty to change the scripting back end that Unity uses.
PlayerSettings.SetScriptingBackend
The Configuration section of the Player settings
Scripting backends comparison
CoreCLR uses its own base class library and garbage collector and only supports the .NET Standard API Compatibility level. IL2CPP shares CoreCLR's base class library and supports the available API compatibility levels, though some restrictions specific to IL2CPP and certain AOT platforms apply. For more information, refer to IL2CPP restrictions.
The following table provides a side‑by‑side comparison of CoreCLR and IL2CPP scripting back ends across key features:
Feature | CoreCLR | IL2CPP |
|---|---|---|
| Execution model | Just-in-time (JIT) with tiered compilation via RyuJIT. | Ahead-of-time (AOT): C# to IL to C++ to native code |
| Platforms | Windows, macOS, and Linux desktop platforms only. | Widest support and required for iOS and most consoles. |
| Cross‑compilation toolchain | Minimal; JIT compiles managed assemblies as needed. | Requires C++ toolchain (Clang/MSVC), platform SDKs; longer build/link times. For more information, refer to Linux IL2CPP cross-compiler. |
| Build time | Faster iteration, smaller linking steps. | Slower (C++ codegen, compiling, and linking), larger generated codebases. |
| Startup time | Typically slower with JIT (warmup, tiered JIT cost). | Typically faster (fully native, no JIT warmup). |
| Memory usage | Smaller code size with JIT; uses a modern, generational garbage collector. | Larger native binaries; additional generated C++ and metadata |
| Exception handling | Managed exceptions via the CoreCLR runtime. | Managed semantics mapped to native via IL2CPP runtime support. |
| Reflection | Full reflection works, dynamic codegen supported. | Reflection works for existing metadata, but dynamic codegen has limits. |
| Generics | Full support, JIT can specialize at runtime. | AOT uses ahead‑of‑time generic sharing and IL2CPP might need additional AOT hints to avoid missing method or type errors at runtime. For more information, refer to Generic types and methods. |
| Code stripping/linker | Managed linker, easier to keep symbols due to JIT. | More aggressive stripping, must annotate or configure to preserve reflected or dynamically loaded members. Use a |
Interop ( | Standard | Standard |
| Debugging (C#) | Supports both mixed-mode (managed and native) and pure C# managed debugging with Visual Studio or Rider. For more information, refer to Debugging C# code in Unity. | Supported managed debugging, stack traces can be optionally enhanced. For more information, refer to IL2CPP managed stack traces. |
Note
Mono is not included in the previous table as it has been removed as a scripting backend in Unity 7
On platforms where you have a choice between IL2CPP and CoreCLR, prefer IL2CPP if Player builds need faster startup, stricter platform compliance, and more predictable performance. CoreCLR offers faster iteration in Editor and desktop development, faster build times, and is the only option if you need to use APIs not supported by IL2CPP.
Tip
Whichever scripting back end you choose, you can supplement it with the Burst compiler to compile select parts of your code to highly optimized native code. For more information, refer to Burst compilation.