Authors: Kavita Chodavarapu @CKnew234 and Chris Gagnon
Back in March, we shared our plans to meaningfully improve two things that directly affect how you build in UEFN: stability and iteration time.
On stability, that meant expanding developer-made island testing, improving regression coverage, and escalating high-risk defects earlier in the release cycle.
On iteration time, we committed to a significant reduction in the time it takes to get your changes into a live session.
We also committed to sharing ongoing updates—including where things are improving and where we still have work to do.
Here’s the latest.
Where We’ve Improved
Iteration Time
In our previous post, we committed to reducing iteration time—and we’ve been making real progress, getting the time taken to push changes down by an average of 40% so far. That’s even higher for larger projects where we’ve seen reductions of up to 70%.
This reduction comes from a number of improvements that cut push times:
-
Incremental Cooking: The cooker now identifies and processes only the assets that changed since your last push, rather than reprocessing your entire project.
-
Zen DDC: A new Derived Data Cache infrastructure that reduces the time spent retrieving and validating cooked assets, shortening the play-on-client loop.
-
Additional cooking pipeline and upload/download improvements: Faster file transfer speeds, reduced queue wait times, improved asset validation, and Verse compilation improvements.
-
And more: Server- and Client-side load time improvement, parallelization of preparatory steps and validation, and many more improvements throughout iteration as a whole.
We’ve also made significant improvements to Live Edit:
- Live Edit features are available while your game is running.
- You can pause the game, eject from the pawn, and investigate the game state for debug purposes.
- Expanded support for Level Sequences and Sound Buses.
- New UI for reviewing the edit list for the transactions that are taking place live or requiring push, UX improvements to iteration, and plenty of bug fixes for existing Live Edit features.
Our work here isn’t done. Live Edit expansion will be a continued focus to improve iteration experience, Distributed Shader Compilation is still in progress, and we have a number of other improvements planned this year, which will continue to drive iteration time down.
Stability
Since 39.50, we’ve significantly reduced the rate of high-severity regressions reaching developers. We expanded developer-made island testing, tightened our regression escalation process, and improved root cause analysis. The result: significant improvements through 40.00 and 41.00, measurable across two key metrics: Defect Escape Rate (DER) and Major Defect Escapes.
This means we are increasingly successful at catching the most disruptive and developer-impacting regressions before release.
We’ve also shipped Asset Health Tooling and Spatial Profiler updates in 41.00 to give you more visibility into asset issues before they cause crashes or stalls. We’re continuing to work on further improving these tools in future releases.
What We’re Working On
Stability has improved substantially on our most critical metrics, but some areas remain inconsistent—particularly Scene Graph, Join-in-Progress (JIP), custom UI/UMG, validation and publishing, and matchmaking. Many of these regressions involve interactions across multiple systems, originate from changes made weeks or months earlier, or only surface during large-scale developer testing late in the release cycle.
Our current focus areas:
- Expanding automation coverage for Scene Graph and JIP workflows
- Increasing developer-scale testing earlier in release cycles
- Strengthening release review criteria for high-risk changes
- Improving visibility into known regressions and future-targeted fixes
We’ve also started publishing known issue lists ahead of releases wherever possible, giving developers earlier visibility into confirmed regressions and planned fixes.
Looking Ahead
We’ll continue to be upfront about where challenges remain—developers deserve honesty about the complexity of the tools. What we can commit to is continuing to improve detection of high-impact regressions, communicating more transparently, and sharing the actual data behind the work.
Thank you for continuing to build with UEFN and for the feedback, bug reports, and stability survey responses that help shape these priorities.
The one thing that needs doing to add to that list is fixing bugs that are reported by devs. Many get missed as they don’t have the 3 votes needed (Worst thing of this whole system is this). I had one today that was auto closed with no ticket yet is an engine/epic bug but now its in the void (How does this make any sense).