Goodbye Mono: Why Unity is Switching to CoreCLR

Recently, in a video from the GDC 2026 session, Joe Valenzuela, senior director of the Core Engine team, shared plans for Unity's transition to the CoreCLR runtime.

There is talk that the engine needs a modern one.NET, we've been in the community for over five years now. There have also been occasional reports in the Unity community that there is a desire to switch to CoreCLR, but there have always been many difficulties.

It should be noted that Unity currently uses its own version of Mono. Because of this, the Unity engine remained hostage to this custom architecture for years, and we could only look with envy at the features of the new versions of C#.

But now, the ice has broken! By the end of 2026, with the release of Unity 6.8, this Mono branch will go into a well-deserved retirement, and we will receive a full-fledged CoreCLR with support.NET 10 and C#14.

Let's look at why this is incredibly cool news for each of us.

1. The Death of Domain Reload

If you work in Unity with large projects, then you are familiar with the situation when you write one line of code, save it, go to the editor and wait. You wait for the download bar to crawl to the end. This process is called Domain Reload and on large projects it can take tens of seconds.

With the transition to CoreCLR, the engine gets rid of the old AppDomain concept in favor of modern Assembly Load Contexts (ALC). Instead of a "nuclear explosion" with full unloading and loading of all memory, Unity will be able to point-reload only the modified code.

Already in Unity 6.6, the "Fast Enter Play Mode" mode will become the default for all new projects. Yes, we'll have to learn how to clean up static variables correctly (by the way, Unity rolled out a cool Project Auditor tool to find such problems), but the opportunity to test features instantly is worth it!

2. ECS for Everyone

I love the performance of DOTS (Data-Oriented Technology Stack), but let's be honest: writing pure ECS code is still a pleasure, and combining it with regular GameObjects has always been a crutch.

Unity plans deep integration under the slogan "ECS for All". Developers are finally converting classic Instance IDs from 32-bit to 64-bit. This sounds like a dry technical detail, but in fact it is a fundamental shift: now ordinary scene objects and ECS entities will have a single ID dimension. We are already seeing the first steps towards this in the form of the GetEntityId() method, which makes it easy to connect the familiar GameObject with the world of high-performance computing.

You no longer have to choose between "it's convenient to assemble a scene in the inspector" and "it works at 120 FPS". We will even have a new Hierarchy v2 window where objects and entities will live together.

3. Native Serialization of Dictionaries

Unity 6.7 will finally have native support for Dictionary<TKey, TValue> serialization right out of the box! No more dancing with a tambourine or converting lists of keys and values through the ISerializationCallbackReceiver interface. Finally, a full-fledged serialization of the dictionary will appear! You can't even imagine how long the community has been waiting for this.

By the way, Unity is also cutting out the old and insecure BinaryFormatter. It was time to do this a long time ago for the sake of the safety of our games.

4. Performance Is "Free" and the Future of IL2CPP

You can say that release games are collected through IL2CPP anyway, where JIT compilation is irrelevant, and you'd be right. A logical question arises: what will happen to IL2CPP when switching to CoreCLR? Will Unity switch completely to native compilation (NativeAOT) from Microsoft?

The answer from the developers of the engine is already there: Unity has no plans to abandon IL2CPP. The main reason lies in the fact that CoreCLR's NativeAOT does not physically support all the target platforms that Unity works with, and the creators of the engine do not expect this situation to change. However, great news awaits us: it is expected that around the release of Unity 6.7, a CoreCLR technical preview will appear as an independent "Scripting Backend" option (similar to the choice between Mono and IL2CPP now). Thus, IL2CPP will not go anywhere for those platforms where it is needed, but for compatible platforms we will be able to use a full-fledged CoreCLR runtime.

In addition to the updated code, Unity completely changes the memory allocation system by integrating MiMalloc, Microsoft's top allocator. It brilliantly solves locking problems in multithreaded scenarios. Your multithreaded C# Job System code will run more stable and faster simply as the engine is updated.

Result

You know, reading this roadmap, I am sincerely happy. Unity has stopped chasing only beautiful high-level features and has finally embarked on a major overhaul of the foundation. Yes, we'll have to wait a little bit until 2026. Yes, we will have to adapt our code to "Fast Enter Play Mode".

But as a result, we will get a modern, lightning-fast tool that will allow us to use all the current features of C#14 and compile games faster than ever. The future of Unity looks very promising!