ProHoster > Blog > Verwaltung > Funktionen zum Erstellen und Bereitstellen von iOS-Anwendungen

Funktionen zum Erstellen und Bereitstellen von iOS-Anwendungen

In diesem Artikel teilen wir die Erfahrungen mit der Zusammenstellung und Bereitstellung von iOS-Anwendungen für Benutzer, die das Studio Plarium Krasnodar im Prozess des Debuggens von CI/CD gesammelt hat.

Funktionen zum Erstellen und Bereitstellen von iOS-Anwendungen

Training

Jeder, der auf die eine oder andere Weise an der Entwicklung von Anwendungen für Apple-Geräte beteiligt ist, hat den umstrittenen Komfort der Infrastruktur bereits zu schätzen gewusst. Schwierigkeiten gibt es überall: vom Entwicklerprofilmenü bis zu den Debug- und Build-Tools.

Es gibt viele Artikel über die „Grundlagen“ im Internet, daher werden wir versuchen, das Wesentliche hervorzuheben. Folgendes benötigen Sie, um Ihre Anwendung erfolgreich zu erstellen:

  • Entwicklerkonto;
  • ein macOS-basiertes Gerät, das als Build-Server fungiert;
  • generiert Entwicklerzertifikat, das weiterhin zur Unterzeichnung des Antrags verwendet wird;
  • erstellte Anwendung mit einzigartigem ID (Die Bedeutung der Bundle-ID sollte beachtet werden, da die Verwendung einer Wildcard-ID die Nutzung vieler Funktionen der Anwendung unmöglich macht, zum Beispiel: Zugehörige Domänen, Push-Benachrichtigungen, Apple-Anmeldung und andere.)
  • Profil Antragssignaturen.

Auf jedem macOS-Gerät muss per Schlüsselbund ein Entwicklerzertifikat generiert werden. Die Art des Zertifikats ist sehr wichtig. Abhängig von der Anwendungsumgebung (Entwicklung, Qualitätssicherung, Staging, Produktion) unterscheidet es sich (Entwicklung oder Verteilung), ebenso wie die Art des Anwendungssignaturprofils.

Haupttypen von Profilen:

  • Entwicklung – dient zum Signieren der Anwendung des Entwicklungsteams, es wird ein Entwicklungszertifikat verwendet (Typname iPhone Developer: XXXXX);
  • Ad Hoc – zum Signieren eines Testantrags und zur internen Überprüfung durch die QS-Abteilung bestimmt; es wird das Verteilungszertifikat des Entwicklers verwendet (Typname iPhone-Verteilung: XXXXX);
  • App Store – Release-Build für externe Tests über TestFlight und Hochladen in den App Store, es wird das Distributionszertifikat des Entwicklers verwendet.

Bei der Erstellung von Entwicklungs- und Ad-hoc-Profilen wird dies ebenfalls angezeigt Geräteliste, auf dem Sie einen Build installieren können, mit dem Sie den Zugriff für Benutzer weiter einschränken können. Es gibt keine Geräteliste im App Store-Profil, da die Zugriffskontrolle während des geschlossenen Betatests von TestFlight übernommen wird, worauf später noch eingegangen wird.

Der Übersichtlichkeit halber können Sie das Profil des Entwicklers unten in Form einer Tabelle darstellen. Dadurch ist es einfacher zu verstehen, welche Parameter wir für die Montage benötigen und woher wir diese beziehen.

Funktionen zum Erstellen und Bereitstellen von iOS-Anwendungen

Montage

Um die Trennung von Baugruppen nach Projekt und Umgebung zu erleichtern, verwenden wir Profilnamen wie ${ProjectName}_${Instance}, also Projektname + Instanz (abhängig von der Anwendungsumgebung: Dev, QA, GD, Staging, Live usw.).

Beim Import auf den Build-Server ändert das Profil seinen Namen in eine eindeutige ID und wird in den Ordner verschoben /Users/$Username/Library/MobileDevice/Provisioning Profiles (wo $Username entspricht dem Benutzerkontonamen des Build-Servers).

Es gibt zwei Möglichkeiten, eine *.ipa-Datei zu erstellen: Legacy (PackageApplication) und modern (über XcAchive-Erstellung und -Export). Die erste Methode gilt als veraltet, da seit Version 8.3 das App-File-Packaging-Modul aus der Xcode-Distribution entfernt wurde. Um es zu verwenden, müssen Sie das Modul vom alten Xcode (Version 8.2 und früher) in den Ordner kopieren:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/

