Unity is replacing its scripting runtime. Not tweaking it, replacing it. The Mono runtime that has sat under every line of C# you have written in Unity for years is being retired in favour of Microsoft's CoreCLR. It is the most significant change to Unity's foundation in over a decade, and it is no longer a distant roadmap item: the Unity 6.7 public alpha is out now, with CoreCLR arriving as an experimental option.
Most of the coverage treats this as good news wrapped in a version number. It is good news. But if you run a real project, the interesting questions are the practical ones: when does this actually reach me, what changes underneath my game, and what is going to break. Here is that read, from the perspective of a studio that plans and runs Unity upgrades for a living.
What CoreCLR Is, and Why Unity Is Doing It
Unity has been running a heavily customised fork of Mono for years. That custom fork is the reason Unity has always trailed the wider .NET ecosystem: while the rest of the C# world moved to modern runtimes, garbage collectors, and language features, Unity developers looked on from behind a runtime that could not easily keep pace.
CoreCLR is Microsoft's modern, open-source .NET runtime, the same one that powers current .NET. Moving to it does three things at once: it gives Unity a far more capable runtime and garbage collector, it unlocks modern C# and the current .NET library ecosystem, and it dramatically improves iteration time, the write-save-wait-for-domain-reload loop that quietly eats hours of every Unity developer's week. Unity 6.8 is expected to target .NET 10 and C# 14.
To make room for it, Unity has done something telling: it paused new work on animation and world-building workflows specifically to concentrate engineering on this migration and on architectural stability. That is a company choosing foundations over features, which is the right call, and a sign of how big this change is.
The Timeline That Actually Matters
The migration lands across two releases, and the distinction between them decides what you should do.
| Release | What happens | Your posture |
|---|---|---|
| 6.7 (alpha now, LTS targeted late 2026) | CoreCLR arrives as an experimental, opt-in scripting backend, desktop first, sitting alongside Mono and IL2CPP | Test in a branch. Do not ship on it. |
| 6.8 (targeted late 2026) | Mono is removed entirely. CoreCLR becomes the foundation of the C# layer. No Mono option remains. | This is the real cutover. Plan for it now. |
Two things worth internalising. First, Unity has been explicit that 6.8 aims for holistic performance parity first, not a blanket speed-up. Some things will be faster, some slower, and the larger gains come over time as the runtime settles. Treat promises of instant performance with appropriate scepticism. Second, because 6.7 is where you can first put hands on CoreCLR, it is the release to experiment with, even though 6.8 is where the decision becomes unavoidable.
What Changes Under the Hood
The garbage collector is the headline. Mono uses the Boehm GC, which is conservative and non-moving: it cannot always tell precisely what is a live object, and it never relocates memory. CoreCLR brings a precise, moving, generational GC. It knows exactly which objects are live, and it can compact memory. In practice that means less collection overhead and fewer of the stalls that show up as frame hitches. For anyone who has spent time chasing GC spikes in a Unity profiler, this is the change that matters most.
The memory allocator changes too. Unity is integrating MiMalloc, Microsoft's high-performance allocator, which handles the locking problems that hurt multithreaded allocation. If your project makes serious use of the C# Job System, that code gets more stable and more predictable under load essentially for free, just from the engine update.
The C# and serialisation story improves. Beyond the language and library modernisation, Unity 6.7 adds native serialisation for Dictionary<TKey, TValue>, something the community has wanted for years and worked around with ISerializationCallbackReceiver gymnastics. Unity is also removing the old and insecure BinaryFormatter, which is a security improvement but a real migration item if your project or a dependency still uses it.
Iteration gets faster. This is the day-to-day win that every developer on the team feels: compile and domain-reload times come down. On a large project, that is hours back per developer per week.
The Nuance for Mobile and Console: IL2CPP Is Not Going Away
This is the part a lot of the excitement skips, and it is the part that matters most if you ship where we ship.
CoreCLR is a JIT runtime. It is aimed first at platforms that permit JIT compilation: desktop and the editor. But iOS, the consoles, and other restricted platforms require ahead-of-time compilation, and that is exactly what IL2CPP does. Unity has been clear that it has no plans to retire IL2CPP. So the real change is not "Mono to CoreCLR" across the board. It is that the old choice of Mono versus IL2CPP becomes a new choice of CoreCLR versus IL2CPP, with CoreCLR replacing Mono as the JIT option and IL2CPP continuing as the AOT option.
The honest implication for a mobile team: your production iOS and console builds will very likely still go out through IL2CPP for the foreseeable future. That means the immediate, guaranteed win from this migration for a mobile studio is faster iteration and a modern .NET foundation across the team, rather than an automatic reduction in on-device GC stalls on your shipped AOT build. The deeper runtime and GC gains land where CoreCLR actually runs. Knowing which improvements apply to which of your targets is the difference between planning this well and being surprised by it.
What Will Break, and What to Check Now
The migration risk does not sit in your gameplay code. It sits at the boundary between managed C# and native code.
Unity's own engine code, and a great deal of third-party plugin code, was written around the behaviour of the Boehm GC: what it does and does not move, how it handles references crossing into native code. A precise, moving GC changes those assumptions. Unity has had to rework its own internal marshaling tooling to make the transition; native plugins that make similar assumptions will need the same scrutiny.
Concretely, before the 6.8 cutover reaches you:
- Audit your native plugins and native interop. Anything using
p/invoke, custom marshaling, or pinned pointers is where problems will surface. This is the single highest-value thing to inventory early. - Find anything that relies on Mono-specific behaviour or on
BinaryFormatter. Both are on borrowed time. - Check your critical packages and SDKs for CoreCLR readiness, particularly older or unmaintained ones. A dependency that assumes Mono can hold up your whole upgrade.
- Test on the 6.7 alpha in an isolated branch, never in production. The point of alpha access is to find your project's specific issues before they are urgent.
- Follow Unity's quarterly CoreCLR updates. This is moving fast, and the details shift release to release.
Key takeaway: CoreCLR is genuinely good news, a modern runtime, a much better garbage collector, faster iteration, current C#. But it is a foundational change, and foundational changes reward the studios that prepare and punish the ones that assume an engine upgrade will just work. The work is in the native interop, and the time to look is before 6.8, not during it.
How We Can Help
Ocean View Games plans and runs exactly this kind of migration. Runtime and version upgrades, native plugin audits, and the modernisation of older Unity projects are core to what we do, alongside mobile performance optimisation and mobile builds.
The CoreCLR transition is squarely in our territory, because it is fundamentally about the runtime, the garbage collector, and the managed-to-native boundary, which is where mobile performance work lives. And when you work with us, you talk to the engineer doing the work, not a producer relaying it. If you have a project you know will need to make this jump, we can audit it, tell you honestly what the migration involves, and embed to do it as a co-development partner.
Get in touch and we will give you a straight assessment of what CoreCLR means for your specific project.
