Recursos de construção e entrega de aplicativos iOS

Neste artigo, compartilhamos a experiência de montagem e entrega de aplicativos iOS aos usuários, que o estúdio Plarium Krasnodar acumulou no processo de depuração de CI/CD.

Treinamento

Todas as pessoas que estão de uma forma ou de outra envolvidas no desenvolvimento de aplicativos para dispositivos Apple já apreciaram a polêmica conveniência da infraestrutura. As dificuldades são encontradas em todos os lugares: desde o menu de perfil do desenvolvedor até as ferramentas de depuração e construção.

Existem muitos artigos sobre o “básico” na Internet, por isso tentaremos destacar o principal. Aqui está o que você precisa para construir seu aplicativo com sucesso:

• conta de desenvolvedor;
• um dispositivo baseado em macOS que atua como servidor de compilação;
• gerado certificado de desenvolvedor, que será posteriormente utilizado para assinar o pedido;
• aplicativo criado com exclusivo ID (deve-se ressaltar a importância do Bundle Identifier, pois o uso do wildcard ID impossibilita a utilização de muitas funções da aplicação, por exemplo: Domínios Associados, Push Notifications, Apple Sign In e outros);
• perfil assinaturas de aplicativos.

Um certificado de desenvolvedor deve ser gerado via Keychain em qualquer dispositivo macOS. O tipo de certificado é muito importante. Dependendo do ambiente do aplicativo (Dev, QA, Staging, Production), ele será diferente (Desenvolvimento ou Distribuição), assim como o tipo de perfil de assinatura do aplicativo.

Principais tipos de perfis:

• Desenvolvimento - destinado à assinatura da aplicação pela equipe de desenvolvimento, é utilizado um certificado de Desenvolvimento (nome do tipo iPhone Developer: XXXXX);
• Ad Hoc - destinado à assinatura de uma aplicação de teste e verificação interna pelo departamento de QA, é utilizado o certificado de Distribuição do desenvolvedor (nome do tipo iPhone Distribution: XXXXX);
• App Store - versão de lançamento para testes externos via TestFlight e upload para a App Store, é usado o certificado de distribuição do desenvolvedor.

Ao gerar perfis de Desenvolvimento e Ad Hoc, também é indicado lista de dispositivos, no qual você pode instalar uma compilação, que permite restringir ainda mais o acesso dos usuários. Não há lista de dispositivos no perfil da App Store, pois o controle de acesso durante o teste beta fechado é feito pelo TestFlight, que será discutido mais adiante.

Para maior clareza, você pode apresentar o perfil do desenvolvedor na forma de tabela abaixo. Isso torna mais fácil entender quais parâmetros precisamos para a montagem e onde obtê-los.

montagem

Para facilitar a separação de montagens por projeto e ambiente, usamos nomes de perfis como ${ProjectName}_${Instance}, ou seja, nome do projeto + instância (depende do ambiente da aplicação: Dev, QA, GD, Staging, Live e assim por diante).

Quando importado para o servidor de compilação, o perfil muda seu nome para um ID exclusivo e é movido para a pasta /Users/$Username/Library/MobileDevice/Provisioning Profiles (onde $Username corresponde ao nome da conta de usuário do servidor de compilação).

Existem duas maneiras de construir um arquivo *.ipa - legado (PackageApplication) e moderno (por meio da criação e exportação do XcAchive). O primeiro método é considerado obsoleto, pois desde a versão 8.3 o módulo de empacotamento de arquivos do aplicativo foi removido da distribuição Xcode. Para utilizá-lo, você precisa copiar o módulo do Xcode antigo (versão 8.2 e anterior) para a pasta:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/

E então execute o comando:

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

Em seguida, você precisa coletar o arquivo *.app do aplicativo:

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

Em que:

-workspace — caminho para o arquivo do projeto.

-scheme — o regime utilizado, especificado no projecto.

-derivedDataPath — caminho para baixar o aplicativo montado (*.app).

CODE_SIGN_IDENTITY — o nome da conta do desenvolvedor, que pode ser verificada no Keychain (desenvolvedor do iPhone: XXXX XXXXXXX, sem TeamID entre colchetes).

PROVISIONING_PROFILE — ID do perfil para assinatura do aplicativo, que pode ser obtido com o comando:

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

Se o aplicativo usar um perfil adicional (por exemplo, para notificações push), então, em vez de PROVISIONING_PROFILE indicar:

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

Em seguida, o arquivo *.app resultante deve ser empacotado em *.ipa. Para fazer isso, você pode usar um comando como:

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

No entanto, este método é considerado obsoleto do ponto de vista da Apple. É relevante obter *.ipa exportando do arquivo da aplicação.

Primeiro você precisa coletar o arquivo com o comando:

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

As diferenças estão no método de montagem e nas opções SYNCHRONOUS_SYMBOL_PROCESSING, que desativa o descarregamento de símbolos no momento da construção.

Em seguida precisamos gerar um arquivo com configurações de exportação:

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

Em que:

