Не было необходимости делать доп приседания со сборкой всего в динамике в дебаге с учетом того, что время компиляции у нас не изменилось (на уровне погрешности)
Всегда статика для всех конфигураций. Проблем с брейкпоинтами не наблюдается ни у кого, вероятно из-за того, что 95% таргетов конфигурируется через spm.
Есть вероятность, что проблемы с бряками могут появиться, если таргеты конфигурировать через Xcode. Например, заметил, что если статический фреймворк создан в Xcode, а не Package.swift, то не работает код с objc рантаймом, например, свизлинг (соответственно и бряки не вызываются). Однако это лечится простановкой OTHER_LDFLAGS = -force_load static_framework_path
Да. То есть, если разобрать на примере, то будет так.
Пакет A создаёт продукт и таргет для него. В этом таргете указываются какие-то unsafeFlags, например -ObjC флаг.
Если Пакету B нужно будет использовать пакет А как зависимость, то сделать это он сможет только, если будет забирать зависимость A по названию ветки либо по коммиту. В ином случае на этапе резолвинга зависимости появится ошибка.
Когда зависимость скачивается по коммиту или ветке считается, что данная зависимость еще в режиме разработки и можно прикрыть глаза на безопасность)
Тоже сталкивался с подобным, когда пытался как раз таки решить проблему дублирования статического таргета в апке и в экстеншене и перевод на динамику не дал результатов из-за этого. Оставил решение проблемы на будущее :)
Не очень понял почему unsafeFlags нельзя в публичных пакетах, мало ли какие мне обязательные флажки для пакета надо задать. Можно ссылку?
В статье есть ссылка, на всякий случай вот. unsafeFlags можно использовать, но с описанными ограничениями.
Поды тоже так могут, там надо одну настройку в Podfile прописать:
Факт. Статическую линковку мы, по сути, получили бонусом. Основная цель переезда была не в этом, а в отказе от подсов как таковых и для того, чтобы безболезненно поддерживать в актуальном состоянии внешние зависимости и для того, чтобы уходить от использования ruby локально и на ci/cd
Не было необходимости делать доп приседания со сборкой всего в динамике в дебаге с учетом того, что время компиляции у нас не изменилось (на уровне погрешности)
Всегда статика для всех конфигураций. Проблем с брейкпоинтами не наблюдается ни у кого, вероятно из-за того, что 95% таргетов конфигурируется через spm.
Есть вероятность, что проблемы с бряками могут появиться, если таргеты конфигурировать через Xcode. Например, заметил, что если статический фреймворк создан в Xcode, а не Package.swift, то не работает код с objc рантаймом, например, свизлинг (соответственно и бряки не вызываются). Однако это лечится простановкой OTHER_LDFLAGS = -force_load static_framework_path
Просто приятный сайд эффект про который тоже рассказали)
Какие-то зависимости действительно перетащили себе. Какие-то в процессе переезда наоборот удалили, забрав из них буквально пару десятков строк.
Но какой-нибудь RxSwift так не заберешь, или TCA)
Да. То есть, если разобрать на примере, то будет так.
Пакет A создаёт продукт и таргет для него. В этом таргете указываются какие-то
unsafeFlags, например-ObjCфлаг.Если Пакету B нужно будет использовать пакет А как зависимость, то сделать это он сможет только, если будет забирать зависимость A по названию ветки либо по коммиту. В ином случае на этапе резолвинга зависимости появится ошибка.
Когда зависимость скачивается по коммиту или ветке считается, что данная зависимость еще в режиме разработки и можно прикрыть глаза на безопасность)
Тоже сталкивался с подобным, когда пытался как раз таки решить проблему дублирования статического таргета в апке и в экстеншене и перевод на динамику не дал результатов из-за этого. Оставил решение проблемы на будущее :)
В статье есть ссылка, на всякий случай вот.
unsafeFlagsможно использовать, но с описанными ограничениями.Факт. Статическую линковку мы, по сути, получили бонусом. Основная цель переезда была не в этом, а в отказе от подсов как таковых и для того, чтобы безболезненно поддерживать в актуальном состоянии внешние зависимости и для того, чтобы уходить от использования ruby локально и на ci/cd
Ого. По пункту 1 интересно. Исправили ли они это в релизной версии. Я смотрю в apple сами удивились такому поведению 😁
Думаю с 1к таргетов Xcode будет совсем тяжело жить (запускаться, удалять/переименовывать/добавлять файлы).
Сейчас мы постепенно идем в сторону генерации проекта через Tuist. В этом случае многие проблемы с SPM отпадают.