Fonctionnalités de création et de livraison d'applications iOS

Dans cet article, nous partageons l'expérience d'assemblage et de livraison d'applications iOS aux utilisateurs, que le studio Plarium Krasnodar a accumulée dans le processus de débogage CI/CD.

Formation

Toute personne impliquée d'une manière ou d'une autre dans le développement d'applications pour les appareils Apple a déjà apprécié la commodité controversée de l'infrastructure. Les difficultés se retrouvent partout : du menu du profil du développeur aux outils de débogage et de build.

Il existe de nombreux articles sur les « bases » sur Internet, nous allons donc essayer de souligner l'essentiel. Voici ce dont vous avez besoin pour créer votre application avec succès :

• compte développeur;
• un appareil basé sur macOS agissant comme un serveur de build ;
• généré certificat de développeur, qui sera ensuite utilisé pour signer la demande ;
• application créée avec un unique ID (il convient de noter l'importance de l'identifiant de bundle, car l'utilisation d'un identifiant générique rend impossible l'utilisation de nombreuses fonctions de l'application, par exemple : domaines associés, notifications push, connexion Apple et autres) ;
• profil signatures d'application.

Un certificat de développeur doit être généré via le trousseau sur n'importe quel appareil macOS. Le type de certificat est très important. Selon l'environnement de l'application (Dev, QA, Staging, Production), il différera (Développement ou Distribution), tout comme le type de profil de signature de l'application.

Principaux types de profils :

• Développement - destiné à signer l'application de l'équipe de développement, un certificat de développement est utilisé (type nom iPhone Developer : XXXXX) ;
• Ad Hoc - destiné à la signature d'une application de test et à la vérification interne par le service QA, le certificat de distribution du développeur est utilisé (nom de type iPhone Distribution : XXXXX) ;
• App Store - version version pour tests externes via TestFlight et téléchargement sur l'App Store, le certificat de distribution du développeur est utilisé.

Lors de la génération des profils Développement et Ad Hoc, il est également indiqué liste des périphériques, sur lequel vous pouvez installer une build, qui vous permet de restreindre davantage l'accès des utilisateurs. Il n'y a pas de liste d'appareils dans le profil App Store, car le contrôle d'accès pendant les tests bêta fermés est géré par TestFlight, dont nous parlerons plus tard.

Pour plus de clarté, vous pouvez présenter le profil du développeur sous la forme d’un tableau ci-dessous. Cela permet de comprendre plus facilement de quels paramètres nous avons besoin pour l'assemblage et où les obtenir.

assemblage

Pour faciliter la séparation des assemblys par projet et environnement, nous utilisons des noms de profil comme ${ProjectName}_${Instance}, c'est-à-dire le nom du projet + l'instance (dépend de l'environnement de l'application : Dev, QA, GD, Staging, Live, etc.).

Lorsqu'il est importé sur le serveur de build, le profil change son nom en un identifiant unique et est déplacé vers le dossier /Users/$Username/Library/MobileDevice/Provisioning Profiles (où $Username correspond au nom du compte utilisateur du serveur de build).

