iOS-sovellusten rakentamisen ja toimituksen ominaisuudet

Tässä artikkelissa jaamme kokemukset iOS-sovellusten kokoamisesta ja toimittamisesta käyttäjille, joita Plarium Krasnodar -studio on kerännyt CI/CD-virheenkorjausprosessissa.

Koulutus

Jokainen Apple-laitteiden sovellusten kehittämisessä tavalla tai toisella mukana oleva henkilö on jo arvostanut infrastruktuurin kiistanalaista mukavuutta. Vaikeuksia löytyy kaikkialta: kehittäjäprofiilivalikosta virheenkorjaus- ja rakennustyökaluihin.

Internetissä on paljon artikkeleita "perusasioista", joten yritämme korostaa pääasiaa. Tässä on mitä tarvitset rakentaaksesi sovelluksesi onnistuneesti:

• kehittäjätili;
• macOS-pohjainen laite, joka toimii koontipalvelimena;
• luotu kehittäjäsertifikaatti, jota käytetään edelleen hakemuksen allekirjoittamiseen;
• luotu sovellus ainutlaatuisella ID (Bundle Identifierin merkitys tulee huomioida, koska jokerimerkkitunnuksen käyttö tekee mahdottomaksi käyttää monia sovelluksen toimintoja, esimerkiksi: Associated Domains, Push Notifications, Apple Sign In ja muut);
• profiili sovelluksen allekirjoitukset.

Kehittäjävarmenne on luotava Keychainin kautta millä tahansa macOS-laitteella. Sertifikaatin tyyppi on erittäin tärkeä. Sovellusympäristöstä riippuen (kehittäjä, laadunvarmistus, vaiheistus, tuotanto) se vaihtelee (kehitys tai jakelu), samoin kuin sovelluksen allekirjoitusprofiilin tyyppi.

Tärkeimmät profiilityypit:

• Kehitys - tarkoitettu kehitysryhmän hakemuksen allekirjoittamiseen, käytetään kehityssertifikaattia (tyyppinimi iPhone Developer: XXXXX);
• Ad Hoc - tarkoitettu testisovelluksen allekirjoittamiseen ja laadunvarmistusosaston sisäiseen tarkastukseen, käytetään kehittäjän jakeluvarmennetta (tyypin nimi iPhone Distribution: XXXXX);
• App Store – julkaisuversio ulkoista testausta varten TestFlightin kautta ja lataamiseen App Storeen, käytetään kehittäjän jakeluvarmennetta.

Kehitys- ja Ad Hoc -profiileja luotaessa se ilmoitetaan myös laiteluettelo, johon voit asentaa koontiversion, jonka avulla voit edelleen rajoittaa käyttäjien pääsyä. App Store -profiilissa ei ole luetteloa laitteista, koska pääsynvalvonta suljetun beta-testauksen aikana on TestFlightilla, josta keskustellaan myöhemmin.

Selvyyden vuoksi voit esittää kehittäjän profiilin alla olevan taulukon muodossa. Näin on helpompi ymmärtää, mitä parametreja tarvitsemme kokoonpanoon ja mistä ne saa.

kokoonpano

Jotta kokoonpanojen erottaminen projektin ja ympäristön mukaan olisi helpompaa, käytämme profiilinimiä, kuten ${ProjectName}_${Instance}, eli projektin nimi + ilmentymä (riippuu sovellusympäristöstä: Dev, QA, GD, Staging, Live ja niin edelleen).

Kun profiili tuodaan koontipalvelimelle, se muuttaa nimensä yksilölliseksi tunnukseksi ja siirretään kansioon /Users/$Username/Library/MobileDevice/Provisioning Profiles (Missä $Username vastaa koontipalvelimen käyttäjätilin nimeä).

