System.Windows.Forms works in the same way (the UI is serialized to code). WPF was designed many years after that because it allows different disciplines to work together.
Designers would most likely be familiar with XML given their HTML background, but they wouldn't necessarily know C#.
If Swift UI expresses the full fidelity of the API in the designer (e.g. expressing custom states and animations, keyframes, etc. on a custom button), then my point doesn't apply. If the full range of designer responsibilities cannot be achieved without dropping into code, then Swift UI isn't a real counterexample.
> Designers would most likely be familiar with XML given their HTML background, but they wouldn't necessarily know C#.
I am really curious how often XAML has been used by a designer who didn't know C#. Most of the XAML I've seen (in non-trivial apps) has a lot of code-like constructs in it. If you don't know what's going on under the hood, how are going to correctly declare your data bindings (for example)?
> Most of the XAML I've seen (in non-trivial apps) has a lot of code-like constructs in it.
Those code-like constructs are UI behavior (e.g. how to transition from checked to unchecked for a checkbox). While they do take learning, they are not strictly code.
Also, Expression Blend can interact with every part of XAML in full-fidelity. Designers need not worry about the code-like parts of XAML at all.
> If you don't know what's going on under the hood
I suppose the workflow is that the design team would log a ticket for the development team, who would expose said binding and add it to the UI as a placeholder. I'm not sure exactly how this is supposed to work, but Microsoft did have a project which combined Unity and WPF to solve this exact workflow (I forget the name), and they were using it internally.
---
Personally, I can see the benefit as I do work at a product company. Developers get bugs pretty often to do with "element X is 1 pixel off," usually from the design team (one designer was known to open screenshots in paint to measure distances). If you can empower the designers to just create real UIs instead of mockups, it would get done correctly in the first place. Vue SFCs come close to achieving this, but fall short in terms of state (you still need JS to add/remove CSS classes).
Either way, it isn't fair to compare Swift UI to XAML as Swift UI doesn't seem to attempt to solve this at all (even if XAML doesn't solve it perfectly). Swift UI is closer to System.Windows.Forms.
