Этот пост является вольным переводом статьи Xcode: A Better Way to Deal with Storyboards by Stan Ostrovskiy Некоторые примеры кода в оригинальной статье устарели (ввиду выхода Swift 3) и в переводе были изменены. Советы и рекомендации по работе с Interface Builder. Apple серьезно улучшили Interface Builder в новом Xcode 8. Использование size classes стало более интуитивным, возможность масштабирования сториборда — очень удобной, а полное превью прям в Interface Builder — просто великолепным. Для тех у кого были сомнения насчет использования Interface Builder, это может стать хорошими плюсами. С другой стороны, у многих разработчиков все еще есть некоторые проблемы с Interface Builder когда они создают большие многоэкранные приложения со сложной навигацией. В этой статье я поделюсь некоторыми из лучших практик для работы со сторибордами в вашем проекте. Вы уже пользуетесь Interface Builder, или только делаете первые шаги в этом направлении? — в любом случае, эти советы будут полезны для вас. В вашем проекте есть один файл main.storyboard, который выглядит вот так? Но для разработчика это несет множество проблем: Как же связать различные сториборды в вашем проекте? Есть два способа. Используйте ссылки на сториборды (storyboard referencing), которые появились в Xcode 7. О первом способе вы можете почитать детальнее здесь. Я расскажу о втором способе, так как он широко используется для сложных проектов. Это упростит правила именования, а также даст некоторые "плюшки" о которых поговорим в пункте 3. Когда дело доходит до инициализации вью-контроллера через сториборд, я часто вижу следующий код: Немного "грязновато": вам нужно назвать сториборд, вам нужен storyboard ID вью-контроллера, и вам необходимо использовать этот паттерн каждый раз, когда вы создаете HomeViewController. Лучше перенести этот код в сам класс контроллера и использовать статический метод, чтоб инициализировать контроллер с помощью сториборда: Если вы последуете предыдущему совету (одинаковые имена файлов), то можете избежать "харкода" имени сториборда и воспользоваться String(describing:): Это делает ваш код более читаемым и отказоустойчивым: Теперь, инициализация такого вью-контроллера займет одну строку: Просто и понятно, не так ли? Вы можете использовать этот же подход для инициализации вью из nib: У вас не будет переходов, если вы последуете совету из пункта 1. Но даже если у вас есть несколько вью-контроллеров в одном сториборде, использование переходов (segues) для навигации между ними — не очень хорошая идея: Какова альтернатива? Когда вы хотите перейти к следующему вью-контроллеру по нажатию на кнопку, просто добавьте IBAction для этой кнопки и инициализируйте вью-контроллер в коде: это ведь всего одна строка, как вы помните из пункта 3. Иногда навигация предполагает возврат пользователя к предыдущему экрану. Начиная с iOS 7, Interface Builder дает вам возможность сделать "unwind" навигационного стэка. Unwind segue позволяет вам указать возврат на предыдущий экран. Это звучит довольно просто, но на практике это требует некоторых дополнительных действий и только сбивает с толку разработчика: Каков же более простой способ? Проще делать это в коде: вместо создания действия "unwind" для вашей кнопки, создайте обычный IBAction и используйте dismissViewController или popViewController (в зависимости от вашей навигации): На сегодня это все. Я надеюсь, вы найдете что-то полезное для себя. Благодаря методу описанному в этой статье, я очень сильно упростил работу со сторибордами в своем текущем проекте. Пока я работал над ним один — все было прекрасно, но как только появились другие разработчики — работа со сторибордом превратилась в настоящий ад. От отчаянья мы практически перешли к "банановому методу" (можно почитать здесь в разделе "Pass the banana"). Конечно же, в идеале нужно будет рано или поздно прийти к VIPER. Но об этом будет уже другой пост. Software Engineer