By ByteBot
Unity developers have been waiting more than 8 years for the company to migrate from its outdated Mono runtime to modern .NET CoreCLR—and at Unite 2025 this month, Unity finally admitted it won’t be ready until after 2026. The performance cost is staggering: identical game code runs in 100 seconds on Unity’s Mono versus just 38 seconds on .NET CoreCLR, a 2.6x gap. Synthetic benchmarks reveal even worse results, with some operations running 15x slower on Mono due to inefficient JIT compilation. What started as a 2018 announcement has become a near-decade of broken promises.
This isn’t just a performance problem—it’s a leadership failure. While competitors like Godot shipped modern .NET runtimes, Unity developers pay a 2-10x performance tax on every project. The delay impacts iteration speed (15+ second domain reloads), game performance (2-3x slower simulations), and access to modern C# features like Span<T> and hardware intrinsics that could compound those gains.
The Performance Gap Unity Won’t Fix
Marek Fišer’s detailed benchmark analysis reveals the scale of Unity’s Mono problem. The same C# code runs 100 seconds in Unity’s Mono debug mode versus 38 seconds in .NET CoreCLR—a 2.6x performance difference. In release mode, the gap persists: 30 seconds (Mono) versus 12 seconds (CoreCLR), still 2.5x slower. Synthetic benchmarks testing struct operations show an even more dramatic 15.3x performance difference (11,500ms on Mono vs 750ms on CoreCLR).
These aren’t artificial tests. The benchmarks measure map loading, save file processing, and simulation initialization—real-world game operations that developers perform thousands of times during development and players experience every launch. Fišer’s assembly-level analysis shows Mono’s JIT compiler fails basic optimizations: poor inlining, excessive memory shuffling via MOV instructions, failure to hoist invariant calculations out of loops, and inefficient loop structures.
The impact is real for every Unity project using managed C# code. For developers, it means longer iteration times with domain reloads taking 15+ seconds. For players, it means longer load times, lower frame rates, and reduced game scope—fewer NPCs, simpler physics. For mobile games, it means half the battery life and faster device heating. Unity has known about this 2-10x gap since 2018 and chosen not to fix it.
Eight Years of Broken Promises
Unity first announced the CoreCLR migration in 2018 when Alexandre Mutel (Unity engineer) published a detailed blog post about porting the engine to .NET CoreCLR. At Unite 2025—seven years later—Unity admitted CoreCLR won’t be production-ready until after 2026, with an experimental desktop player planned for Unity 6.7. That’s a minimum of 8-9 years from announcement to production-ready, potentially longer given Unity’s history of experimental features never shipping.
The timeline is damning. In 2018, CoreCLR migration was announced with technical details. By 2022, developers expected it by now—it didn’t happen. At Unite 2024, it was still experimental. The Unite 2025 roadmap reveals “after 2026” for production. Unity 6.7 might bring an experimental desktop player in 2026, but production-ready is speculation for 2027 or beyond.
Unity has paused work on new animation and world-building workflows to focus on CoreCLR migration—an admission that the company can’t deliver on its roadmap without sacrificing other features. As one Hacker News commenter put it: “Unity leadership was more interested in other things for the past 8 years.”
Eight years is an eternity in technology. For context, the iPhone was released in 2007—eight years later was 2015, when the iPhone 6S shipped. In those same 8 years Unity delayed CoreCLR, Godot evolved from a niche engine to a serious Unity competitor with modern .NET support built-in. The delay reveals what Unity prioritizes: marketing and new features over foundational performance.
IL2CPP Isn’t a Real Fix
Most shipped Unity games use IL2CPP (Intermediate Language to C++) instead of Mono to avoid performance problems. IL2CPP converts C# code to C++, then compiles it with platform-specific compilers for better performance. However, IL2CPP introduces different trade-offs: build times extend from seconds to minutes, debugging becomes more complex, and performance is inconsistent—some workloads run 2x faster than Mono, while others (like H264 video decoding) run 2x slower.
Developer sentiment from the Hacker News discussion captures the frustration: “IL2CPP and HPC# are messy and add unnecessary complexity and artificial limitations.” The workaround doesn’t solve iteration speed—developers still endure 15+ second domain reloads with Mono during development, then switch to IL2CPP for release builds. This dual-backend testing adds overhead. Additionally, IL2CPP is mandatory for certain platforms (iOS, WebGL), removing the choice entirely.
IL2CPP proves Unity knows Mono is inadequate—they built an entire workaround rather than fixing the root cause. But a workaround isn’t a solution. Developers want fast iteration during development (which IL2CPP doesn’t provide) AND runtime performance (which Mono doesn’t provide). They also want modern C# features like Span<T>, hardware intrinsics, and C# 12+ language improvements—none of which IL2CPP enables because it’s still limited by Mono’s outdated C# support during the conversion process.
Developers Lose Faith
The recent Hacker News discussion about Unity’s Mono problem (202 points, 100 comments) reveals widespread developer frustration beyond performance complaints. Top-voted comments express doubt Unity can even complete the CoreCLR migration: “Unity has no technical skillset anymore to make the migration to CoreCLR” (+47 upvotes), and “Unity leadership was more interested in other things for the past 8 years” (+28 upvotes).
Developers are questioning whether CoreCLR will ever ship in production form. Unity has a reputation for experimental features that never stabilize—as one developer summarized: “Unity has two ways of solving any problem, but one is deprecated, and the other is experimental.” The 8-year CoreCLR delay reinforces this perception. Some developers report their game simulations run 2-3x faster in standalone .NET compared to Unity, leading them to consider engine migration.
Developer trust, once lost, is hard to regain. Unity’s 2023 pricing controversy already damaged the relationship with its community. The CoreCLR delay compounds this by revealing a pattern: promises made, deadlines missed, developers left waiting. Meanwhile, Godot 5 ships with modern .NET CoreCLR support out of the box, offering Unity developers an escape hatch.
Godot Already Won This Race
While Unity spends 8+ years migrating to CoreCLR, Godot 5 already ships with modern .NET support using the latest CoreCLR runtime. Godot developers get access to C# 12+ features, Span<T>, hardware intrinsics, and 2-10x better runtime performance than Unity’s Mono—all without waiting until 2027. Godot is also 100% free (no revenue share, MIT licensed) and open source, removing Unity’s pricing uncertainty.
Godot’s 2025 competitive position is strong: excellent for 2D games, rapidly improving 3D capabilities with Vulkan renderer and better lighting/shadow systems. While Godot’s 3D still lags Unity and Unreal for AAA visuals, it’s more than sufficient for indie and mid-market games—the segment Unity dominated. For C# developers prioritizing modern .NET features and runtime performance, Godot is no longer a compromise, it’s a better choice.
Unity’s CoreCLR delay isn’t happening in a vacuum—it’s happening while a free, open-source competitor with superior .NET support gains market share. Godot’s timing is perfect: Unity alienated developers with 2023 pricing changes, then failed to deliver on CoreCLR performance improvements. By the time Unity ships production-ready CoreCLR in 2027+, Godot will be even more mature. Unity is ceding the C# game development market to a competitor that does .NET better.
What This Reveals
The CoreCLR delay exposes Unity’s priorities over the past 8 years. Technical debt compounds when leadership focuses on “other things” instead of foundational performance. Workarounds like IL2CPP hide problems instead of fixing them. By the time CoreCLR ships—if it ships—Unity will have lost years of competitive advantage to Godot.
The lesson extends beyond Unity. Eight years is long enough to lose a market. Performance can’t wait a decade. Developer trust, once broken by broken promises and pricing controversies, accelerates migration to alternatives. For Unity developers stuck on Mono, the question isn’t whether to migrate engines—it’s when.
