Ниже вы сами же верно пишете про декомпозицию экрана на xib'ы, что решает проблему. Почему же тогда это мешает повторному использованию?
Как вы могли заметить, в итоге из 10 недостатков я вынес лишь 4. Но вы правы, из статьи это может быть не совсем понятно. Внес правку в тексте перед разделом о недостатках.
Вы правы. Но с iOS13 это возможно.
Пока необходима поддержка более старых версий, эта проблема все же сохраняет актуальность.
Вы правы, если сравнение идет в отношении верстки в коде и storyboard, но не соглашусь если речь про xib и storyboard
Неприятные конфликты могут иметь место и в xib-файлах, на мой взгляд. Зависит от его размера. В коде их править гораздо удобнее, чем в xml-файле.
Все указанные преимущества (в финальной таблице) относятся и к xib'ам. Так какой смысл использовать сториборды?
Xibs — замечательный инструмент, без которого лично я не представляю использование Storyboards. Storyboards мне нравятся тем, что они расширяют возможности Xibs. Иногда полезно объединить 2-3 экрана в одном месте и настроить между ними простую навигацию. Может быть, добавив еще storyboard reference на другой похожий модуль. Также Storyboards позволяют более гибко работать с таблицами, особенно когда речь идет о статических.
В конце концов, все зависит от конкретной ситуации: в каких-то удобно использовать Storyboard, а в каких-то можно ограничиться лишь Xib.
Так же хотел бы отметить, что работать с trait variations можно и в коде. Так что в целом это не является преимуществом сторибордов.
Безусловно, с trait variations можно взаимодействовать и в коде. Однако я посчитал необходимым включить size classes в список преимуществ Storyboards, так как Interface Builder упрощает с ними работу за счет предварительного просмотра любого size class и функции Vary for Traits.
Справедливости ради, стоит упомянуть, что ошибка в xib-файле с IBAction или Outlet тоже может привести к падению.
Конечно, если рассматривать недостатки Xib-файлов, то некоторые перечисленные здесь будут применимы и к ним.
Разве это не приведёт к ошибке уже на этапе компиляции?
Нет, Xcode только выдаст предупреждение. На самом деле, не менее распространенным случаем является несоответствие имени класса UIView в коде и в Storyboard. Тогда Xcode вообще молчит, и приложение может упасть, например, при вызове несуществующего метода.
Как вы могли заметить, в итоге из 10 недостатков я вынес лишь 4. Но вы правы, из статьи это может быть не совсем понятно. Внес правку в тексте перед разделом о недостатках.
Пока необходима поддержка более старых версий, эта проблема все же сохраняет актуальность.
Неприятные конфликты могут иметь место и в xib-файлах, на мой взгляд. Зависит от его размера. В коде их править гораздо удобнее, чем в xml-файле.
Xibs — замечательный инструмент, без которого лично я не представляю использование Storyboards. Storyboards мне нравятся тем, что они расширяют возможности Xibs. Иногда полезно объединить 2-3 экрана в одном месте и настроить между ними простую навигацию. Может быть, добавив еще storyboard reference на другой похожий модуль. Также Storyboards позволяют более гибко работать с таблицами, особенно когда речь идет о статических.
В конце концов, все зависит от конкретной ситуации: в каких-то удобно использовать Storyboard, а в каких-то можно ограничиться лишь Xib.
Безусловно, с trait variations можно взаимодействовать и в коде. Однако я посчитал необходимым включить size classes в список преимуществ Storyboards, так как Interface Builder упрощает с ними работу за счет предварительного просмотра любого size class и функции Vary for Traits.
Конечно, если рассматривать недостатки Xib-файлов, то некоторые перечисленные здесь будут применимы и к ним.
Нет, Xcode только выдаст предупреждение. На самом деле, не менее распространенным случаем является несоответствие имени класса UIView в коде и в Storyboard. Тогда Xcode вообще молчит, и приложение может упасть, например, при вызове несуществующего метода.