Característiques de muntatge i lliurament d'aplicacions iOS

En aquest article, compartim l'experiència de crear i lliurar aplicacions iOS als usuaris, que Plarium Krasnodar ha guanyat en el procés de depuració de CI/CD.

Entrenament

Totes les persones, d'una manera o altra, connectades amb el desenvolupament d'aplicacions per a dispositius Apple, ja han sabut apreciar la controvertida comoditat de la infraestructura. Les complexitats estan a tot arreu, des del menú del perfil del desenvolupador fins a les eines de depuració i creació.

Hi ha molts articles sobre els "bàsics" a la xarxa, així que intentarem destacar el més important. Això és el que necessiteu per crear l'aplicació amb èxit:

• compte de desenvolupador;
• un dispositiu basat en macOS que actua com a servidor de compilació;
• generat certificat de desenvolupador, que s'utilitzarà a més per signar la sol·licitud;
• aplicació creada amb un únic ID (S'ha de tenir en compte la importància de l'identificador de paquet, perquè l'ús d'un identificador comodí fa que no es puguin utilitzar moltes de les funcions de l'aplicació, per exemple: dominis associats, notificacions push, inici de sessió d'Apple i altres);
• perfil signatura de la sol·licitud.

S'ha de generar un certificat de desenvolupador mitjançant Keychain a qualsevol dispositiu macOS. El tipus de certificat és molt important. Segons l'entorn de l'aplicació (desenvolupament, control de qualitat, posada en escena, producció), variarà (desenvolupament o distribució), així com el tipus de perfil de signatura de l'aplicació.

Principals tipus de perfils:

• Desenvolupament: dissenyat per signar l'aplicació de l'equip de desenvolupament, s'utilitza el certificat de desenvolupament (nom del tipus iPhone Developer: XXXXX);
• Ad Hoc: destinat a signar una aplicació de prova i verificació interna per part del departament de control de qualitat, mitjançant el certificat de distribució del desenvolupador (nom del tipus iPhone Distribution: XXXXX);
• L'App Store és una versió de versió per a proves externes mitjançant TestFlight i la càrrega a l'App Store, mitjançant el certificat de distribució d'un desenvolupador.

A l'hora de generar els perfils de Desenvolupament i Ad Hoc també s'indica llista de dispositius, on podeu instal·lar la compilació, que us permet restringir encara més l'accés dels usuaris. No hi ha cap llista de dispositius al perfil de l'App Store, ja que TestFlight, que es comentarà més endavant, s'encarrega del control d'accés durant les proves beta tancades.

Per a més claredat, podeu presentar el perfil del desenvolupador en forma de taula a continuació. Això fa que sigui més fàcil entendre quins paràmetres per al muntatge necessitem i d'on obtenir-los.

assemblea

Per facilitar la separació de conjunts per projecte i entorn, utilitzem els noms de perfils del formulari ${ProjectName}_${Instance}, és a dir, el nom del projecte + instància (segons l'entorn de l'aplicació: Dev, QA, GD, Staging, Live, etc.).

Quan s'importa al servidor de compilació, el perfil canvia el seu nom a un ID únic i es mou a la carpeta /Users/$Username/Library/MobileDevice/Provisioning Profiles (On $Username coincideix amb el nom del compte d'usuari del servidor de compilació).

Hi ha dues maneres de muntar el fitxer *.ipa: obsolet (PackageApplication) i modern (mitjançant la creació i exportació de XcAchive). El primer mètode es considera obsolet, ja que el mòdul d'embalatge de fitxers de l'aplicació s'ha eliminat de la distribució Xcode des de la versió 8.3. Per utilitzar-lo, heu de copiar el mòdul de l'antic Xcode (versió 8.2 i anterior) a la carpeta:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/

I després executeu l'ordre:

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

A continuació, heu de crear el fitxer *.app de l'aplicació:

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

On:

-workspace - camí al fitxer del projecte.

-scheme - Esquema utilitzat especificat en el projecte.

-derivedDataPath - el camí per descarregar l'aplicació muntada (*.app).

