Remember when I wrote about MVVM and eventually in 2015 produced this:

I learned that the “view model” in the architectural style of MVVM is a “model of the view” instead of a “model for the view”. Let me explain the difference and the benefits of being able to chose between both.

From a language perspective, I was terribly confused about this for a while. How come nobody says if their VM of MVVM is a model of the view, i.e. modeling it, or a model for the view, which better be called “view data” (Part 1 and Part 2 of Joe Fabsevich’s posts making that point).

Coming back to a use of view models in SwiftUI samples, the following hypothesis is stuck in my mind:

SwiftUI.View is actually a view model – a model of the view. It’s a blueprint for what to display, but doesn’t contain any actual pixel drawing.

All things considered, you end up with SwiftUI managing UIViews/NSViews for you at the moment. But that’s an implementation detail that may change. The point is that the “view” is not, in face, the view, but a description of it.

That’s why SwiftUI.View implementations have structural identity and such without being utterly, terribly confusing – because the map is not the territory, and you can navigate between neatly delienated map sectors just fine without expecting straight lines on the earth in front of you.

So, the SwiftUI.View is in some referential sense the view, while in another sense it isn’t. I’m being reminded of philosophy classes where we took great care to separate referents, e.g. the actual planet Venus itself, from its name, e.g. “the morning star”. Check out Frege’s puzzles if you’re into that. But understanding that likely won’t help grasp the implications here, so it’s a purely optional ‘side quest’.

If the SwiftUI.View is a representation aka a model of the view (that is to be drawn by UIKit/AppKit/…), it doesn’t make sense to nest another level of “view model” inside. We ought to be talking about different concepts on other levels of abstraction.