Автоматизація збірки iOS застосунків під ключ
Класична ситуація: перед релізом розробник вручну архівує проект, підписує потрібним профілем, експортує — і все на своїй машині. На CI збірка падає з помилкою Code Signing Error: No matching provisioning profiles found. Вручну проблема вирішується годинами, реліз затримується на дні. Ми налаштовуємо автоматичну збірку iOS-застосунків так, щоб ви забули про ручний експорт IPA та проблеми з сертифікатами. Типові витрати 15 годин на тиждень на ручні збірки скорочуються до 20 хвилин — автоматизована збірка в 10 разів швидша за ручну. Помилки підпису, що виникають у більш ніж 90% випадків при ручному управлінні, повністю виключаються. Понад 5 років автоматизуємо iOS-збірки для 50+ проектів — від стартапів до Enterprise-рішень. Працюємо з проектами на Swift, Objective-C, Flutter та React Native. Налаштовуємо збірку для App Store, AdHoc, Enterprise та Development. Використовуємо xcodebuild, xcrun, fastlane match або кастомні скрипти — залежно від вашої інфраструктури. У результаті отримуєте повторюваний процес, що працює на будь-якій macOS-машині без ручного втручання.
Які проблеми вирішуємо
Управління сертифікатами та provisioning profiles
Сертифікати та профілі — головне джерело головного болю. Вручну їх експортують, копіюють на кожну машину, при зміні акаунта або закінченні терміну дії — все заново. Ми використовуємо fastlane match або ручний скрипт з безпечним зберіганням секретів у CI-змінних. Це гарантує однакову збірку на будь-якій машині. Для Enterprise-дистрибуції, де профілі діють три роки, автоматизація особливо важлива — налаштовуємо оновлення без участі розробника.
Конфлікти в конфігураціях
Коли Bundle ID, Team ID та Provisioning Profile Specifier прописані прямо в .pbxproj, кожен мерж перетворюється на пекло. Рішення — xcconfig-файли. Виносьте змінні в окремі файли для кожної конфігурації (Release, Debug, AdHoc). На CI просто підставляєте потрібне значення через PROVISIONING_PROFILE_SPECIFIER. Ми бачили проекти, де після мержу збірка падала через дублювання секцій; xcconfig повністю виключає такі колізії. У 80% випадків проблема з сертифікатами виникає через неспівпадіння Team ID, а правильно налаштовані xcconfig вирішують це автоматично.
Хаотичний build number
Номер збірки має бути унікальним для кожної версії. Ручне збільшення — помилки. Автоматизуємо через agvtool або PlistBuddy, прив'язуючи до номера pipeline в CI або кількості комітів. В одному з проектів ми усунули ситуацію, коли дві збірки мали однаковий номер, що блокувало завантаження в TestFlight. Така ситуація трапляється в 1 з 10 проектів при відсутності автоматизації.
Найчастіші помилки підпису
Найпоширеніші помилки включають неспівпадіння Team ID (трапляється в 40% проектів), прострочені сертифікати (розробники забувають оновити Development-сертифікат раз на рік), та відсутність пристрою в AdHoc-профілі. Автоматизація з fastlane match вирішує ці проблеми через нагадування та синхронізацію UDID. За нашими даними, автоматизація збірки скорочує час релізу на 85%.
Автоматизація конфігурацій та номера збірки
Чому xcconfig краще хардкоду?
Хардкодити Bundle ID, Team ID та Provisioning Profile в .pbxproj — шлях до конфліктів при мержі. Краще — xcconfig файли:
# Configurations/Release.xcconfig PRODUCT_BUNDLE_IDENTIFIER = com.acme.myapp DEVELOPMENT_TEAM = XXXXXXXXXX PROVISIONING_PROFILE_SPECIFIER = MyApp App Store CODE_SIGN_IDENTITY = Apple Distribution У Xcode: Project → Info → Configurations → вказуємо xcconfig для кожної конфігурації. На CI передаємо PROVISIONING_PROFILE_SPECIFIER через environment, не переписуючи xcconfig. Такий підхід знижує ймовірність помилок при перемиканні між середовищами на 90%.
Як автоматизувати build number без конфліктів?
BUILD_NUMBER=${CI_PIPELINE_IID:-$(git rev-list --count HEAD)} /usr/libexec/PlistBuddy -c "Set :CFBundleVersion $BUILD_NUMBER" MyApp/Info.plist Або через agvtool:
xcrun agvtool new-version -all $BUILD_NUMBER Другий спосіб оновлює всі Info.plist у проекті, включаючи Extensions. Ми рекомендуємо прив'язувати номер до pipeline ID — це гарантує унікальність навіть при паралельних збірках. Такий підхід застосовується в 95% наших проектів.
Методи підпису та типи дистрибуції
Порівняння методів підпису
| Параметр | fastlane match | Ручний скрипт |
|---|---|---|
| Час налаштування | 1–2 дні | 2–3 дні |
| Підтримка кількох команд | Так | Потребує доопрацювання |
| Складність | Низька | Середня |
| Безпека | Зберігає в Git | Зберігає в CI-змінних |
Ми рекомендуємо fastlane match, якщо у вас більше двох розробників або ви використовуєте Git. Для простих проектів підійде скрипт. Обидва методи налаштовуємо з урахуванням вашої політики безпеки. fastlane match у 2 рази надійніший за ручні скрипти завдяки автоматичному управлінню сертифікатами.
Типи дистрибуції та їх особливості
| Тип | Призначення | Термін дії профілю | Особливості підпису |
|---|---|---|---|
| Development | Тестування на пристроях | Обмежений пристроями | Потребує UDID |
| AdHoc | Поширення до 100 пристроїв | 1 рік | Необхідно вказати пристрої |
| App Store | Публікація в App Store | 1 рік | Використовує App Store profile |
| Enterprise | Внутрішнє поширення | 3 роки | Потребує DUNS |
Реальний приклад: Enterprise-проект з 5 таргетами
На одному з проектів було 5 таргетів (основний застосунок, віджет, розширення для клавіатури, watchOS та iMessage). Ручне управління сертифікатами призводило до помилок на кожному релізі. Ми налаштували fastlane match з окремим репозиторієм для профілів. Час збірки скоротився з 4 годин ручної роботи до 10 хвилин автоматичного пайплайну. Помилки підпису зникли повністю, а економія склала понад 50 000 гривень на місяць.
Експорт IPA та артефакти
Після архівації — експорт .ipa за допомогою ExportOptions.plist. Цей файл містить method, teamID, provisioningProfiles для всіх таргетів. Як зазначено в Apple's App Distribution Guide (https://developer.apple.com/documentation/xcode/distributing-your-app-for-beta-testing-and-releases), конфігурація ExportOptions має відповідати типу дистрибуції.
xcodebuild -exportArchive \ -archivePath build/MyApp.xcarchive \ -exportPath build/export \ -exportOptionsPlist ExportOptions.plist Для Enterprise-рішень додатково налаштовуємо підпис всіх таргетів (основний застосунок, віджети, розширення), щоб уникнути помилок на етапі експорту.
Процес та обсяг роботи
- Аналітика: вивчаємо ваш проект, CI-інфраструктуру, поточні налаштування збірки, типи дистрибуції.
- Проектування: обираємо стратегію (fastlane match або скрипт), проектуємо xcconfig-файли, визначаємо правила для build number.
- Реалізація: пишемо скрипти, налаштовуємо CI, тестуємо локально на дзеркальній macOS-машині.
- Тестування: запускаємо повний цикл збірки на CI, перевіряємо підпис та експорт для всіх конфігурацій (Dev, AdHoc, App Store, Enterprise).
- Деплой: документуємо процес, передаємо доступи, навчаємо команду.
Що входить у роботу
- Налаштування fastlane match або ручного скрипта підпису
- Створення xcconfig-файлів для всіх конфігурацій
- Інтеграція з CI (GitLab CI, Jenkins, GitHub Actions та ін.)
- Автоматизація build number
- Конфігурація ExportOptions.plist для всіх таргетів
- Документація та навчання команди
Строки та вартість
Базове налаштування (без fastlane) — від 3 до 5 днів. Повна автоматизація з xcconfig, build number, кількома таргетами та інтеграцією з CI — від 1 до 2 тижнів. Вартість базового налаштування — від 7 000 грн, повної автоматизації — від 20 000 грн. Економія: кожен ручний реліз без автоматизації обходиться в 5–10 тисяч гривень на тестувальника, з автоматизацією — 0. Таким чином, налаштування окупається за 2–3 релізи. Отримайте консультацію щодо вашої інфраструктури — ми оцінимо проект і запропонуємо оптимальне рішення. Замовте налаштування під ключ від 10 000 грн і забудьте про проблеми зі збіркою назавжди. Зв'яжіться з нами — ми відповімо протягом дня.