Und führen Sie dann den Befehl aus:

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

Als nächstes müssen Sie die *.app-Datei der Anwendung sammeln:

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

Wo:

-workspace – Pfad zur Projektdatei.

-scheme — das verwendete Schema, spezifiziert im Projekt.

-derivedDataPath – Pfad zum Herunterladen der zusammengestellten Anwendung (*.app).

CODE_SIGN_IDENTITY – der Name des Entwicklerkontos, der im Schlüsselbund überprüft werden kann (iPhone-Entwickler: XXXX XXXXXXX, ohne TeamID in Klammern).

Funktionen zum Erstellen und Bereitstellen von iOS-Anwendungen

PROVISIONING_PROFILE — Profil-ID zum Signieren der Anwendung, die mit dem Befehl abgerufen werden kann:

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

Wenn die Anwendung ein zusätzliches Profil verwendet (z. B. für Push-Benachrichtigungen), dann anstelle von PROVISIONING_PROFILE angeben:

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

Als nächstes sollte die resultierende *.app-Datei in *.ipa gepackt werden. Dazu können Sie einen Befehl wie den folgenden verwenden:

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

Allerdings gilt diese Methode aus Apples Sicht als veraltet. Es ist wichtig, *.ipa durch Exportieren aus dem Anwendungsarchiv zu erhalten.

Zuerst müssen Sie das Archiv mit dem Befehl sammeln:

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

Die Unterschiede liegen in der Montageart und den Optionen SYNCHRONOUS_SYMBOL_PROCESSING, wodurch das Entladen von Symbolen zur Erstellungszeit deaktiviert wird.

Als nächstes müssen wir eine Datei mit Exporteinstellungen generieren:

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

Wo:

$Method – Übermittlungsmethode, entspricht dem Typ des Anwendungssignaturprofils, d. h. für „Entwicklung“ ist der Wert „Entwicklung“, für „Ad Hoc“ „Ad-hoc“ und für „App Store“ „App-Store“.

$BundleID — Anwendungs-ID, die in den Anwendungseinstellungen angegeben wird. Sie können dies mit dem Befehl überprüfen: 

defaults read $ProjectDir/Info CFBundleIdentifier

$DevAccName и $ProfileId – Entwicklernamen- und Signaturprofil-ID-Einstellungen, die zuvor verwendet wurden und mit den Werten in den Exporteinstellungen übereinstimmen müssen.

$TeamID — zehnstellige ID in Klammern nach dem Namen des Entwicklers, Beispiel: iPhone-Entwickler: …… (XXXXXXXXXX); kann im Schlüsselbund überprüft werden.

Als nächstes erhalten wir mit dem Export-Befehl die erforderliche *.ipa-Datei:

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

Lieferung

Nun muss die gesammelte Datei an den Endbenutzer geliefert, also auf dem Gerät installiert werden.

Es gibt viele Dienste zum Verteilen von Entwicklungs- und Ad-hoc-Builds, wie HockeyApp, AppBlade und andere, aber in diesem Artikel werden wir über einen eigenständigen Server zum Verteilen von Anwendungen sprechen.

Die Installation der Anwendung für iOS erfolgt in 2 Schritten:

  1. Empfangen des Anwendungsinstallationsmanifests über den Items-Dienst.
  2. Installation der *.ipa-Datei gemäß den Angaben im Manifest über HTTPS.

Daher müssen wir zunächst ein Installationsmanifest (Dateityp *.plist) mit dem Befehl generieren:

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

Wie Sie sehen, enthält das Manifest fast alle Parameter, die zum Erstellen der Anwendung erforderlich sind.

Anwendungsversion ($AppVersion) kann mit dem Befehl überprüft werden:

defaults read $ProjectDir/Info CFBundleVersion

Parameter $ipaUrl enthält einen direkten Link zum Herunterladen der *.ipa-Datei. Ab der siebten iOS-Version muss die Anwendung über HTTPS installiert werden. In der achten Version hat sich das Format des Manifests leicht geändert: Blöcke mit Einstellungen für Anwendungssymbole wie

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

