Unity 6.3 LTS, the first Long-Term Support release since Unity 6.0 LTS, is now available on the download page and in the Unity Hub!
Curious about what’s new Unity 6.3 LTS? Check out our feature overview blog post or dive into our release notes and the Unity Documentation. Additionally, you can find all official topics here on Unity Discussions that are related to 6.3 via our dedicated filter. Join us in those topics and share your feedback with us!
Unsure how to go about upgrading? Check out the upgrade guides to help you go from previous Unity releases to Unity 6.3 LTS. For complex productions with a high number of dependencies, find out how our Success Plans can ensure the upgrade process goes smoothly.
Join us for our Unity 6.3 LTS live stream from 2025-12-04T17:00:00Z→2025-12-04T18:30:00Z.
Can you give a sense of how significant this optimization is in practice? Are we typically talking about memory savings on the order of kilobytes or megabytes?
Minor issue: a few of the hyperlinks in the blog post are all incorrectly redirecting to the Render Graph discussion. For instance, it happens with the links after the xAtlas and per-renderer shader vaules sections.
Upgrade from 6.2 to 6.3 Far from smooth release. same error as on beta: The type or namespace name ‘Messaging’ does not exist in the namespace ‘System.Runtime.Remoting’ (are you missing an assembly reference?)
Part of this may be the fault of marketing, but my experience has been that you should only view the LTS branch as something that is supported long term, not something that is robust out of the gate. They only become robust after point releases reach well into double digits, same as every other branch. Maybe branches should only be given the LTS label after they reach that point, to avoid this misunderstanding.
It’s possible more care goes into an initial LTS release than otherwise, but you still shouldn’t expect an initial LTS release to be anywhere near as robust as the preceding, more mature, non-LTS branch. No plan survives first contact with the enemy, as the saying goes.
What is the ‘Api Compatibility Level’ in your Project Settings -> Player set to? I think that namespace is only available when you’re targeting the .NET Framework, not .NET Standard. (Note that this means it will no longer be available once we migrate to CoreCLR, so I recommend migrating away from it anyway).
What you describe is not a great workflow to begin with.
But yeah, if you had not planned or for whatever reason your change choices led you to having to do that, yes.
With proper research and planning early in your project your workflows and pipeline should not lead you to what you described. Sounds messy.
Doing it in your 3D application is the recommended workflow really. Doing it in the engine is meant as a quick touch up solution. Not an efficient workflow. It creates problems down the line too. With different versions of assets between your engine and asset library. Possibly also adds an extra layer of data on your assets where you would only have vertex color data from your 3D application. Doing it en masse may not be optimal.
Of course im using .NET Standard 2.1, .Net Framework is relict of past and even here on forum you can find your employes that dont recommend using .net framework api compability so why someone was thinking its good idea to force everyone switch to this relict with newest LTS version? I just wasted yesterday 3 hours of trying make it work and back to 6.2, no energy to try again, It should be smooth to transist and if there are extra steps that need to be taken with migration then there should be instruction with all required steps.
