Hi everyone,
As we did with Unity 6.3, this thread is where we’ll share some early information about breaking changes we plan to make in Unity 6.4.
While our goal is for every release in the 6.x series to be a completely seamless upgrade experience, we also need to balance that goal against the need to evolve the product, both in response to external changes in our platforms and ecosystem, and as part of our long-term product roadmap. So, we’re making a few changes that may require a little bit of upgrade work on your part.
We’re communicating these changes now so that you can plan any needed work around them, and to give you the opportunity to let us know if there is some aspect of the change we haven’t considered. There may be further breaking changes in 6.4 that are not captured on this list, but we aim to be as comprehensive as we can be, and will update this thread with new information through to the beginning of the 6.4 beta period.
Narrowing of artifact dependencies
We are changing the way dependencies between assets in the AssetDatabase are handled in 6.4, which unlocks some great performance improvements when importing, but may cause some bad behaviour with your AssetPostprocessor or ScriptedImporter types if your dependencies are under-specified.
The details of this change are quite long to explain, so we made a dedicated topic for it - please discuss there.
The following items were added before October 20th
Removal of HoloLens 2 support
As we announced back in July, we have deprecated our dedicated support for HoloLens 2 as a platform, and the HoloLens 2 package/plugin will not be supported on Unity 6.4. Projects targeting HoloLens 2 should either migrate to our OpenXR plugin (which can target HoloLens 2), or remain on Unity 6.3.
Changes to runtime libraries on Apple platforms
On iOS, iPadOS, tvOS and visionOS, the Unity runtime libraries for device builds (libiPhone-lib.a, libVisionOS-lib.a) will be wrapped into a framework. This means the library path will change from XcodeFolder/Libraries/<Unity Runtime Lib> to XcodeFolder/Frameworks/UnityRuntime.framework/UnityRuntime.
Similarly, the Unity runtime framework for iOS, iPadOS, tvOS and visionOS simulator builds at XcodeFolder/Frameworks/UnityRuntime.framework/UnityRuntime will be changed from dynamic to static.
We’re making these changes so that the libraries are of the same type and at the same path (XcodeFolder/Frameworks/UnityRuntime.framework/UnityRuntime) regardless of whether you’re targeting the simulator or a device. We expect the vast majority of users will not be affected by these changes, but if you are relying on these details - for example, in a post-processing script that is part of your build pipeline - then you may need to update your script to accommodate the change.
The following items were added before October 15th
Removal of UxmlFactory/UxmlTraits
This change was originally planned for Unity 6.4, but ultimately did not land before our internal cutoff, so it won’t be in this release. We still plan to do it in a future release of Unity and still recommend taking any appropriate steps to migrate your projects as soon as you can.
In Unity 6.0, UI Toolkit introduced a modern UI element authoring system based on UxmlElement and UxmlAttribute, powered by Unity serialization. This new system replaces the legacy UXML Factory/Traits workflow, which has been deprecated and will now be removed.
While the legacy system was supported for backwards compatibility, maintaining dual workflows has created bugs, confusion, and long-term costs. The new system offers a cleaner, more robust, and consistent UI experience, so we’re moving forward with it exclusively.
The Unity Manual contains a migration guide. Further documentation and examples can be found in the manual and API reference.
Scriptable Render Pipeline volumes
The SRP Core package - and by extension, the URP and HDRP packages - have previously had a hard dependency on the Physics module, as part of the Local Volumes feature. We are changing this hard dependency into a soft dependency, so that projects using SRPs but not Physics may now be able to strip the Physics module from builds, reducing build size on some platforms.
Explicitly disabling the Physics module (via the ‘Builtins’ section of the Package Manager) will cause the Local Volumes feature to no longer be available in your project.
Packages that use Physics and have a dependency on SRP Core will now need to explicitly declare their own dependency on com.unity.modules.physics, instead of relying on SRP Core providing it transitively. Note that even without this dependency, the physics module is enabled by default for all Unity projects, so a package that does not declare the dependency will usually still work - but existing or future tools that use package dependencies to reason about the project may draw incorrect conclusions without the dependency.
As part of this change, the IVolume interface has been removed. If you have your own custom volume types, you should implement volume visualization instead using the new VolumeGizmoDrawer class.
OnDisable now invoked when destroying grandchild GameObjects
OnDisable() callbacks will now be correctly invoked on components of grandchildren when a GameObject is destroyed using Object.Destroy(). Before this change, only components on the GameObject itself and direct children would have OnDisable() invoked on them.
This change means that the behaviour will be more consistent between Object.Destroy() and Object.DestroyImmediate(); Object.DestroyImmediate() always invoked OnDisable() for the entire hierarchy, and now both methods will do that.
Removal of SRP Compatibility Mode
Following our change in 6.3 to make Compatiblity Mode only available when URP_COMPATIBILITY_MODE is defined, in 6.4 we plan to remove Compatibility Mode entirely, to reduce the maintenance burden on the team and allow them to move faster.
Going forward, all custom render passes will need to use the Render Graph interface instead. For more details, please refer to the Render Graph section in the manual.
