Ручная верстка vs Storyboard/Nib

Большинство разработчиков для iOS знакомы со Storyboard. Apple предлагает использовать его. Но в последнее время, удобство этого инструмента вызывает у меня сомнения.

Ниже я хочу сравнить различные методологии с использованием Storyboard или набора Xib-фалов, с ручной верстой (с использованием autolayout и без). Не претендую на полноту раскрытия темы и буду рад, если вы укажете мне на ошибки и/или предложите другие методологии и критерии сравнения.

Пост не содержит экспериментов, академических вычислений и основывается на моих знаниях и опыте в области iOS разработки. Был бы рад узнать мнения экспертов!

С теми или иными оговорками, существуют следующие методологии разработки:

• Один Storyboard и все в нем (минимум кода верстки в коде) — используется в небольших проектах; очень неудобен при разработке командой разработчиков.
• Несколько Storyobard-ов и все в них.
• Забываем про Storybaord, все UI-контролы помещаем в xib-файлы (см. этот пост).
• Забываем про Storyboard и Xib, но используем autolayout — привет PureLayouts.
• Забываем про все Storyboard/Xib/AutoLayouts и настраиваем всем View фреймы в ручную.
• Забываем про UIKit — используем сторонние решения AsyncDisplayKit от Facebook или ComponentsKit. (Такого опыта у меня нет, поэтому ничего путного не скажу).

Storyboard и Xib

Проблемы:

1. Большую часть кода, связанного с анимациями туда не поместить.
2. Если их несколько, то при переходе с одного на другой — создается нагрузка на main thread (NSKeyedArchiver должен распарсить сториборду, а он сам по себе медленный).
3. Нельзя все сделать в Storybaord при все желании. Например, задать cornerRadius, shadowOffset и т.д.; на самом деле, можно — через user defined runtime attributes (@IBInspectable)

Плюсы:

1. Верстка наглядна.
2. User-story виден при просмотре.
3. SizeClasses
4. Используем Embedded Segue/Storyboard Reference и живем счастливо
5. Мы абстрагируемся от типа перехода и для осуществления самого перехода достаточно знать segue identifier (см. RamblerSegues), также, при использовании автоматических dependency injection библиотек (см. typhoon), мы абстрагируемся от внедрения зависимостей.

Ручная верстка с использованием Autolayout-ов

Использовал различные тулы, наиболее, удобные — PureLayout и Cartography (для swift).

Проблемы:

1. Больше кода (приблизительно в 1.2 раза).
2. Нет наглядности
3. Сложный layout превращается в ад

Плюсы:

1. Немного быстрей — экономим на парсинге Xib/Storyboard файла NSKyedArchiver-ом.
2. Декларативно и все в одном месте (не нужно постоянно переключаться между Storyboard и текстом).
3. Удобней делать анимации (например, pan).

Ручная верстка

Проблемы:

1. При неправильной реализации — есть hardcoded-значения (при правильной, только padding-и и прочее; причем это можно вынести в отдельных header).
2. Больше кода (приблизительно в 1.5 раза).
3. Нет наглядности
4. Сами нужно заботиться об адекватном изменении frame-а при изменении параметров внешней view
5. Нет SizeClasses

Плюсы:

1. При правильной реализации все очень гибко.
2. Работает быстрей.
3. Можно рассчитать фреймы в background-потоке и просто их потом применить.

Итог

При отказе от каждого из [Stobyboard, Xib, Autolayout] работа усложняется и кода становится больше.

Имеет смысл не использовать Storyboard (не обязательно полностью), если:

• Делаем сложные анимации (отпадает необходимость кидать кучу outlet-ов).
• Время восстановления из архива становится критичным.
• Возникает много костылей (обычно, большая их часть устраняется правильной архитектурой и/или method swizzling-ом).

Имеет смысл, требовательные к ресурсам TableView/CollectionView не делать ни в Storyboard, ни в Xib (мы теряем время на парсинге файла, теряем гибкость). При оптимизации, можно сначала сверстать с использованием autolayouts, но если лаги не проходят — замерить в инструментах, убедиться, что именно layout-ы тормозят, и потом уже переходить на ручной счет.

Иногда, похожее содержимое необходимо отображать как в TableViewCell так и в CollectionViewCell. При ручной верстке это не будет проблемой. А при использовании Xib-а решается, например, так: содержимое ячейки верстаем в xib-файле, а в init-е ячейки вызывать addSubview с данным view.

EDIT:

Подводя итог, можно сказать, что Storyboard имеет следующие преимущества перед ручной версткой:

• Наглядность (верстка в коде, зачастую, «понятна» только ее автору — см. комментарий DmitrySpb79).
• Использование нескольких Storyboard позволяет разделить различные user-story и уменьшает вероятность конфликтов при командной разработке.
• При необходимости использовать в одном из сторибордов конроллер, из другого сториборда — с версии iOS 8 можем использовать Storyboard Reference и этот комментарий от visput; если нужно поддерживать iOS версий < 8, то можно использовать Xib-ы, либо самим как-то реализовать аналог Storyboard Reference

Ручную верстку используем там, где это необходимо, а на фреймы переходим — если autolayout становится узким местом (см. комментарий mish).