SwiftUI. Есть ли жизнь без NavigationView или пару слов о координаторе

[NineNineOne]

Привет!

Интересная статья.

Вопрос 1: почему завернул containered в массив?

self.stack += [containered]

Вопрос 2: при описанном подходе мы отказываемся от стандартных анимаций переходов между экранами (и от модальных презентаций), а значит должны реализовать кастомные, верно?

Если да, то не слишком много будет работы с повторением стандартных анимаций и исправлением багов, особенно учитывая годы костылей на UIKit у любителей понаделать кастомные tab/nav-бары?

Я работал с UIKit 3 года, но повидал много таких костылей (сам не грешил).

Бонус: предлагаю заменить @ObservedObject на @StateObject внутри struct ContentView, потому что не рекомендовано использовать @ObservedObject для хранения состояния вьюшки в SwiftUI, для этого предназначен @StateObject, цитата:

SwiftUI might create or recreate a view at any time, so it’s important that initializing a view with a given set of inputs always results in the same view. As a result, it’s unsafe to create an observed object inside a view. Instead, SwiftUI provides the StateObject attribute for this purpose

[Demtriy]

Вопрос 1: почему завернул containered в массив?

Не уверен, что понял вопрос. Массив - потому что нужно было реализовать функциональность стека. Так как коллекция "стек" в Swift отсутствует, то проще всего было использовать именно массив. В целом - это можно делать по-разному.
Если вопрос касался ContainerView, то потому, для инициализации массива мы не можем использовать View или some View.

Вопрос 2: при описанном подходе мы отказываемся от стандартных анимаций переходов между экранами (и от модальных презентаций), а значит должны реализовать кастомные, верно?

Точно такую анимацию как это делается при использовании UINavigationViewController в UIKIt сделать не получается. Но достаточно добавить   .transition(.move(edge: .trailing)) к "навигационному вью" и .transition(.move(edge: .bottom)) - для модального окна - чтоб получить схожее поведение.

Бонус: предлагаю заменить @ObservedObject на @StateObject внутри struct ContentView, ...

Согласен. Для данного примера @StateObject подходит лучше.