CoreCLR, Scripting, and Serialization Update - June 2026
Hi everyone,
Following our public roadmap sessions at GDC 2026 and our previous community update, we are back to share our next quarterly look into the technical evolution of the Unity Engine. As we march closer to our ultimate target of a full CoreCLR Editor in Unity 6.8, we have several crucial adjustments, ecosystem updates, and framework refinements to discuss across our upcoming releases.
Let’s dive straight into what is hitting in Unity versions 6.6, 6.7, and 6.8.
Unity 6.6: Workflow Efficiency & Core Refinement
Unity 6.6 is heavily focused on setting the baseline for workflow efficiencies, engine standardization, and cross-framework modernization. Along with this foundation, we are implementing significant pipeline updates:
Fast Enter Play Mode (FEPM) by Default & Static State Prep
The most significant workflow change in Unity 6.6 is that the default setting for entering playmode is now scene reload only for all new projects. This means code will not be reloaded, and state, such as static variables, is not reset when entering playmode. Making it the standard helps ensure fast transitions from Edit to Play mode in real-world projects.
- Why are we making this change? With the complete move to CoreCLR, traditional domain reloads go away entirely in Unity 6.8. Code that is migrated today can be prepared for the changes coming with CoreCLR in the future.
- Ecosystem Readiness via Project Auditor: Turning FEPM on by default gives developers a clear runway to handle static state cleanup. We have been actively using Project Auditor to track down static fields and un-reset delegates across the most popular Asset Store solutions. We have notified the Asset Store creator community on how to repeat these diagnostic tests, and we are already tracking fantastic success stories of developers quickly resolving potential memory leaks and compatibility bugs. Project Auditor is included with the installation of the Unity Editor in versions of Unity 6.4 or later and available as a package for earlier versions of Unity as far back as Unity 2018.4.
Native Dictionary Serialization
We are incredibly excited to announce that Unity 6.6 now natively serializes Dictionary fields directly. You can now author and edit dictionary data in the Inspector without writing custom wrapper structures or boilerplate serialization code.
- How it works: Simply apply the [SerializeField] attribute to a dictionary field on a MonoBehaviour, ScriptableObject, or nested [Serializable] type, and Unity will seamlessly persist it across domain reloads, scene saves, and Play mode transitions.
- Inspector & Validation: The Inspector displays serialized dictionaries as an intuitive, two-column list layout with keys on the left and values on the right. Additionally, a built-in serialization rules analyzer validates your key and value types at compile time to catch unsupported signatures immediately.
Deprecation of the Serialization Package (com.unity.serialization)
The com.unity.serialization package is officially marked as deprecated in Unity 6.6.
- Migration path: If your project relies directly on it for unique JSON or binary traversal, you can avoid immediate compilation friction by embedding the package directly into your local project. For long-term development, we recommend migrating to standard framework alternatives such as System.Text.Json or community ecosystems like Odin Serializer and MemoryPack.
Burst Integration into the Engine Core
While we covered this in another post back in March, another fundamental shift hitting in Unity 6.6 is that the Burst compiler package is no longer needed. Its functionality is now entirely built-in. Burst is moving away from a standalone Package Manager footprint to become a built-in module of the core engine itself.
- What this means for upgrading: If you reference Burst via your project’s Packages/manifest.json, you do not need to take any action; the legacy package references will automatically redirect to the built-in core module version.
- Breaking Change Warning: If you have an embedded or local version of the Burst package in your project, it will break upon upgrading to 6.6+. You should prepare to remove any local versions before starting your upgrade, as you will no longer be able to make local modifications to Burst files. Moving forward, all subsequent updates to Burst will be shipped directly as part of the core Editor installation instead of separate package updates.
Memory Optimization: True Multi-Threaded Allocation
We are continually driving optimization across both time and memory dimensions. In Unity 6.6, we are introducing true multi-threaded memory allocation through Microsoft’s open-source mimalloc. This change improves several internal benchmarks and we anticipate it will allow future optimizations regarding memory allocation.
Unity 6.7 LTS: Consolidated Runtimes & Unified Analysis
Unity 6.7 LTS serves as our final release built upon Mono, but it acts as a critical public validation for our new scripting backends.
Public Experimental Releases
First, we’d like to be clear that experimental releases are not supported. Do not use them for active productions. They are a way to get hands on early with new technology and to provide feedback to us on what works and doesn’t work for your particular needs. That being said, we are close to making a public experimental release available alongside the LTS release. In these releases, we’re targeting functionality, and don’t expect performance improvements. While built upon updated scripting runtimes, these experimental releases will be constrained to the current .NET Standard 2.1 API and C# 9 language version supported by Unity.
- Experimental CoreCLR Desktop Player: Has been released in Unity 6.7 Alpha 2 as a Public Experimental Release.
- Experimental IL2CPP Player: Coming shortly after as part of the Unity 6.7 Alpha cycle as a Public Experimental Release.
Unity 6.8: The CoreCLR Era & Unified Tooling
When we cross the threshold into Unity 6.8, Mono is completely stripped from the ecosystem. We are fully committed to delivering a fully-supported, CoreCLR-backed editor and a CoreCLR Desktop Player in this release, with access to .NET 10 and C# 14.
Parity First
We want to be completely transparent regarding our engineering goals for the initial 6.8 Alpha phase:
- The Goal: Our strict internal focus is on functionality and performance parity. We are working to ensure that the CoreCLR Editor satisfies our rigorous quality bars, third-party code compiles smoothly, and existing games load correctly. We are also doing Production Verification as part of this validation process to check our updates with actual Unity projects like Survival Kids and many others.
- The Optimization Phase: We are explicitly delaying major performance optimization work until the subsequent LTS release following Unity 6.8 in 2027.
Technical Resource Library & Documentation
To help your teams navigate these foundational updates and update their custom build pipelines, please reference the active links below:
We’ll be watching the comments section below to answer your technical questions, look over your feedback, and hear your thoughts on these changes!
What part of the consolidated .NET, scripting, and CoreCLR modernization are you most excited to deploy in your pipelines?
, no just joking, but… 