On kaksi tapaa luoda *.ipa-tiedosto - vanha (PackageApplication) ja moderni (XcAchiven luomisen ja viennin kautta). Ensimmäistä menetelmää pidetään vanhentuneena, koska versiosta 8.3 lähtien sovellustiedoston pakkausmoduuli on poistettu Xcode-jakelusta. Käyttääksesi sitä sinun on kopioitava moduuli vanhasta Xcodesta (versio 8.2 ja aikaisempi) kansioon:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/

Ja sitten suorita komento:

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

Seuraavaksi sinun on kerättävä sovelluksen *.app-tiedosto:

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

Missä:

-workspace — polku projektitiedostoon.

-scheme — hankkeessa määritelty suunnitelma.

-derivedDataPath — polku kootun sovelluksen lataamiseen (*.app).

CODE_SIGN_IDENTITY — kehittäjätilin nimi, joka voidaan vahvistaa Keychainissa (iPhone Developer: XXXX XXXXXXX, ilman TeamID:tä suluissa).

PROVISIONING_PROFILE — Profiilitunnus hakemuksen allekirjoittamista varten, jonka saa komennolla:

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

Jos sovellus käyttää lisäprofiilia (esimerkiksi push-ilmoituksia varten), sen sijaan PROVISIONING_PROFILE osoittaa:

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

Seuraavaksi tuloksena oleva *.app-tiedosto tulee pakata *.ipa-tiedostoon. Voit tehdä tämän käyttämällä komentoa, kuten:

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

Tätä menetelmää pidetään kuitenkin Applen näkökulmasta vanhentuneena. On tärkeää hankkia *.ipa viemällä tiedosto sovellusarkistosta.

Ensin sinun on kerättävä arkisto komennolla:

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

Erot ovat asennustavassa ja vaihtoehdoissa SYNCHRONOUS_SYMBOL_PROCESSING, joka estää symbolien purkamisen rakennusaikana.

Seuraavaksi meidän on luotava tiedosto, jossa on vientiasetukset:

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

Missä:

$Method — toimitustapa, vastaa sovelluksen allekirjoitusprofiilin tyyppiä, eli kehitykselle arvo on kehitys, Ad Hocille - ad-hoc ja App Storelle - sovelluskauppa.

$BundleID — Sovellustunnus, joka määritetään sovelluksen asetuksissa. Voit tarkistaa komennolla:

defaults read $ProjectDir/Info CFBundleIdentifier

$DevAccName и $ProfileId — kehittäjän nimen ja allekirjoitusprofiilin tunnusasetukset, joita käytettiin aiemmin ja joiden on vastattava vientiasetusten arvoja.

$TeamID — kymmennumeroinen tunnus suluissa kehittäjän nimen jälkeen, esimerkki: iPhone Developer: …… (XXXXXXXXXX); voidaan tarkistaa Avainnipussa.

Seuraavaksi saamme vientikomennolla tarvittavan *.ipa-tiedoston:

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

Toimitus

Nyt kerätty tiedosto on toimitettava loppukäyttäjälle, eli asennettava laitteelle.

Kehitys- ja Ad Hoc -koontiversioiden jakeluun on monia palveluita, kuten HockeyApp, AppBlade ja muut, mutta tässä artikkelissa puhumme erillisestä palvelimesta sovellusten jakelua varten.

Sovelluksen asentaminen iOS:lle tapahtuu kahdessa vaiheessa:

1. Sovelluksen asennusluettelon vastaanottaminen Item Servicen kautta.
2. *.ipa-tiedoston asennus luettelossa määritettyjen tietojen mukaan HTTPS:n kautta.

Siksi meidän on ensin luotava asennusluettelo (tiedostotyyppi *.plist) komennolla:

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

Kuten näette, luettelo sisältää melkein kaikki sovelluksen rakentamiseen liittyvät parametrit.

Sovellusversio ($AppVersion) voidaan tarkistaa komennolla:

defaults read $ProjectDir/Info CFBundleVersion

Parametri $ipaUrl sisältää suoran linkin *.ipa-tiedoston lataamiseen. iOS:n seitsemännestä versiosta alkaen sovellus on asennettava HTTPS:n kautta. Kahdeksannessa versiossa manifestin muoto on muuttunut hieman: lohkot sovelluskuvakkeiden asetuksilla, kuten

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

