It really doesn’t matter too much. CoreCLR is exciting, but not nearly as exciting as up-to-date .NET versions.
The extra performance isn’t going to magically fix your game. You should always work under the constraints of your target platform, anything else is just bad planning and tech worship.
A quick look at the kind of C++ that IL2CPP spits out will tell you why. The code is atrocious.
Part of that is understandable: As a dev you expect that there will be no differences in the behavior of IL2CPP and Mono builds. You want your C++ code to do C# things. That means IL2CPP has to generate a whole bunch of C++ you’d never add if you implemented your game in C++ yourself.
The big issue there is that some C# code lends itself well to being translated to C++, while other C# code will produce a lot of garbage. The unsuspecting Unity dev would be surprised to find out about the kind of C# code that IL2CPP trips over. (I hope you’re minimizing the use of statics, generics and string literals in your C# code if you’re using IL2CPP. 
)
Some problems are on Unity though. Commonly used math functions (like sqrt and atan2) don’t just turn into the pure math you asked for. Instead, a bunch of C# support code is inserted every time you use them. I’m baffled by the decision to not add special handling for math into IL2CPP, given the staggering amount of mathematics involved in games.
I created a build of our game just to check: There are over 1.500 of these sprinkled all over our IL2CPP output. And all of them could be eliminated.
It’s not all bad though.
In the hands of a developer who has some understanding of what makes programs either slow or fast, Il2CPP has tremendous potential.
You can inspect the C++ IL2CPP spits out and the disassembly of your final build.
With those, you can get smart about writing the kind of C# that IL2CPP can turn into the kind of C++ that the compiler can optimize well.
Did you optimize the math functions by rewriting them yourself? And did you inspect the C++ code by decompiling the exe/dll?
0% chance any Unity 7 news so early. Best case scenario Q4 2025 imo
maybe 2027 is unity 7
Unity puts the C++ code into your build folder. On platforms like Windows, you can optionally have the build also generate a Visual Studio solution for you.
As for the math issue. There is no reasonable fix for Unity users. The Unity developers would have to fix it on their end. What is happening is that the Unity Mathematics package (what I’ve been using in that specific example) relies on System.Math for some functionality. The issue is that System.Math does some things which cause IL2CPP to generate that initialization code every time you call it.
In my case, Unity’s math.sqrt() calls System.Math.Sqrt(), which makes IL2CPP generate a bunch of pointless initialization. Since I can’t edit System.Math, I can’t fix the issue.
The normal C# List<> type is another such case. It also generates a ton of initialization code all across your build. And since a lot of Unity’s APIs use Lists rather than Arrays, you can’t really avoid using them.
I don’t want to come off as antagonistic (I acknowledge I’m the problem…), but after reading through all the messages in this thread and its predecessor, I still don’t understand why CoreCLR is so exciting for me as a developer who primarily ships on mobile (with increasing focus on Web). We use IL2CPP exclusively because our platforms have to, use Burst, Collections, Mathematics and the job system extensively (but not ECS), and frequently write C++ when HPC# isn’t a fit.
Somewhere along the line, I heard “2x faster for your generic C# code,” which sounded great, but if that’s “2x faster in the editor” (since we don’t have a Mono build), then that’s “just” a workflow improvement.
I completely understand the benefits of CoreCLR aligning Unity more closely with Microsoft, potentially reducing costs for the platform. There’s also the theoretical benefit of “more stuff working on more platforms,” but in the real world, I doubt the Azure CosmosDB libraries (just picking a random non-Unity-aware .NET library that loves using every modern .net feature because it can) will magically start working in a Unity Web build. In practice, most .net libraries are excluded from Unity web because of dependencies on System.Net or System.Threading, rather than by language features (or have I missed the whole point and the whole framework including System.Net, Threading, etc starts to work on all Unity platforms with CoreCLR and .net framework 8?)
Having new standards like System.Numerics.Vectors is “nice”, but we’ve got Unity.Mathematics with Burst (and in fact, for burst jobs that are CPU-so-debuggable versions of your compute shaders, System.Numerics results in more code diffs between CPU/GPU so it’s a slight workflow step back.)
There may be some awesome language or framework features that offer direct programming benefits I’m unaware of, but 30 years of C++ have made me cynical about new language features.
I want to be told I’m wrong. Can someone explain to me in very concrete terms why I should be excited about this move? Just to be clear, I’m not saying Unity shouldn’t transition to CoreCLR - in fact it must transition because the platform needs to be viable going forward. I just want to understand whether I, as a programmer using Unity, should be excited, or see it as a necessary transition that maybe also brings some workflow / standard alignment benefits.
Significantly better editor performance. Better feature parity with modern .NET, including new C# versions. Possibly stuff like hot reload?
Latest C# versions as quickly as they release? Faster compilation times as we are going away from Unity Compilation and are using MSBuild? NuGet Packages? Abstract Static Mathematics? Sln files instead of asmdef? No static reload aka Domain Reload aka the infamous „Reloading Domain“ bar (f**kin piece of sh*t)
CoreCLR did not relate to IL2CPP
CoreCLR is about what C# can be converted into IL before it would become 2CPP
As developer you should understand C# and dotnet ecosystem was progressing and evolving with newer tool and paradigm it can be used and converted into IL, not just language feature. Without CoreCLR unity will stuck and waste their time maintaining their own fork that incompatible with the whole dotnet that will always better than unity can do. The gap will only widen because unity is just game engine company while dotnet ecosystem as a whole is far more enormous and being used in everything
There was always C# code or library people had been made to solve problem and we could avoid reinventing the wheel by using existing solution already presented in dotnet ecosystem, if unity just use CoreCLR properly
The new versions of .NET will produce more optimized IL code and that will help IL2CPP builds too, hopefully.
Although there might be a lot of work needed in IL2CPP to support any new features added to IL that are supported by the newer .NET runtime and JIT.
I largely agree with you.
The one reason I care about CoreCLR (and I think you should care about, too) is that Unity promises it fixes domain reload times. In any sizeable Unity project, domain reload times just crush your ability to iterate rapidly.
The longer it takes to iterate, the fewer times you can click the play button. This doesn’t just mean fewer opportunities to find bugs. Your games will become less well designed and less fun, because you didn’t put your design decisions to the test as often. Because sometimes your code isn’t buggy, but a bad idea for game design reasons.
Agreed, iteration time is king. We have domain reload disabled. It’s not perfect, and annoying to debug every time somebody adds a static in a way they assume is ok, which if you have 3rd party dlls with static init issues isn’t even an option. Will be nice to be rid of editor domain reload.
My understanding is that you can use CoreCLR directly on Android (not on iOS though) - and that should significantly boost performance on low-mid range android devices. Also vastly improve your stack traces for debugging and finding bugs in production games that run both on Android (CoreCLR) + iOS (IL2CPP).
Additionally Unity will then use the better Garbage Collector - and that will again speed up your code significantly - especially if you use stuff like async/await, linq, foreach or even lists and so on.
Are the employees in charge of the coreclr migration not affected by the recent layoffs?
I think it will be Android and iOS both with latest .Net AOT for those platforms
.Net have support for WIndows, Linux, MAC, Android and iOS so we can see those supported in Unity but all other ones will be IL2CPP only
I mean you shouldn’t assume that .NET AOT will be used… The Unity team said they will look into it, not implement it.
Also most likely CoreCLR should outperform AOT on Android?
My game’s client (Unity) and server (CoreCLR) both use a shared .NET Standard 2.1 library. Identical game world generation executes 10x faster in .NET 9 compared to IL2CPP.
An order of magnitude difference in performance should not be discounted.
CoreCLR is about what C# can be converted into IL before it would become 2CPP
This is completely wrong. It’s Roslyn who converts C# into IL. CoreCLR is the runtime of .NET which has a JIT compiler to compile IL code into machine code that can be executed directly.