Il existe deux manières de créer un fichier *.ipa : héritée (PackageApplication) et moderne (via la création et l'exportation XcAchive). La première méthode est considérée comme obsolète, puisque depuis la version 8.3, le module d'empaquetage de fichiers d'application a été supprimé de la distribution Xcode. Pour l'utiliser, vous devez copier le module de l'ancien Xcode (version 8.2 et antérieure) dans le dossier :
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/

Et puis exécutez la commande :

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

Ensuite, vous devez collecter le fichier *.app de l'application :

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

Où:

-workspace - chemin d'accès au fichier du projet.

-scheme — le schéma utilisé, précisé dans le projet.

-derivedDataPath — chemin pour télécharger l'application assemblée (*.app).

CODE_SIGN_IDENTITY — le nom du compte développeur, qui peut être vérifié dans le trousseau (iPhone Developer : XXXX XXXXXXX, sans TeamID entre parenthèses).

PROVISIONING_PROFILE — ID de profil pour signer la demande, qui peut être obtenu avec la commande :

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

Si l'application utilise un profil supplémentaire (par exemple, pour les notifications push), alors au lieu de PROVISIONING_PROFILE indiquer:

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

Ensuite, le fichier *.app résultant doit être regroupé dans *.ipa. Pour ce faire, vous pouvez utiliser une commande comme :

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

Cependant, cette méthode est considérée comme obsolète du point de vue d'Apple. Il est pertinent d'obtenir *.ipa en exportant depuis l'archive de l'application.

Vous devez d'abord récupérer l'archive avec la commande :

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 différences résident dans la méthode d'assemblage et les options SYNCHRONOUS_SYMBOL_PROCESSING, qui désactive le déchargement des symboles au moment de la construction.

Ensuite, nous devons générer un fichier avec les paramètres d'exportation :

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

Où:

$Method — méthode de livraison, correspond au type de profil de signature de l'application, c'est-à-dire que pour le développement, la valeur sera développement, pour Ad Hoc - ad hoc et pour l'App Store - app-store.

$BundleID — ID d'application, spécifié dans les paramètres de l'application. Vous pouvez vérifier avec la commande :

defaults read $ProjectDir/Info CFBundleIdentifier

$DevAccName и $ProfileId — les paramètres du nom du développeur et de l'ID du profil de signature qui ont été utilisés précédemment et doivent correspondre aux valeurs des paramètres d'exportation.

$TeamID — identifiant à dix chiffres entre parenthèses après le nom du développeur, exemple : Développeur iPhone : …… (XXXXXXXXXX) ; peut être vérifié dans le trousseau.

Ensuite, en utilisant la commande export, nous obtenons le fichier *.ipa nécessaire :

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

livraison

Le fichier collecté doit maintenant être livré à l'utilisateur final, c'est-à-dire installé sur l'appareil.

Il existe de nombreux services pour distribuer des builds de développement et ad hoc, tels que HockeyApp, AppBlade et autres, mais dans cet article, nous parlerons d'un serveur autonome pour distribuer des applications.

L'installation de l'application pour iOS se déroule en 2 étapes :

1. Réception du manifeste d'installation de l'application via le service Items.
2. Installation du fichier *.ipa selon les informations spécifiées dans le manifeste via HTTPS.

Ainsi, nous devons d'abord générer un manifeste d'installation (type de fichier *.plist) avec la commande :

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

Comme vous pouvez le constater, le manifeste contient presque tous les paramètres impliqués dans la création de l'application.

Version de l'application ($AppVersion) peut être vérifié avec la commande :

defaults read $ProjectDir/Info CFBundleVersion

Paramètre $ipaUrl contient un lien direct pour télécharger le fichier *.ipa. A partir de la septième version d'iOS, l'application doit être installée via HTTPS. Dans la huitième version, le format du manifeste a légèrement changé : des blocs avec des paramètres pour les icônes d'application comme

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

Ainsi, pour installer l'application, une simple page HTML avec un lien comme celui-ci suffit :

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

Pour les besoins des départements de développement et de tests, Plarium a créé sa propre application d'installation de build, qui nous offre :

• l'autonomie et l'indépendance,
• centralisation du contrôle d’accès et installation sécurisée des applications grâce à des liens « temporaires » créés dynamiquement,
• fonctionnalité extensible (c'est-à-dire que l'équipe de développement, si nécessaire, peut intégrer les fonctions manquantes dans une application existante).

Test

Nous allons maintenant parler des tests préliminaires de l'application en utilisant TestFlight.

Les conditions requises pour le téléchargement sont le type de profil de signature App Store et la présence de clés API générées.

Il existe plusieurs manières de télécharger l'application :

• via Xcode (Organisateur),
• via altool,
• via Application Loader pour les anciennes versions de Xcode (maintenant Transporter).

Pour le téléchargement automatique, on utilise altool, qui dispose également de deux méthodes d'autorisation :

• Mot de passe spécifique à l'application,
• Clé API.

Il est préférable de télécharger l'application à l'aide de la clé API.

Pour obtenir la clé API, accédez à lien et générer une clé. En plus de la clé elle-même au format *.p8, nous aurons besoin de deux paramètres : IssuerID et KeyID.

Ensuite, importez la clé téléchargée sur le serveur de build :

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

Avant de télécharger l'application sur TestFlight, vous devez valider l'application, nous le faisons avec la commande :

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

Où apiKey и apiIssuer avoir des valeurs de champ de la page de génération de clé API.

Ensuite, une fois la validation réussie, nous chargeons l'application avec la commande --upload-app avec les mêmes paramètres.

L'application sera testée par Apple d'ici un ou deux jours et sera ensuite disponible pour les testeurs externes : ils recevront par email des liens d'installation.

Une autre façon de télécharger une application via altool consiste à utiliser un mot de passe spécifique à l'application.

Pour obtenir le mot de passe spécifique à l'application, vous devez accéder à lien et générez-le dans la section Sécurité.

Ensuite, vous devez créer un enregistrement de serveur de build dans le trousseau avec ce mot de passe. Depuis la version 11 de Xcode, cela peut être fait avec la commande :

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

Où:

$DeveloperName — le nom du compte développeur iOS utilisé pour se connecter aux services Apple.

$AppPswd - Mot de passe spécifique à l'application généré.

Ensuite, nous obtenons la valeur du paramètre asc-provider et vérifions le succès de l'importation du mot de passe avec la commande :

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

Nous obtenons le résultat :

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

Comme vous pouvez le voir, la valeur Short Name requise (asc-provider) coïncide avec le paramètre $TeamID que nous avons utilisé lors de la création de l'application.

Pour valider et charger l'application dans TestFlight, utilisez la commande :

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

En tant que valeur de paramètre -p tu peux prendre la valeur $AppPswd sous forme non cryptée (explicite).

Cependant, comme déjà mentionné, du point de vue des performances, il est préférable de choisir la clé API pour l'autorisation altool, car différentes versions de Xcode ont certains problèmes (« ne voit pas » le trousseau, erreurs d'autorisation lors du téléchargement, etc.).

C'est tout, en fait. Je souhaite à toutes les personnes impliquées des versions réussies et des versions sans problème dans l'App Store.

Source: habr.com