Характеристики на сглобяване и доставка на iOS приложения

В тази статия споделяме опита от изграждането и предоставянето на iOS приложения на потребителите, който Plarium Krasnodar е натрупал в процеса на отстраняване на грешки в CI/CD.

Обучение

Всеки човек, по един или друг начин свързан с разработването на приложения за устройства на Apple, вече е успял да оцени противоречивото удобство на инфраструктурата. Сложностите са навсякъде, от менюто на профила на програмиста до инструментите за отстраняване на грешки и изграждане.

В мрежата има много статии за „основите“, така че ще се опитаме да подчертаем основното. Ето какво ви трябва, за да създадете успешно приложението:

• акаунт на програмист;
• устройство, базирано на macOS, действащо като сървър за изграждане;
• генерирани сертификат за разработчик, които по-нататък ще се използват за подписване на заявлението;
• създадено приложение с уникален ID (Трябва да се отбележи важността на Bundle Identifier, тъй като използването на ID със заместващ знак прави невъзможно използването на много от функциите на приложението, например: Асоциирани домейни, Push Notifications, Apple Sign In и други);
• профил подпис на приложението.

Сертификатът на програмист трябва да бъде генериран чрез Keychain на всяко устройство с macOS. Видът на сертификата е много важен. В зависимост от средата на приложението (Dev, QA, Staging, Production), тя ще се различава (разработване или разпространение), както и типа на профила за подписване на приложението.

Основни видове профили:

• Разработка - предназначена за подписване на приложението на екипа за разработка, използва се сертификатът за разработка (име на типа iPhone Developer: XXXXX);
• Ad Hoc - предназначен за подписване на тестово приложение и вътрешна проверка от QA отдела, използвайки сертификата за разпространение на разработчика (име на типа iPhone Distribution: XXXXX);
• App Store е версия на версия за външно тестване чрез TestFlight и качване в App Store, като се използва сертификат за разпространение на разработчик.

При генериране на профилите Development и Ad Hoc също се посочва списък с устройства, на който можете да инсталирате компилацията, което ви позволява допълнително да ограничите достъпа за потребителите. В профила на App Store няма списък с устройства, тъй като TestFlight, който ще бъде обсъден по-късно, отговаря за контрола на достъпа по време на затворено бета тестване.

За по-голяма яснота можете да представите профила на разработчика под формата на таблица по-долу. Това улеснява разбирането какви параметри за сглобката ни трябват и откъде да ги вземем.

монтаж

За да улесним разделянето на сборките по проект и среда, ние използваме имената на профилите на формата ${ProjectName}_${Instance}, тоест името на проекта + екземпляр (в зависимост от средата на приложението: Dev, QA, GD, Staging, Live и т.н.).

Когато се импортира в сървъра за изграждане, профилът променя името си на уникален идентификатор и се премества в папката /Users/$Username/Library/MobileDevice/Provisioning Profiles (Където $Username съвпада с името на потребителския акаунт на сървъра за изграждане).

Има два начина за сглобяване на *.ipa файла - остарял (PackageApplication) и модерен (чрез създаване и експортиране на XcAchive). Първият метод се счита за остарял, тъй като модулът за пакетиране на файлове на приложението е премахнат от разпространението на Xcode от версия 8.3. За да го използвате, трябва да копирате модула от стария Xcode (версия 8.2 и по-стари) в папката:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/

И след това изпълнете командата:

chmod +x /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/*

След това трябва да създадете *.app файла на приложението:

xcodebuild 
-workspace $ProjectDir/$ProjectName.xcworkspace 
-scheme $SchemeName 
-sdk iphoneos 
build 
-configuration Release 
-derivedDataPath build 
CODE_SIGN_IDENTITY=”$DevAccName”
PROVISIONING_PROFILE=”$ProfileId”
DEPLOYMENT_POSTPROCESSING=YES 
SKIP_INSTALL=YES 
ENABLE_BITCODE=NO

Къде:

-workspace - път до файла на проекта.

-scheme - използвана схема, посочена в проекта.

-derivedDataPath - пътя за разтоварване на сглобеното приложение (*.app).

CODE_SIGN_IDENTITY — име на акаунт на програмист, което може да се провери в Keychain (разработчик на iPhone: XXXX XXXXXXX, без TeamID в скоби).

PROVISIONING_PROFILE — ID на профил за подписване на приложението, който се получава с командата:

cd "/Users/$Username/Library/MobileDevice/Provisioning Profiles/" && find *.mobileprovision -type f | xargs grep -li ">${ProjectName}_${Instance}<" | sed -e 's/.mobileprovision//'

Ако приложението използва допълнителен профил (например за Push Notifications), тогава вместо PROVISIONING_PROFILE посочете:

APP_PROFILE=”$AppProfile” 
EXTENSION_PROFILE=”$ExtProfile” 

След това полученият *.app файл трябва да бъде пакетиран в *.ipa. За да направите това, можете да използвате команда като:

/usr/bin/xcrun --sdk iphoneos PackageApplication 
-v $(find "$ProjectDir/build/Build/Products/Release-iphoneos" -name "*.app") 
-o "$ProjectDir/$ProjectName_$Instance.ipa"

Този метод обаче се счита за остарял от гледна точка на Apple. Уместно е получаването на *.ipa чрез експортиране от архива на приложението.

Първо трябва да изградите архива с командата:

xcodebuild 
-workspace $ProjectDir/$ProjectName.xcworkspace 
-scheme $SchemeName 
-sdk iphoneos 
-configuration Release 
archive 
-archivePath $ProjectDir/build/$ProjectName.xcarchive 
CODE_SIGN_IDENTITY=”$DevAccName” 
PROVISIONING_PROFILE=”$ProfileId”
ENABLE_BITCODE=NO 
SYNCHRONOUS_SYMBOL_PROCESSING=FALSE

Разликите са в начина на сглобяване и опциите SYNCHRONOUS_SYMBOL_PROCESSING, което деактивира разтоварването на символи по време на изграждане.

След това трябва да генерираме файл с настройки за експортиране:

ExportSettings="$ProjectDir/exportOptions.plist"

cat << EOF > $ExportSettings
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>compileBitcode</key>
<false/>
<key>uploadBitcode</key>
<false/>
<key>uploadSymbols</key>
<false/>
<key>method</key>
<string>$Method</string>
<key>provisioningProfiles</key>
<dict>
<key>$BundleID</key>
<string>$ProfileId</string>
</dict>
<key>signingCertificate</key>
<string>$DevAccName</string>
<key>signingStyle</key>
<string>manual</string>
<key>stripSwiftSymbols</key>
<true/>
<key>teamID</key>
<string>$TeamID</string>
<key>thinning</key>
<string><none></string>
</dict>
</plist>
EOF

Къде:

$Method - метод на доставка, съответства на типа на профила на подписа на приложението, т.е. за Разработка стойността ще бъде разработка, за Ad Hoc - ad-hoc, а за App Store - магазин за приложения.

$BundleID - ID на приложението, което се посочва в настройките на приложението. Можете да проверите с командата:

defaults read $ProjectDir/Info CFBundleIdentifier

$DevAccName и $ProfileId - името на разработчика и настройките за ID на профила на подписа, които са били използвани преди това и трябва да съответстват на стойностите в настройките за експортиране.

$TeamID - десетцифрен идентификатор в скоби след името на разработчика, например: iPhone Developer: ...... (XXXXXXXXXX); може да се провери в Keychain.

След това, използвайки командата за експортиране, получаваме необходимия * .ipa файл:

xcodebuild 
-exportArchive 
-archivePath $ProjectDir/build/$ProjectName.xcarchive 
-exportPath $ProjectDir 
-exportOptionsPlist $ExportSettings

Доставка

Сега сглобеният файл трябва да бъде доставен на крайния потребител, тоест инсталиран на устройството.

Има много услуги за разпространение на разработки и ad hoc компилации, като HockeyApp, AppBlade и други, но в тази статия ще се съсредоточим върху самостоятелен сървър за разпространение на приложения.

Инсталирането на iOS приложението се извършва на 2 етапа:

1. Получаване на манифеста за инсталиране на приложението чрез услугата Items.
2. Инсталиране на файла *.ipa според информацията, посочена в манифеста чрез HTTPS.

По този начин първо трябва да генерираме инсталационен манифест (файлов тип *.plist) с командата:

cat << EOF > $manifest
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>items</key>
<array>
<dict>
<key>assets</key>
<array>
<dict>
<key>kind</key>
<string>software-package</string>
<key>url</key>
<string>$ipaUrl</string>
</dict>
</array>
<key>metadata</key>
<dict>
<key>bundle-identifier</key>
<string>$BundleID</string>
<key>bundle-version</key>
<string>$AppVersion</string>
<key>kind</key>
<string>software</string>
<key>title</key>
<string>$ProjectName_$Instance</string>
<key>subtitle</key>
<string>$Instance</string>
</dict>
</dict>
</array>
</dict>
</plist>
EOF

Както можете да видите, манифестът съдържа почти всички параметри, включени в изграждането на приложението.

Версия на приложението ($AppVersion) може да се провери с командата:

defaults read $ProjectDir/Info CFBundleVersion

Параметър $ipaUrl съдържа директна връзка за изтегляне на файла *.ipa. От седмата версия на iOS приложението трябва да се инсталира през HTTPS. В осмата версия форматът на манифеста е леко променен: блоковете с настройките за иконите на приложенията на изгледа са премахнати.

<images>
   <image>...</image>
</images>

По този начин, за да инсталирате приложението, е достатъчна проста html страница с връзка като тази:

itms-services://?action=download-manifest&url=https://$ServerUrl/$ProjectName/$Instance/iOS/$AppVersion/manifest.plist

За нуждите на отделите за разработка и тестване, Plarium създаде собствено приложение за инсталиране на компилация, което ни дава:

• автономия и независимост,
• централизиране на контрола на достъпа и сигурно инсталиране на приложения чрез "временни", динамично създавани връзки,
• разширяема функционалност (т.е. екипът за разработка, ако е необходимо, може да интегрира липсващите функции в съществуващо приложение).

Тестване

Сега ще говорим за тестване преди пускане на приложението, използващо TestFlight.

Предпоставки за изтегляне са типът на профила за подписване в App Store и наличието на генерирани API ключове.

Има няколко начина за изтегляне на приложението:

• чрез Xcode (организатор),
• чрез altool,
• чрез Application Loader за по-стари версии на Xcode (сега Transporter).

За автоматично изтегляне се използва altool, който също има два метода за оторизация:

• Парола за конкретно приложение,
• API ключ.

За предпочитане е да изтеглите приложението чрез API ключа.

За да получите API ключа, отидете на връзка и генерирайте ключ. В допълнение към самия ключ във формат *.p8, имаме нужда от два параметъра: IssuerID и KeyID.

След това импортирайте изтегления ключ в сървъра за изграждане:

mkdir -p ~/.appstoreconnect/private_keys
mv ~/Downloads/AuthKey_${KeyID}.p8 ~/.appstoreconnect/private_keys/

Преди да качите приложението в TestFlight, трябва да потвърдите приложението, ние правим това с командата:

xcrun altool 
--validate-app 
-t ios 
-f $(find "$ProjectDir" -name "*.ipa") 
--apiKey “$KeyID” 
--apiIssuer “$IssuerID” 

където apiKey и apiIssuer имат стойности на полета от страницата за генериране на API ключ.

Освен това, при успешно валидиране, зареждаме приложението с командата --upload-app със същите параметри.

Приложението ще бъде тествано от Apple в рамките на един или два дни и след това ще стане достъпно за външни тестери: те ще получат връзки за инсталиране по пощата.

Друг начин за изтегляне на приложение чрез altool е да използвате паролата за конкретно приложение.

За да получите паролата за конкретно приложение, трябва да отидете на връзка и го генерирайте в секцията Сигурност.

След това създайте запис на сървър за изграждане в Keychain с тази парола. От версия 11 на Xcode това може да се направи с командата:

xcrun altool --store-password-in-keychain-item "Altool" -u "$DeveloperName" -p $AppPswd

Къде:

$DeveloperName — Име на акаунт на разработчик на iOS, използвано за влизане в услугите на Apple.

$AppPswd - генерирана парола за конкретно приложение.

След това получаваме стойността на параметъра asc-provider и проверяваме успеха на импортирането на парола с командата:

xcrun altool --list-providers -u "$DeveloperName" -p "@keychain:Altool"

Получаваме резултата:

Provider listing:
- Long Name - - Short Name -
XXXXXXX        XXXXXXXXX

Както можете да видите, желаната стойност за кратко име (asc-provider) съответства на параметъра $TeamID, който използвахме при изграждането на приложението.

За да потвърдите и заредите приложението в TestFlight, използвайте командата:

xcrun altool 
--(validate|upload)-app   
-f $(find "$ProjectDir" -name "*.ipa") 
-u "$DeveloperName" 
-p "@keychain:Altool" 

Като стойност на параметъра -p можете да вземете стойността $AppPswd в некриптирана (явна) форма.

Въпреки това, както вече беше споменато, от гледна точка на производителността е по-добре да изберете API ключа за оторизация на инструмента, тъй като различните версии на Xcode имат определени проблеми („не вижда“ Keychain, грешки при оторизация при качване и т.н. ).

Това всъщност е всичко. Пожелавам на всички участващи успешни компилации и безпроблемни версии в App Store.

Източник: www.habr.com