Caracteristici de construire și livrare de aplicații iOS

În acest articol, împărtășim experiența asamblarii și livrării de aplicații iOS către utilizatori, pe care studioul Plarium Krasnodar a acumulat-o în procesul de depanare CI/CD.

Pregătire

Fiecare persoană care este într-un fel sau altul implicată în dezvoltarea de aplicații pentru dispozitivele Apple a apreciat deja confortul controversat al infrastructurii. Dificultățile se găsesc peste tot: de la meniul profilului de dezvoltator până la instrumentele de depanare și construire.

Există o mulțime de articole despre „elementele de bază” pe Internet, așa că vom încerca să evidențiem principalul lucru. Iată de ce aveți nevoie pentru a vă construi aplicația cu succes:

• cont de dezvoltator;
• un dispozitiv bazat pe macOS care acționează ca un server de compilare;
• generate certificat de dezvoltator, care va fi folosit în continuare pentru semnarea cererii;
• aplicație creată cu unic ID (trebuie remarcată importanța Bundle Identifier, deoarece utilizarea ID-ului wildcard face imposibilă utilizarea multor funcții ale aplicației, de exemplu: Domenii asociate, Notificări Push, Apple Sign In și altele);
• profil semnăturile cererii.

Un certificat de dezvoltator trebuie generat prin Keychain pe orice dispozitiv macOS. Tipul de certificat este foarte important. În funcție de mediul aplicației (Dev, QA, Staging, Production) acesta va diferi (dezvoltare sau distribuție), la fel ca și tipul de profil al semnăturii aplicației.

Principalele tipuri de profile:

• Dezvoltare - destinat semnarii aplicatiei echipei de dezvoltare, se foloseste un certificat de dezvoltare (nume tip iPhone Developer: XXXXX);
• Ad Hoc - destinat semnarii unei aplicatii de testare si verificarii interne de catre departamentul QA, se foloseste certificatul de Distributie al dezvoltatorului (nume tip iPhone Distribution: XXXXX);
• App Store - versiunea de lansare pentru testarea externă prin TestFlight și încărcarea în App Store, se folosește certificatul de distribuție al dezvoltatorului.

La generarea profilurilor de Dezvoltare și Ad Hoc, este de asemenea indicat lista de dispozitive, pe care puteți instala o versiune, care vă permite să restricționați și mai mult accesul utilizatorilor. Nu există o listă de dispozitive în profilul App Store, deoarece controlul accesului în timpul testării beta închise este gestionat de TestFlight, despre care va fi discutat mai târziu.

Pentru claritate, puteți prezenta profilul dezvoltatorului sub forma unui tabel de mai jos. Acest lucru face mai ușor să înțelegem ce parametri avem nevoie pentru asamblare și de unde să-i obținem.

asamblare

Pentru a facilita separarea ansamblurilor în funcție de proiect și mediu, folosim nume de profil cum ar fi ${ProjectName}_${Instance}, adică numele proiectului + instanță (depinde de mediul aplicației: Dev, QA, GD, Staging, Live și așa mai departe).

Când este importat pe serverul de compilare, profilul își schimbă numele într-un ID unic și este mutat în dosar /Users/$Username/Library/MobileDevice/Provisioning Profiles (Unde $Username corespunde numelui contului de utilizator al serverului de compilare).

Există două moduri de a construi un fișier *.ipa - moștenit (PackageApplication) și modern (prin crearea și exportul XcAchive). Prima metodă este considerată învechită, deoarece din versiunea 8.3 modulul de ambalare a fișierelor aplicației a fost eliminat din distribuția Xcode. Pentru a-l folosi, trebuie să copiați modulul din vechiul Xcode (versiunea 8.2 și anterioară) în folder:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/

Și apoi rulați comanda:

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

Apoi, trebuie să colectați fișierul *.app al aplicației:

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

În cazul în care:

-workspace — calea către fișierul proiect.

-scheme — schema utilizată, specificată în proiect.

-derivedDataPath — cale pentru a descărca aplicația asamblată (*.app).

CODE_SIGN_IDENTITY — numele contului de dezvoltator, care poate fi verificat în Keychain (iPhone Developer: XXXX XXXXXXX, fără TeamID între paranteze).

PROVISIONING_PROFILE — ID de profil pentru semnarea aplicației, care poate fi obținut cu comanda:

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

Dacă aplicația folosește un profil suplimentar (de exemplu, pentru notificări push), atunci în loc de PROVISIONING_PROFILE indica:

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

Apoi, fișierul rezultat *.app ar trebui să fie împachetat în *.ipa. Pentru a face acest lucru, puteți utiliza o comandă ca:

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

Cu toate acestea, această metodă este considerată învechită din punctul de vedere al Apple. Este relevant să obțineți *.ipa prin exportul din arhiva aplicației.

Mai întâi trebuie să colectați arhiva cu comanda:

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

Diferentele constau in metoda si optiunile de asamblare SYNCHRONOUS_SYMBOL_PROCESSING, care dezactivează descărcarea simbolului în timpul construirii.

În continuare trebuie să generăm un fișier cu setările de export:

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

În cazul în care:

$Method — metoda de livrare, corespunde tipului de profil al semnăturii aplicației, adică pentru Dezvoltare valoarea va fi dezvoltare, pentru Ad Hoc - ad-hoc și pentru App Store - app-store.

