ProHoster > Blog > administration > Funktioner ved at bygge og levere iOS-applikationer

Funktioner ved at bygge og levere iOS-applikationer

I denne artikel deler vi erfaringerne med at samle og levere iOS-applikationer til brugere, som Plarium Krasnodar-studiet har samlet i processen med at fejlsøge CI/CD.

Funktioner ved at bygge og levere iOS-applikationer

Træning

Enhver person, der på en eller anden måde er involveret i udviklingen af ​​applikationer til Apple-enheder, har allerede sat pris på den kontroversielle bekvemmelighed ved infrastrukturen. Vanskeligheder findes overalt: fra udviklerprofilmenuen til fejlfindings- og byggeværktøjerne.

Der er masser af artikler om "grundlæggende" på internettet, så vi vil forsøge at fremhæve det vigtigste. Her er hvad du skal bruge for at bygge din applikation med succes:

  • udviklerkonto;
  • en macOS-baseret enhed, der fungerer som en build-server;
  • genereret udviklercertifikat, som yderligere vil blive brugt til at underskrive ansøgningen;
  • oprettet applikation med unikke ID (Vigtigheden af ​​bundle-id'en skal bemærkes, fordi brugen af ​​jokertegn-id gør det umuligt at bruge mange funktioner i applikationen, for eksempel: Tilknyttede domæner, Push-meddelelser, Apple-logon og andre);
  • profil applikations signaturer.

Et udviklercertifikat skal genereres via nøglering på enhver macOS-enhed. Certifikattypen er meget vigtig. Afhængigt af applikationsmiljøet (Dev, QA, Staging, Production) vil det variere (Udvikling eller Distribution), ligesom typen af ​​applikationssignaturprofil.

Hovedtyper af profiler:

  • Udvikling - beregnet til at underskrive ansøgningen fra udviklingsteamet, et udviklingscertifikat bruges (typenavn iPhone-udvikler: XXXXX);
  • Ad Hoc - beregnet til at underskrive en testapplikation og intern verifikation af QA-afdelingen, udviklerens distributionscertifikat bruges (typenavn iPhone Distribution: XXXXX);
  • App Store - release build til ekstern test via TestFlight og upload til App Store, udviklerens distributionscertifikat bruges.

Ved generering af udviklings- og ad hoc-profiler er det også angivet enhedsliste, hvorpå du kan installere en build, som giver dig mulighed for yderligere at begrænse adgangen for brugere. Der er ingen liste over enheder i App Store-profilen, da adgangskontrol under lukket beta-test håndteres af TestFlight, som vil blive diskuteret senere.

For klarhedens skyld kan du præsentere udviklerens profil i form af en tabel nedenfor. Dette gør det nemmere at forstå, hvilke parametre vi skal bruge til montering, og hvor de skal hentes fra.

Funktioner ved at bygge og levere iOS-applikationer

samling

For at gøre det nemmere at adskille samlinger efter projekt og miljø bruger vi profilnavne som f.eks ${ProjectName}_${Instance}, det vil sige projektnavn + instans (afhænger af applikationsmiljøet: Dev, QA, GD, Staging, Live, og så videre).

Når den importeres til build-serveren, ændrer profilen sit navn til et unikt ID og flyttes til mappen /Users/$Username/Library/MobileDevice/Provisioning Profiles (Hvor $Username svarer til brugerkontonavnet på build-serveren).

Der er to måder at bygge en *.ipa-fil på - legacy (PackageApplication) og moderne (via XcAchive-oprettelse og -eksport). Den første metode anses for at være forældet, da app-filpakkemodulet siden version 8.3 er blevet fjernet fra Xcode-distributionen. For at bruge det skal du kopiere modulet fra den gamle Xcode (version 8.2 og tidligere) til mappen:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/

Og kør derefter kommandoen:

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

Dernæst skal du indsamle *.app-filen for applikationen:

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

Hvor:

-workspace — stien til projektfilen.

-scheme — den anvendte ordning, specificeret i projektet.

-derivedDataPath — sti til at downloade den samlede applikation (*.app).

CODE_SIGN_IDENTITY — navnet på udviklerkontoen, som kan verificeres i nøglering (iPhone-udvikler: XXXX XXXXXXX, uden TeamID i parentes).

Funktioner ved at bygge og levere iOS-applikationer

PROVISIONING_PROFILE — Profil-id til at signere ansøgningen, som kan fås med kommandoen:

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

Hvis applikationen bruger en ekstra profil (for eksempel til push-meddelelser), så i stedet for PROVISIONING_PROFILE angive:

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

Dernæst skal den resulterende *.app-fil pakkes ind i *.ipa. For at gøre dette kan du bruge en kommando som:

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

Denne metode anses dog for at være forældet set fra Apples synspunkt. Det er relevant at få *.ipa ved at eksportere fra applikationsarkivet.

Først skal du samle arkivet med kommandoen:

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

Forskellene ligger i monteringsmetoden og mulighederne SYNCHRONOUS_SYMBOL_PROCESSING, som deaktiverer symbolaflæsning på byggetidspunktet.

Dernæst skal vi generere en fil med eksportindstillinger:

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

Hvor:

$Method — leveringsmetode, svarer til applikationssignaturprofiltypen, dvs. for udvikling vil værdien være udvikling, for Ad Hoc - ad-hoc og for App Store - app-store.

$BundleID — Applikations-id, som er angivet i applikationsindstillingerne. Du kan tjekke med kommandoen: 

defaults read $ProjectDir/Info CFBundleIdentifier

$DevAccName и $ProfileId — Indstillinger for udviklernavn og signaturprofil-id, der blev brugt tidligere og skal matche værdierne i eksportindstillingerne.

$TeamID — ticifret ID i parentes efter udviklerens navn, eksempel: iPhone-udvikler: …… (XXXXXXXXXX); kan tjekkes i nøglering.

Dernæst, ved at bruge eksportkommandoen, får vi den nødvendige *.ipa-fil:

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

Levering

Nu skal den indsamlede fil leveres til slutbrugeren, det vil sige installeret på enheden.

Der er mange tjenester til distribution af udvikling og ad hoc builds, såsom HockeyApp, AppBlade og andre, men i denne artikel vil vi tale om en selvstændig server til distribution af applikationer.

Installation af applikationen til iOS foregår i 2 trin:

  1. Modtagelse af applikationsinstallationsmanifestet gennem Items Service.
  2. Installation af *.ipa-filen i henhold til oplysningerne angivet i manifestet via HTTPS.

Derfor skal vi først generere et installationsmanifest (filtype *.plist) med kommandoen:

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

Som du kan se, indeholder manifestet næsten alle de parametre, der er involveret i opbygningen af ​​applikationen.

Applikationsversion ($AppVersion) kan kontrolleres med kommandoen:

defaults read $ProjectDir/Info CFBundleVersion

Parameter $ipaUrl indeholder et direkte link til at downloade *.ipa-filen. Fra den syvende version af iOS skal applikationen installeres via HTTPS. I den ottende version har manifestets format ændret sig lidt: blokke med indstillinger for applikationsikoner som

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

For at installere applikationen er en simpel HTML-side med et link som dette nok:

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

Til udviklings- og testafdelingernes behov har Plarium skabt sin egen byggeinstallationsapplikation, som giver os:

  • autonomi og uafhængighed,
  • centralisering af adgangskontrol og sikker installation af applikationer gennem "midlertidige" dynamisk oprettede links,
  • udvidelig funktionalitet (det vil sige, at udviklingsteamet om nødvendigt kan integrere manglende funktioner i en eksisterende applikation).

Test

Nu vil vi tale om pre-release test af applikationen ved hjælp af TestFlight.

Påkrævede betingelser for download er typen af ​​App Store-signaturprofil og tilstedeværelsen af ​​genererede API-nøgler.

Der er flere måder at downloade applikationen på:

  • via Xcode (Organisator),
  • via altool,
  • via Application Loader til ældre versioner af Xcode (nu Transporter).

Til automatisk download bruges altool, som også har to autorisationsmetoder:

  • App-specifik adgangskode,
  • API nøgle.

Det er at foretrække at downloade applikationen ved hjælp af API-nøglen.

For at få API-nøglen, gå til link og generere en nøgle. Ud over selve nøglen i *.p8-format skal vi bruge to parametre: IssuerID og KeyID.

Funktioner ved at bygge og levere iOS-applikationer

Importer derefter den downloadede nøgle til build-serveren:

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

Før du uploader applikationen til TestFlight, skal du validere applikationen, det gør vi med kommandoen:

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

hvor apiKey и apiIssuer har feltværdier fra API-nøglegenereringssiden.

Dernæst, efter vellykket validering, indlæser vi applikationen med kommandoen --upload-app med de samme parametre.

Applikationen vil blive testet af Apple inden for en eller to dage og vil derefter blive tilgængelig for eksterne testere: De vil få tilsendt links til installation via e-mail.

En anden måde at downloade en applikation gennem altool er at bruge App-specifik adgangskode.

For at få den app-specifikke adgangskode skal du gå til link og generer det i afsnittet Sikkerhed.

Funktioner ved at bygge og levere iOS-applikationer

Dernæst skal du oprette en build-serverpost i nøglering med denne adgangskode. Fra version 11 af Xcode kan dette gøres med kommandoen:

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

Hvor:

$DeveloperName — navnet på den iOS-udviklerkonto, der bruges til at logge ind på Apple-tjenester.

$AppPswd — genereret app-specifik adgangskode.

Dernæst får vi værdien af ​​asc-provider-parameteren og kontrollerer succesen med adgangskodeimporten med kommandoen:

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

Vi får output:

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

Som du kan se, falder den påkrævede Short Name-værdi (asc-provider) sammen med $TeamID-parameteren, som vi brugte, da vi byggede applikationen.

For at validere og indlæse applikationen i TestFlight skal du bruge kommandoen: 

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

Som en parameterværdi -p du kan tage værdien $AppPswd i ukrypteret (eksplicit) form.

Men, som allerede nævnt, fra et ydelsessynspunkt er det bedre at vælge API Key til altool-autorisation, da forskellige versioner af Xcode har visse problemer ("kan ikke se" nøglering, autorisationsfejl under upload osv.).

Det er alt, faktisk. Jeg ønsker alle involverede succesfulde builds og problemfri udgivelser i App Store.

Kilde: www.habr.com

Tilføj en kommentar