Some thoughts…

“It would lead to nested coding blocks and declarations….”

Not really. If you’re doing a lot of nesting of Views then you’re probably ignoring another one of SwiftUI’s core tenets: Composition.

SwiftUI strongly encourages breaking complex Views into smaller, easily composed and — more to the point — easily understand and testable components.

“SwiftUI is basically a different way to set Auto Layout-like constraints, it’s not a separate tool or a separate technology…”

From talks given by Apple engineers, SwiftUI uses a new rendering, layout, and diffing system that manages “Views” internally. It’s not a UIView/Autolayout builder. (From a technical standpoint, it actually seems to be more of a layer/Metal engine…)

“SwiftUI is basically conceived to design a single view.”

I know what you mean here, in that you don’t have a storyboard that shows all of your views and the interconnections between them. That said, modern iOS development tends to avoid that approach for large projects and teams anyway, as multiple people making changes to a single storyboard tends to devolve into a merge-request nightmare.

All in all, a good article.