CODE_SIGN_IDENTITY — Nom del compte de desenvolupador, que es pot comprovar al Keychain (Desenvolupador d'iPhone: XXXX XXXXXXX, sense TeamID entre parèntesis).

PROVISIONING_PROFILE — ID de perfil per signar l'aplicació, que es pot obtenir amb l'ordre:

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

Si l'aplicació utilitza un perfil addicional (per exemple, per a les notificacions push), en lloc de PROVISIONING_PROFILE indicar:

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

A continuació, el fitxer *.app resultant s'ha d'empaquetar a *.ipa. Per fer-ho, podeu utilitzar una ordre com:

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

No obstant això, aquest mètode es considera obsolet des del punt de vista d'Apple. El rellevant és obtenir *.ipa exportant des de l'arxiu de l'aplicació.

Primer heu de crear l'arxiu amb l'ordre:

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

Les diferències estan en el mètode de muntatge i les opcions SYNCHRONOUS_SYMBOL_PROCESSING, que desactiva la descàrrega de símbols en temps de creació.

A continuació, hem de generar un fitxer amb la configuració d'exportació:

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

On:

$Method - mètode de lliurament, correspon al tipus de perfil de signatura de l'aplicació, és a dir, per al desenvolupament, el valor serà desenvolupament, per a Ad Hoc - ad-hoc, i per a l'App Store - app-store.

$BundleID - ID de l'aplicació, que s'especifica a la configuració de l'aplicació. Podeu comprovar amb l'ordre:

defaults read $ProjectDir/Info CFBundleIdentifier

$DevAccName и $ProfileId - la configuració del nom del desenvolupador i de l'identificador del perfil de signatura que s'utilitzava anteriorment i que ha de coincidir amb els valors de la configuració d'exportació.

$TeamID - un identificador de deu dígits entre parèntesis després del nom del desenvolupador, exemple: Desenvolupador d'iPhone: ...... (XXXXXXXXXX); es pot comprovar al clauer.

A continuació, utilitzant l'ordre d'exportació, obtenim el fitxer * .ipa necessari:

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

Доставка

Ara el fitxer muntat s'ha de lliurar a l'usuari final, és a dir, instal·lat al dispositiu.

Hi ha molts serveis per distribuir les compilacions de desenvolupament i ad hoc, com ara HockeyApp, AppBlade i altres, però en aquest article ens centrarem en un servidor autònom per distribuir aplicacions.

La instal·lació de l'aplicació iOS es fa en 2 etapes:

1. Obtenció del manifest d'instal·lació de l'aplicació mitjançant el Servei d'Items.
2. Instal·lant el fitxer *.ipa segons la informació especificada al manifest mitjançant HTTPS.

Per tant, primer hem de generar un manifest d'instal·lació (tipus de fitxer *.plist) amb l'ordre:

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

Com podeu veure, el manifest conté gairebé tots els paràmetres implicats en la creació de l'aplicació.

Versió de l'aplicació ($AppVersion) es pot comprovar amb l'ordre:

defaults read $ProjectDir/Info CFBundleVersion

Paràmetre $ipaUrl conté un enllaç directe per descarregar el fitxer *.ipa. A partir de la setena versió d'iOS, l'aplicació s'ha d'instal·lar mitjançant HTTPS. A la vuitena versió, el format del manifest ha canviat lleugerament: s'han eliminat els blocs amb la configuració de les icones de l'aplicació de la vista.

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

Així, per instal·lar l'aplicació, n'hi ha prou amb una simple pàgina html amb un enllaç com aquest:

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

Per a les necessitats dels departaments de desenvolupament i proves, Plarium ha creat la seva pròpia aplicació d'instal·lació de compilació, que ens ofereix:

• autonomia i independència,
• centralització del control d'accés i instal·lació segura d'aplicacions mitjançant enllaços "temporals" creats dinàmicament,
• funcionalitat extensible (és a dir, l'equip de desenvolupament, si cal, pot integrar les funcions que falten en una aplicació existent).

Proves

Ara parlarem de les proves prèvies al llançament de l'aplicació TestFlight.

Els requisits previs per a la descàrrega són el tipus de perfil de signatura de l'App Store i la presència de claus API generades.

Hi ha diverses maneres de descarregar l'aplicació:

• mitjançant Xcode (organitzador),
• via altool,
• mitjançant Application Loader per a versions anteriors de Xcode (ara Transporter).

Per a la descàrrega automàtica, s'utilitza altool, que també té dos mètodes d'autorització:

• Contrasenya específica de l'aplicació,
• Clau de l'API.

És preferible descarregar l'aplicació mitjançant la clau API.

Per obtenir la clau de l'API, aneu a enllaç i generar una clau. A més de la pròpia clau en format *.p8, necessitem dos paràmetres: IssuerID i KeyID.

A continuació, importeu la clau baixada al servidor de compilació:

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

Abans de carregar l'aplicació a TestFlight, cal validar l'aplicació, ho fem amb l'ordre:

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

On apiKey и apiIssuer tenir valors de camp de la pàgina de generació de claus de l'API.

A més, després de la validació correcta, carreguem l'aplicació amb l'ordre --upload-app amb els mateixos paràmetres.

L'aplicació serà provada per Apple en un o dos dies i després estarà disponible per a provadors externs: se'ls enviarà enllaços per a la instal·lació per correu.

Una altra manera de descarregar una aplicació mitjançant altool és utilitzar la contrasenya específica de l'aplicació.

Per obtenir la contrasenya específica de l'aplicació, heu d'anar a enllaç i generar-lo a la secció Seguretat.

A continuació, creeu una entrada de servidor de compilació al clauer amb aquesta contrasenya. A partir de la versió 11 de Xcode, això es pot fer amb l'ordre:

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

On:

$DeveloperName — Nom del compte de desenvolupador d'iOS que s'utilitza per iniciar sessió als serveis d'Apple.

$AppPswd - Contrasenya específica de l'aplicació generada.

A continuació, obtenim el valor del paràmetre asc-provider i comprovem l'èxit de la importació de la contrasenya amb l'ordre:

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

Obtenim la sortida:

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

Com podeu veure, el valor Short Name (asc-provider) que estem buscant coincideix amb el paràmetre $TeamID que vam utilitzar quan vam crear l'aplicació.

Per validar i carregar l'aplicació a TestFlight, utilitzeu l'ordre:

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

Com a valor de paràmetre -p pots prendre el valor $AppPswd en una forma no xifrada (explícita).

Tanmateix, com ja s'ha comentat, des del punt de vista del rendiment, és millor triar la clau API per a l'autorització altool, ja que diferents versions d'Xcode tenen certs problemes (“no veu” el Keychain, errors d'autorització en pujar, etc.). ).

Això, de fet, és tot. Desitjo a tots els implicats compilacions exitoses i versions sense problemes a l'App Store.

Font: www.habr.com