У нормального, вовлеченного в работу текущего проекта разработчика нет свободного времени, чтобы мотаться по каким-то там митапам.
Бросьте, часто все действительно все иначе. Кто тогда все эти разработчики, которые доходят до конференций?) Если за весь год не получается пару раз оставить проект на 1-2 дня, то звучит так, что с процессами явно что-то не так.
Лично не сторонник сторибордов: предпочитаю xib, но исходя из контекста кажется, что вы имеете в виду "верстку в Storyboard и Xib" против "верстки в коде", по названию же кажется что речь исключительно про Storyboard.
Вынужден не согласиться с некоторыми вашими утверждениями:
Если стоит задача создать сложный экран с анимацией и эффектами, с которыми Storyboard не справится, то нужно использовать код!
Очень категорично сказано. На мой взгляд это зависит от ситуации. Вам ведь ничего не мешает декомпозировать экран, верстая и реализуя составные части в отдельных нибах или в коде.
Storyboards мешают повторному использованию кода
Ниже вы сами же верно пишете про декомпозицию экрана на xib'ы, что решает проблему. Почему же тогда это мешает повторному использованию?
Нельзя использовать кастомные инициализаторы для UIViewControllers, созданных в Storyboard
Вы правы. Но с iOS13 это возможно.
Тяжело править конфликты.
Под капотом там действительно XML, и если разработчики работают в двух разных экранах — конфликтов возникнуть не должно. Если же они работают над одним — конфликты появятся и в xib файле. Вы правы, если сравнение идет в отношении верстки в коде и storyboard, но не соглашусь если речь про xib и storyboard
При этом аргументы могут быть совершенно разного типа. Например в VSack мы можем положить TextField, Toggle и что-нибудь еще вместе. И я думаю под капотом недостаточно знать, что аргумент под протоколом View — важно знать конкретный тип каждого аргумента.
Бросьте, часто все действительно все иначе. Кто тогда все эти разработчики, которые доходят до конференций?) Если за весь год не получается пару раз оставить проект на 1-2 дня, то звучит так, что с процессами явно что-то не так.
Лично не сторонник сторибордов: предпочитаю xib, но исходя из контекста кажется, что вы имеете в виду "верстку в Storyboard и Xib" против "верстки в коде", по названию же кажется что речь исключительно про Storyboard.
Вынужден не согласиться с некоторыми вашими утверждениями:
Очень категорично сказано. На мой взгляд это зависит от ситуации. Вам ведь ничего не мешает декомпозировать экран, верстая и реализуя составные части в отдельных нибах или в коде.
Ниже вы сами же верно пишете про декомпозицию экрана на xib'ы, что решает проблему. Почему же тогда это мешает повторному использованию?
Вы правы. Но с iOS13 это возможно.
Под капотом там действительно XML, и если разработчики работают в двух разных экранах — конфликтов возникнуть не должно. Если же они работают над одним — конфликты появятся и в xib файле. Вы правы, если сравнение идет в отношении верстки в коде и storyboard, но не соглашусь если речь про xib и storyboard
Текущий ViewBuilder принимает на вход generic аргументы, с одним ограничением: каждый из них должен реализовывать протокол
View.При этом аргументы могут быть совершенно разного типа. Например в VSack мы можем положить TextField, Toggle и что-нибудь еще вместе. И я думаю под капотом недостаточно знать, что аргумент под протоколом View — важно знать конкретный тип каждого аргумента.