I continue to use UGUI, I know it and it is very flexible.
Curious what the divide is between UGUI and UI Toolkit?
Is UGUI to be supported long into the future?
Because just in v6 we have new shader graph support for UGUI which is great but hugely lacking samples for procedural shapes currently! With built-in procedural shape (image-free) support it can be really good, only SVG support would then truly make it future proof!
Personally I’m still using UGUI a lot… I use a lot of advanced shaders and filters with it, which sadly UI toolkit can’t yet do… I use UI Toolkit sometimes when I have build a UI that a designer wants to use CSS (USS) with… I hope that UGUI will still continue to be supported as it’s a lot easier to just jump into and start building basic GUI, especially for prototyping or simple apps… UI Toolkit is heavier…
Hi @andyz and thanks for the question.
We’re continuing to invest in UI Toolkit so it can achieve all the things you can do using UGUI, while being more productive and performant.
As you and @ChocDino pointed out, lack of custom shaders is something missing from UI Toolkit, which is currently under development, as well as a solution for world-space UI.
Meanwhile, since the day we released UI Toolkit, we’re continuing to maintain UGUI until we’re confident UI Toolkit is a good replacement for it. And we’ll make that decision when you tell us it is. @ChocDino, you’re right; even though UI Toolkit scales much better for larger projects, it does require a lot more setup and might be less efficient for smaller use cases. This is also something we’ll want to address.
All that to say, yes, UGUI will remain supported until we’re ready to deprecate it, which will be announced ahead of time.
Cheers,
I thought I read that UGUI would be deprecated in Unity 7000.X. Is this no longer the case?
This new forum still confuses me.
That was our goal, but we never announced it, and we’re continuously re-assessing.
We’re all adapting 
Should in the future that UGUI is deprecated, would Unity consider donating it to the community via open source, so that projects that choose to keep using it could maintain and expand it on their own, assuming there is no technical hurdles e.g. UGUI depends on any core C++ code that we cannot modify?
I for one am not a fan of writing CSS style sheets and HTML when I had to do web development at my day job, so I am not sure how well UI Toolkit would make the developer experience on par with UGUI, as UGUI workflow is just normal GameObject and Component workflows that feels natural in Unity. Because of this, personally, I’m pessimistic about UI Toolkit replacing UGUI.
Certainly I think too many people use it to consider deprecation currently, even if UI Toolkit gets to feature parity. We will see, but for long term projects it would be difficult to replace
We’re considering it.
UGUI does have C++ code for its rendering side - Unity - Scripting API: CanvasRenderer
So that will introduce some technical issues if we want to continue to support a community version.
We are working on improving the tooling for UI Toolkit so that it should feel as comfortable to use as UGUI and GameObjects. 
There’s also all the very black magic going on around RectTransform being a subclass of Transform. Users can’t introduce subclasses of Transform, so in order to support a community version when ugui’s gone, you’d either have to let the RectTransform vestige stay in the engine, or reimplement RectTransform as an additional component next to Transforms.
Or… something. RectTransform is a really cool system which has some broken beyond repair problems, so I don’t mind it going away.
Considering the Unity 6 docs still recommend uGUI for runtime use, lets not talk deprecation yet…
I’m not concerned about adopting UI Toolkit when it eventually mature, but rather about the pathway of older projects being able to move up to higher Unity versions in the future. It could be very, very far away in the future, but it’s a hanging sword nonetheless.
I hope it’s never. unity was always about leveraging creativity, not about learning a new networking, rendering, ui module every 4-5 years.
because this constant push to make people accept a potential deprecation of ugui feels wrong on many levels, it just doesn’t add up, assuming you guys want Unity to improve
imgui was obviously like the assembler language of UI, but ugui solved that. uitk would not be the same order of magnitude better than ugui like ugui was compared to imgui, at least not without significant resources (which I’m sure could be redirected to more pressing issues).
I really hope at the very least you allocate more resources to make them interop and keep them in synergy rather than being adversaries – because let’s face it, the departure from the game objects as UI paradigm was never a good idea. game objects are the “shoulders of giants” ugui stands on and you dared to think you can create better “shoulders” instead of perhaps just an extension of ugui (I don’t say it’s easy, just that it’s a more natural step than “yet another UI lib rewrite”)
I’m open to do a twitter space where anyone can join and we approach 10-20 points around this issue. you know, see what real users of Unity say, not what the Unity team thinks we need. maybe I’m wrong, and I’m open to learn
Me too. If UI Toolkit wants to replace UGUI, it needs a beginner friendly interface, drag drop to assign reference to an UI item, inspector value… not complicated coding and concept. I don’t see what’s wrong with making UI using Prefabs and Game Object hierarchy, making UI in a special UI Builder window is too different from Unity Game Object system.