$Method — método de entrega, corresponde ao tipo de perfil de assinatura da aplicação, ou seja, para Desenvolvimento o valor será desenvolvimento, para Ad Hoc - ad-hoc, e para App Store - app-store.

$BundleID — ID do aplicativo, especificado nas configurações do aplicativo. Você pode verificar com o comando:

defaults read $ProjectDir/Info CFBundleIdentifier

$DevAccName и $ProfileId — configurações de nome do desenvolvedor e ID do perfil de assinatura que foram usadas anteriormente e devem corresponder aos valores nas configurações de exportação.

$TeamID — ID de dez dígitos entre colchetes após o nome do desenvolvedor, exemplo: iPhone Developer: …… (XXXXXXXX); pode ser verificado no Keychain.

A seguir, usando o comando export, obtemos o arquivo *.ipa necessário:

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

Entrega

Agora o arquivo coletado precisa ser entregue ao usuário final, ou seja, instalado no dispositivo.

Existem muitos serviços para distribuição de compilações de Desenvolvimento e Ad Hoc, como HockeyApp, AppBlade e outros, mas neste artigo falaremos sobre um servidor autônomo para distribuição de aplicativos.

A instalação do aplicativo para iOS ocorre em 2 etapas:

1. Recebendo o manifesto de instalação do aplicativo por meio do Serviço de Itens.
2. Instalação do arquivo *.ipa conforme informações especificadas no manifesto via HTTPS.

Assim, primeiro precisamos gerar um manifesto de instalação (tipo de arquivo *.plist) com o comando:

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

Como você pode ver, o manifesto contém quase todos os parâmetros envolvidos na construção do aplicativo.

Versão do aplicativo ($AppVersion) pode ser verificado com o comando:

defaults read $ProjectDir/Info CFBundleVersion

Parâmetro $ipaUrl contém um link direto para baixar o arquivo *.ipa. A partir da sétima versão do iOS, o aplicativo deverá ser instalado via HTTPS. Na oitava versão, o formato do manifesto mudou um pouco: blocos com configurações para ícones de aplicativos como

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

Assim, para instalar o aplicativo, basta uma simples página HTML com um link como este:

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

Para as necessidades dos departamentos de desenvolvimento e testes, a Plarium criou seu próprio aplicativo de instalação de build, que nos oferece:

• autonomia e independência,
• centralização do controle de acesso e instalação segura de aplicações através de links “temporários” criados dinamicamente,
• funcionalidade expansível (ou seja, a equipe de desenvolvimento, se necessário, pode integrar funções ausentes em um aplicativo existente).

Teste

Agora falaremos sobre o teste de pré-lançamento do aplicativo usando TestFlight.

As condições obrigatórias para download são o tipo de perfil de assinatura da App Store e a presença de chaves API geradas.

Existem várias maneiras de baixar o aplicativo:

• via Xcode (Organizador),
• via altool,
• via Application Loader para versões mais antigas do Xcode (agora Transporter).

Para download automático, é utilizado o altool, que também possui dois métodos de autorização:

• Senha específica do aplicativo,
• Chave API.

É preferível baixar o aplicativo usando a chave API.

Para obter a chave API, vá para link e gerar uma chave. Além da própria chave no formato *.p8, precisaremos de dois parâmetros: IssuerID e KeyID.

Em seguida, importe a chave baixada para o servidor de compilação:

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

Antes de enviar a aplicação para TestFlight, é necessário validar a aplicação, fazemos isso com o comando:

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

Onde apiKey и apiIssuer possuem valores de campo da página de geração de chave de API.

A seguir, após a validação bem-sucedida, carregamos o aplicativo com o comando --upload-app com os mesmos parâmetros.

O aplicativo será testado pela Apple dentro de um ou dois dias e então ficará disponível para testadores externos: eles receberão links para instalação por e-mail.

Outra maneira de baixar um aplicativo através do altool é usar a senha específica do aplicativo.

Para obter a senha específica do aplicativo, você precisa acessar link e gere-o na seção Segurança.

A seguir, você deve criar um registro do servidor de construção no Keychain com esta senha. A partir da versão 11 do Xcode isso pode ser feito com o comando:

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

Em que:

$DeveloperName — o nome da conta de desenvolvedor iOS usada para fazer login nos serviços Apple.

$AppPswd – senha específica do aplicativo gerada.

A seguir, obtemos o valor do parâmetro asc-provider e verificamos o sucesso da importação da senha com o comando:

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

Obtemos a saída:

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

Como você pode ver, o valor do nome abreviado necessário (asc-provider) coincide com o parâmetro $TeamID que usamos ao construir o aplicativo.

Para validar e carregar a aplicação no TestFlight, use o comando:

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

Como valor de parâmetro -p você pode pegar o valor $AppPswd na forma não criptografada (explícita).

Porém, como já mencionado, do ponto de vista de desempenho, é melhor escolher a API Key para autorização do altool, pois diferentes versões do Xcode apresentam certos problemas (“não vê” Keychain, erros de autorização durante o upload, etc.).

Isso é tudo, na verdade. Desejo a todos os envolvidos construções bem-sucedidas e lançamentos sem problemas na App Store.

Fonte: habr.com