Um die Anwendung zu installieren, reicht daher eine einfache HTML-Seite mit einem Link wie diesem:

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

Für die Bedürfnisse der Entwicklungs- und Testabteilungen hat Plarium eine eigene Build-Installationsanwendung erstellt, die uns Folgendes bietet:

  • Autonomie und Unabhängigkeit,
  • Zentralisierung der Zugriffskontrolle und sichere Installation von Anwendungen durch „temporäre“ dynamisch erstellte Links,
  • erweiterbare Funktionalität (d. h. das Entwicklungsteam kann bei Bedarf fehlende Funktionen in eine bestehende Anwendung integrieren).

Testing

Jetzt werden wir über das Testen der Anwendung vor der Veröffentlichung sprechen Testflug.

Erforderliche Bedingungen für den Download sind die Art des App Store-Signaturprofils und das Vorhandensein generierter API-Schlüssel.

Es gibt mehrere Möglichkeiten, die Anwendung herunterzuladen:

  • über Xcode (Organizer),
  • über altool,
  • über Application Loader für ältere Versionen von Xcode (jetzt Transporter).

Für den automatischen Download wird altool verwendet, das ebenfalls über zwei Autorisierungsmethoden verfügt:

  • App-spezifisches Passwort,
  • API-Schlüssel.

Es empfiehlt sich, die Anwendung mit dem API-Schlüssel herunterzuladen.

Um den API-Schlüssel zu erhalten, gehen Sie zu Link und einen Schlüssel generieren. Zusätzlich zum Schlüssel selbst im *.p8-Format benötigen wir zwei Parameter: IssuerID und KeyID.

Funktionen zum Erstellen und Bereitstellen von iOS-Anwendungen

Als nächstes importieren Sie den heruntergeladenen Schlüssel auf den Build-Server:

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

Bevor Sie die Anwendung auf TestFlight hochladen, müssen Sie die Anwendung validieren. Dies erledigen wir mit dem Befehl:

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

Wo apiKey и apiIssuer haben Feldwerte von der Seite zur API-Schlüsselgenerierung.

Als nächstes laden wir nach erfolgreicher Validierung die Anwendung mit dem Befehl --upload-app mit den gleichen Parametern.

Die Anwendung wird innerhalb von ein bis zwei Tagen von Apple getestet und steht dann externen Testern zur Verfügung: Sie erhalten per E-Mail Links zur Installation.

Eine andere Möglichkeit, eine Anwendung über altool herunterzuladen, ist die Verwendung eines App-spezifischen Passworts.

Um das App-spezifische Passwort zu erhalten, müssen Sie zu gehen Link und generieren Sie es im Abschnitt Sicherheit.

Funktionen zum Erstellen und Bereitstellen von iOS-Anwendungen

Als Nächstes sollten Sie mit diesem Passwort einen Build-Server-Datensatz im Schlüsselbund erstellen. Ab Version 11 von Xcode kann dies mit dem Befehl erfolgen:

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

Wo:

$DeveloperName – der Name des iOS-Entwicklerkontos, das zur Anmeldung bei Apple-Diensten verwendet wird.

$AppPswd – generiertes App-spezifisches Passwort.

Als nächstes ermitteln wir den Wert des Parameters asc-provider und überprüfen den Erfolg des Passwortimports mit dem Befehl:

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

Wir erhalten die Ausgabe:

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

Wie Sie sehen können, stimmt der erforderliche Kurznamenwert (asc-provider) mit dem $TeamID-Parameter überein, den wir beim Erstellen der Anwendung verwendet haben.

Um die Anwendung zu validieren und in TestFlight zu laden, verwenden Sie den folgenden Befehl: 

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

Als Parameterwert -p Sie können den Wert nehmen $AppPswd in unverschlüsselter (expliziter) Form.

Allerdings ist es, wie bereits erwähnt, aus Leistungssicht besser, den API-Schlüssel für die Altool-Autorisierung zu wählen, da verschiedene Versionen von Xcode bestimmte Probleme haben („Schlüsselanhänger wird nicht angezeigt“, Autorisierungsfehler beim Hochladen usw.).

Das ist eigentlich alles. Ich wünsche allen Beteiligten erfolgreiche Builds und problemlose Veröffentlichungen im App Store.

Source: habr.com

Kommentar hinzufügen