Спасибо за статью, такой информации мало. Есть пара ошибок. initialFrame в методе animateDismissTransition не используется вообще. Ну и по мелочи, в блоках нет обертки [unowned/weak self], очепяток в showLoginScreen() — там лишняя квадратная скобка закрывающая, также не очень понятно, как «стандартная» реализация вставки нового контроллера из 9 шагов должна превратиться в анимированный переход, неплохо бы привести этот пример в статье. В остальном нормально, лишней статья точно не будет.
а что будет — если экранов станет больше 10 хотя бы, и если будут использоваться разные сценарии — длинный кейс авторизации, кейс редактирования, кейс оплаты?
RootController распухнет до тысяч строк, а еще и синглтон — как менять реализацию на лету например?
И по итогу каждый VC знает, куда ему шагать дальше, а если необходимо в N-ое количество VC заменить вызываемый экран (корзину -> на оплату)?
Проблемы есть в любом подходе, к сожалению. По поводу множества экранов — основным распухающим контроллером тогда будет Main, так как суть рута — это переброска между авторизацией, сплешем и основным Main экраном. Кейсы (пошаговые flow) я обычно выделяю в отдельный контроллер, чтобы не плодить разную логику в корне, но там под ситуацию уже подбирать надо.
Длинные кейсы рулятся уже внутри, для этого в рутовом контроллере вместо непосредственно контроллеров логина/главного добавляют, например, UINavigationController, в который уже и «навигирует».
Координация в таких случаях осуществляется, например, при помощи координаторов. Никаких тысяч строк тут нет.
Организация навигации в iOS-приложениях с помощью Root Controller