Как организована сборка приложения
Что проверяют
Хотят понять, видели ли вы путь от коммита до TestFlight своими глазами или сборкой «занимался другой человек». Обычно смотрят на подпись, окружения и автоматизацию, а следом спрашивают, как вы ускоряли сборку или чинили упавшую подпись на CI. Этот же вопрос полезно задать работодателю: ответ многое говорит о зрелости команды.
Как отвечать
Расскажите о своём проекте по слоям, с конкретными именами и цифрами:
- структура: таргеты (приложение, расширения, тесты), схемы, конфигурации Debug и Release. Настройки удобно выносить в
.xcconfig, а не держать вproject.pbxproj, где они теряются в конфликтах слияния. Tuist или XcodeGen генерируют проект из описания и снимают эту проблему; - окружения: dev, stage и prod как отдельные конфигурации со своими bundle ID, иконками и адресами API, чтобы сборки ставились рядом;
- зависимости: Swift Package Manager и
Package.resolvedв репозитории. CocoaPods фактически в режиме поддержки, если он остался, скажите, как уходите с него; - подпись: сертификаты и provisioning profiles, автоматическая подпись локально и ручная на CI, общее хранение сертификатов через fastlane
match; - релиз:
xcodebuild archive, затем-exportArchiveсExportOptions.plist, либо fastlanebuild_appиupload_to_testflight. Номер сборкиCFBundleVersionрастёт автоматически, dSYM уходят в систему сбора крашей; - CI: Xcode Cloud или macOS-раннеры. На пул-реквест тесты, на релизную ветку выкладка в TestFlight.
Добавьте цифру про время сборки и что вы с ним сделали: разбили код на пакеты, включили кеш DerivedData, убрали тяжёлые скрипты из Build Phases.
Если CI настраивали не вы, так и скажите и опишите, какие части понимаете и как выпускали релиз руками.
Где спотыкаются
Отвечают «собираем кнопкой Archive в Xcode». Для команды это значит, что релиз зависит от одного ноутбука.
Не могут объяснить, чем сертификат отличается от provisioning profile, и теряются на вопросе о падении подписи на CI.
Держат ключи API прямо в Info.plist или в коде репозитория, а не в секретах CI.