Очень сложно представить неприменимую архитектуру. Применимы все, но вопрос стоит в том, насколько "чисто" получится им следовать. Насколько много адаптеров прийдется надстраивать.. Мы обязательно продолжим опыт сравнения и добавим Clean Architecture в репу позже.
Не будем, но это остается потенциально возможно. У enum без cases не будет инициализатора даже на internal уровне, что на 100% исключит вероятность его использования.
В первую очередь вдохновлялись опытом других. Например, SwiftGen уже упоминал, но даже Apple в Combine тоже предпочли enum - Subscriptions, Publishers
Если речь про `enum Facade` и его вложенные enum это устоявшаяся практика для группировки статических переменных и функций. Этот подход применяется например в SwiftGen для доступа к ресурсам. В отличие от структуры enum не содержит дефолтного инициализатора и других лишних функций, которые могут привести к нецелевому использованию сущности. Вложенные enum позволяют формировать хорошо читаемые пути до функций: Facade.Storages.User.current, что удобнее просто длинного имени. Автодополнение в IDE быстрее подбирает нужный вариант такого пути.
Для новых проектов мы обычно поддерживаем 2 предыдущие версии iOS. Сейчас актуальная версия 18я, поэтому уже можно. С проектами в продакшене всё индивидуально, не всегда получается уговорить заказчика отрезать поддержку устаревших версий, но в общем случае это возможно.
Пробовали как-то.. Это было актуально еще со старой системой сборки (Xcode Legacy Build System) Плагин `cocoapods-binary` действительно помогал уменьшить время инкрементальной сборки. Однако не с каждым подом это срабатывало. Приходилось настраивать индивидуально. С новой системой сборки проблема не так жестко стоит как раньше.
Если вы прочитали статью дальше заголовка, то можете понять что аккаунты есть у всех, но мы против того чтобы они создавали персональные сертификаты, потому что это приводит к проблемам описанным в статье.. Что касается оплаты - платим за всех, естественно.
Очень сложно представить неприменимую архитектуру. Применимы все, но вопрос стоит в том, насколько "чисто" получится им следовать. Насколько много адаптеров прийдется надстраивать..
Мы обязательно продолжим опыт сравнения и добавим Clean Architecture в репу позже.
Не будем, но это остается потенциально возможно. У enum без cases не будет инициализатора даже на internal уровне, что на 100% исключит вероятность его использования.
В первую очередь вдохновлялись опытом других.
Например, SwiftGen уже упоминал, но даже Apple в Combine тоже предпочли enum - Subscriptions, Publishers
Если речь про `enum Facade` и его вложенные
enumэто устоявшаяся практика для группировки статических переменных и функций.Этот подход применяется например в SwiftGen для доступа к ресурсам.
В отличие от структуры enum не содержит дефолтного инициализатора и других лишних функций, которые могут привести к нецелевому использованию сущности.
Вложенные enum позволяют формировать хорошо читаемые пути до функций: Facade.Storages.User.current, что удобнее просто длинного имени. Автодополнение в IDE быстрее подбирает нужный вариант такого пути.
Для новых проектов мы обычно поддерживаем 2 предыдущие версии iOS. Сейчас актуальная версия 18я, поэтому уже можно.
С проектами в продакшене всё индивидуально, не всегда получается уговорить заказчика отрезать поддержку устаревших версий, но в общем случае это возможно.
Спасибо за предложение.
Мы планировали продолжить сравнение архитектур. Это только начало.
Swift Macros меня лично больше всего впечатлил)
Уже установил бету Xcode 15 чтобы пощупать их.
Спасибо за обзор
Можно и так сказать.
Пробовали как-то..
Это было актуально еще со старой системой сборки (Xcode Legacy Build System)
Плагин `cocoapods-binary` действительно помогал уменьшить время инкрементальной сборки.
Однако не с каждым подом это срабатывало. Приходилось настраивать индивидуально.
С новой системой сборки проблема не так жестко стоит как раньше.
Если вы прочитали статью дальше заголовка, то можете понять что аккаунты есть у всех, но мы против того чтобы они создавали персональные сертификаты, потому что это приводит к проблемам описанным в статье..
Что касается оплаты - платим за всех, естественно.