$BundleID — ID aplicație, care este specificat în setările aplicației. Puteți verifica cu comanda:

defaults read $ProjectDir/Info CFBundleIdentifier

$DevAccName и $ProfileId — setările pentru numele dezvoltatorului și ID-ul profilului de semnătură care au fost utilizate anterior și trebuie să se potrivească cu valorile din setările de export.

$TeamID — ID din zece cifre între paranteze după numele dezvoltatorului, exemplu: Dezvoltator iPhone: …… (XXXXXXXXXX); poate fi verificat în breloc.

Apoi, folosind comanda de export, obținem fișierul *.ipa necesar:

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

Livrare

Acum, fișierul colectat trebuie să fie livrat utilizatorului final, adică instalat pe dispozitiv.

Există multe servicii pentru distribuirea build-urilor Development și Ad Hoc, precum HockeyApp, AppBlade și altele, dar în acest articol vom vorbi despre un server autonom pentru distribuirea aplicațiilor.

Instalarea aplicației pentru iOS are loc în 2 etape:

1. Primirea manifestului de instalare a aplicației prin intermediul serviciului Items.
2. Instalarea fișierului *.ipa conform informațiilor specificate în manifest prin HTTPS.

Astfel, mai întâi trebuie să generăm un manifest de instalare (tip de fișier *.plist) cu comanda:

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

După cum puteți vedea, manifestul conține aproape toți parametrii implicați în construirea aplicației.

Versiunea aplicației ($AppVersion) poate fi verificat cu comanda:

defaults read $ProjectDir/Info CFBundleVersion

Parametru $ipaUrl conține un link direct pentru a descărca fișierul *.ipa. De la a șaptea versiune de iOS, aplicația trebuie instalată prin HTTPS. În cea de-a opta versiune, formatul manifestului s-a schimbat ușor: blocuri cu setări pentru pictogramele aplicației precum

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

Astfel, pentru a instala aplicația, este suficientă o simplă pagină HTML cu un link ca acesta:

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

Pentru nevoile departamentelor de dezvoltare și testare, Plarium a creat propria aplicație de instalare a build-ului, care ne oferă:

• autonomie și independență,
• centralizarea controlului accesului și instalarea securizată a aplicațiilor prin link-uri „temporare” create dinamic,
• funcționalitate extensibilă (adică echipa de dezvoltare, dacă este necesar, poate integra funcțiile lipsă într-o aplicație existentă).

Testarea

Acum vom vorbi despre testarea pre-lansare a aplicației folosind TestFlight.

Condițiile necesare pentru descărcare sunt tipul de profil de semnătură App Store și prezența cheilor API generate.

Există mai multe modalități de a descărca aplicația:

• prin Xcode (Organizator),
• prin altool,
• prin Application Loader pentru versiunile mai vechi de Xcode (acum Transporter).

Pentru descărcarea automată, se folosește altool, care are și două metode de autorizare:

• Parolă specifică aplicației,
• Cheia API.

Este de preferat să descărcați aplicația folosind cheia API.

Pentru a obține cheia API, accesați legătură și generează o cheie. Pe lângă cheia în sine în format *.p8, vom avea nevoie de doi parametri: IssuerID și KeyID.

Apoi, importați cheia descărcată pe serverul de compilare:

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

Înainte de a încărca aplicația în TestFlight, trebuie să validați aplicația, facem acest lucru cu comanda:

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

unde apiKey и apiIssuer au valori de câmp din pagina de generare a cheilor API.

Apoi, după validarea cu succes, încărcăm aplicația cu comanda --upload-app cu aceiași parametri.

Aplicația va fi testată de Apple în decurs de una sau două zile și va deveni apoi disponibilă pentru testerii externi: li se vor trimite prin e-mail linkuri pentru instalare.

O altă modalitate de a descărca o aplicație prin altool este să utilizați parola specifică aplicației.

Pentru a obține parola specifică aplicației, trebuie să accesați legătură și generați-l în secțiunea Securitate.

Apoi, ar trebui să creați o înregistrare a serverului de compilare în Keychain cu această parolă. Din versiunea 11 a Xcode acest lucru se poate face cu comanda:

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

În cazul în care:

$DeveloperName — numele contului de dezvoltator iOS folosit pentru a vă conecta la serviciile Apple.

$AppPswd — Parola specifică aplicației generată.

În continuare, obținem valoarea parametrului asc-provider și verificăm succesul importului parolei cu comanda:

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

Obținem rezultatul:

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

După cum puteți vedea, valoarea necesară Short Name (asc-provider) coincide cu parametrul $TeamID pe care l-am folosit la construirea aplicației.

Pentru a valida și încărca aplicația în TestFlight, utilizați comanda:

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

Ca valoare a parametrului -p poti lua valoarea $AppPswd în formă necriptată (explicită).

Cu toate acestea, așa cum sa menționat deja, din punct de vedere al performanței, este mai bine să alegeți cheia API pentru autorizarea altool, deoarece diferite versiuni de Xcode au anumite probleme („nu vede” Keychain, erori de autorizare în timpul încărcării etc.).

Asta e tot, de fapt. Le doresc tuturor celor implicați versiuni de succes și versiuni fără probleme în App Store.

Sursa: www.habr.com