Siten sovelluksen asentamiseen riittää yksinkertainen HTML-sivu, jossa on tällainen linkki:

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

Kehitys- ja testausosastojen tarpeisiin Plarium on luonut oman build-asennussovelluksen, joka antaa meille:

• autonomia ja riippumattomuus,
• kulunvalvonnan keskittäminen ja sovellusten turvallinen asennus "väliaikaisten" dynaamisesti luotujen linkkien kautta,
• laajennettavissa oleva toiminnallisuus (eli kehitystiimi voi tarvittaessa integroida puuttuvat toiminnot olemassa olevaan sovellukseen).

Testaus

Nyt puhumme sovelluksen julkaisua edeltävästä testauksesta TestFlight.

Latauksen vaadittavat ehdot ovat App Storen allekirjoitusprofiilin tyyppi ja luotujen API-avainten olemassaolo.

Sovelluksen lataamiseen on useita tapoja:

• Xcoden (järjestäjä) kautta,
• altoolin kautta,
• Application Loader -sovelluksen kautta vanhemmille Xcode-versioille (nyt Transporter).

Automaattiseen lataukseen käytetään altoolia, jolla on myös kaksi valtuutusmenetelmää:

• Sovelluskohtainen salasana,
• API-avain.

On suositeltavaa ladata sovellus API-avaimella.

Saat API-avaimen siirtymällä osoitteeseen linkki ja luo avaimen. Itse *.p8-muodossa olevan avaimen lisäksi tarvitsemme kaksi parametria: IssuerID ja KeyID.

Tuo seuraavaksi ladattu avain koontipalvelimeen:

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

Ennen kuin lataat sovelluksen TestFlightiin, sinun on vahvistettava sovellus, teemme tämän komennolla:

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

jossa apiKey и apiIssuer niillä on kenttäarvot API-avaimen luontisivulta.

Seuraavaksi onnistuneen validoinnin jälkeen lataamme sovelluksen komennolla --upload-app samoilla parametreilla.

Apple testaa sovelluksen yhden tai kahden päivän kuluessa, ja se tulee sitten ulkopuolisten testaajien saataville: heille lähetetään sähköpostilinkkejä asennusta varten.

Toinen tapa ladata sovellus altoolin kautta on käyttää sovelluskohtaista salasanaa.

Saadaksesi sovelluskohtaisen salasanan sinun on mentävä osoitteeseen linkki ja luo se Suojaus-osiossa.

Seuraavaksi sinun tulee luoda koontipalvelintietue Keychainissa tällä salasanalla. Xcoden versiosta 11 alkaen tämä voidaan tehdä komennolla:

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

Missä:

$DeveloperName — sen iOS-kehittäjätilin nimi, jolla kirjaudutaan Applen palveluihin.

$AppPswd — luotu sovelluskohtaisella salasanalla.

Seuraavaksi saamme asc-provider-parametrin arvon ja tarkistamme salasanan tuonnin onnistumisen komennolla:

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

Saamme tuloksen:

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

Kuten näet, vaadittu Short Name -arvo (asc-provider) osuu yhteen $TeamID-parametrin kanssa, jota käytimme sovelluksen rakentamisessa.

Tarkista ja lataa sovellus TestFlightiin käyttämällä komentoa:

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

Parametriarvona -p voit ottaa arvon $AppPswd salaamattomassa (eksplisiittisessä) muodossa.

Kuten jo mainittiin, suorituskyvyn kannalta on kuitenkin parempi valita API-avain altool-valtuutukseen, koska Xcoden eri versioissa on tiettyjä ongelmia ("ei näe" avainnippua, valtuutusvirheet latauksen aikana jne.).

Siinä kaikki, oikeastaan. Toivotan kaikille mukana olleille onnistuneita koontiversioita ja ongelmattomia julkaisuja App Storessa.

Lähde: will.com