Your Registration class in example 2 is what most people would probably implement as RegistrationViewModel. I'm not 100% with you on the "all ViewModels must die" train yet, but I do agree it's completely useless in a lot of scenarios. I started thinking about it a bit more and in my current project I just deleted/refactored a whole bunch of files because of this, because I realised they didn't bring anything to the table except for boilerplate code.

Something I also didn't see: this is great for creating new objects, but what about editing an existing one? How do you get the values of your model in the @State properties you are editing? You can't do that in an initializer, and the defaults are constants. Am I correct in stating that this will only work using an ObservableObject and Published properties which contain the initial values? I see no way of setting the @State properties to the current values in my model.

Isn't it weird that even in developer mode we have this issue, effectively blocking our development work? I don't think it's abnormal to send a lot of test pushes to a simulator or device while developing our apps? I just had exactly the same on an iOS simulator: default 10:36:56.073801+0100 liveactivitiesd Topic *.liveactivity is out of budget because pushToStart is exhausted

What "live activity process" would that be? Can we set a breakpoint somewhere to see where this happens?