It is possible to use reflection with IL2CPP too but everything that is runtime code generation is off limit, even with NativeAOT
No run-time code generation, for example, System.Reflection.Emit.
It has been arguing many times in past discussions that NativeAOT doesn’t help much since IL2CPP supports more platforms than the current NativeAOT and Unity will still invest in IL2CPP for a foreseeable future. They might enable NativeAOT for compatible platforms, but IL2CPP will be there to stay.
CoreCLR would make IL2CPP entirely obsolete. I’ve seen comparisons between
native C++ code, AoT-compiled native C# code, and RyuJIT output. Since PGO
(profile-guided optimization) works in layers and adapts at runtime based on
the actual data and platform, JIT output often outperforms statically
compiled binaries.
However, there’s a significant caveat:
Mobile platforms need proper .NET AoT compilation support first. Since this likely
won’t be available at launch, mobile development will remain dependent on
IL2CPP for the time being, and later IL2CPP has a high chance of being replaced by
.NET AoT compilation (which is way, way faster to compile).
As for Burst, CoreCLR would significantly narrow its relevance to strictly
vectorized, parallel workloads—and even there, I’m seeing spectacular
performance in .NET 8 through 10. This is before the upcoming async2
implementation (likely .NET 12), which will probably arrive around the same
time Unity ships CoreCLR support.
Most of that is a function of the compiler, not the runtime. We can (and will) upgrade the compiler without needing to wait for the CoreCLR runtime to be integrated. Some things, like support for hardware intrinsics, will depend on both CoreCLR and IL2CPP being ready for them.
No - AOT for IL2CPP is completely independent of AOT for CoreCLR (which we have no plans to adopt anyway). GC behaviour on IL2CPP improves when we upgrade the GC there, it’s not really affected by CoreCLR at all.
As we migrate IL2CPP from using the Mono BCL to using the .NET BCL, there may indeed be performance improvements, though these would be quite specific/targeted to things where the .NET BCL came up with a better way of doing things than the Mono BCL.
This has long since become off topic. I think we need a separate thread dedicated to CoreCRL for Unity
Actually there is, is just not updated😅
Is it possible to use C#9 or 10 with generic math and static interface, also new Linq BCL without CoreCLR?
Also NuGet and projectreference, I think this task was called csproj support or something? Is it depend on CoreCLR switching and will it be adopted before if it’s not?
Will the replacement be part of the much later editor integration, or will we see any speedups at the earliest previews?
To me, the domain reload time has gotten out of control, and I’m eagerly waiting for the compiles to be much faster, or at least no longer blocking the entire editor for several seconds.
Lots of improvements, nothing big next year?!
But the focus on continued UGUI support does seem like a positive sign as it did seem like it was very much waiting to be replaced previously.
Hope to continue enhancing UGUI, as only UGUI can handle the complex UI requirements of large-scale games; UIToolKit cannot replace UGUI.
To clarify: Are you saying there will be a period where JIT builds use CoreCLR while IL2CPP continues to use Boehm?
Could you please elaborate which use case that UITK cannot be able to use and really require UGUI ?
Only at the moment. Because they’re working on it to make it feature-parity with uGUI so one day it can fully replace uGUI.
Large-scale games like Genshin Impact、Zenless Zone Zero all use non-Flow layout for their UIs, which are complex and contain numerous animations and special effects. UIToolKit was originally designed for editor development, and even after so many years of development, it still lags significantly behind UGUI in terms of basic game UI functionality, indicating that it is inherently unsuitable for the UIs of large-scale games.
Instead of abandoning it, why not develop the higher-end UGUI from the start?
Because UITK is actually a way to do UI
I agree that the unity is too slow in developing UITK, but in theory the UITK is actual paradigm for doing UI. While UGUI is just using gameobject to mock UI, literally
It inherently lack aspect of element, styling, dynamic, patterning and a bunches other aspect of HTML system
I worked with every unity provided UI solutions.
UIToolkit is the way to go - at least the promise it delivers.
But like everything made by unity it feels half-assed in some departments.
It’s much nicer in 6.3 and with the AppUI package.
I find it easier to just use regular gameObjects for the UI. It means I don’t have to waste time learning about whatever Unity’s latest UI is, which changes every year.
I do not think uitoolkit will change soon.
It is the way people were asking for right from the beginning.
But maybe we should stop spamming this thread 
There are only IMGUI, uGUI and UI Toolkit. But as of now and in the future, they will only invest in UITK, because we can use it to make both editor and in-game UI.
As stated in the roadmap, uGUI will also receive improvements in the future, but I doubt there will be as much as UITK.
Next year there will be an improvement that lets us edit UITK directly on the scene hierarchy, no different from what we’re doing with uGUI.
Gradually the gaps between UITK and uGUI will close, and there won’t be any reason to choose uGUI anymore.