Criando aplicativos Objective-C ou Swift para iOS
Importante
O Visual Studio App Center está programado para ser desativado em 31 de março de 2025. Embora você possa continuar a usar o Visual Studio App Center até que ele seja totalmente desativado, há várias alternativas recomendadas para as quais você pode considerar a migração.
Para criar seu primeiro aplicativo iOS nativo, você deve executar as seguintes ações:
- Conectar-se à sua conta de serviço do repositório (GitHub, Bitbucket, VSTS, Azure DevOps)
- Selecione um repositório e um branch onde seu aplicativo reside
- Configurar o projeto ou o workspace do build e o esquema que você deseja criar
Observação
Para executar o aplicativo em um dispositivo real, o build deve ser assinado com um perfil de provisionamento válido e um certificado.
Se você ainda não se conectou anteriormente à sua conta de serviço do repositório, deverá autorizar a conexão. Depois que sua conta estiver conectada, selecione o repositório em que o projeto do iOS está localizado. O App Center exige que sua conta tenha permissão Administração e Pull para configurar um build para um repositório.
Depois de selecionar um repositório, selecione o branch que você deseja criar. Por padrão, todos os branches ativos serão listados.
Configure seu projeto do iOS antes do primeiro build.
Para uma configuração de build, um projeto Xcode ou um workspace Xcode e um esquema compartilhado são necessários. O App Center detecta automaticamente os projetos, workspaces e esquemas compartilhados (desde que os esquemas estejam na pasta correta) em seu branch. Selecione o projeto ou o workspace que você deseja criar e o esquema correspondente.
Se nenhum esquema for encontrado, verifique se o esquema desejado é compartilhado e se o contêiner é o projeto ou workspace selecionado. Você também deve confirmar se essas alterações estão verificadas no branch que você está configurando.
Tenha em mente que você não pode exportar um .xcscheme
arquivo e colocá-lo em qualquer lugar no projeto. Ele deve estar na xcshareddata/xcschemes/
pasta . Verifique se esse caminho não está no .gitignore
arquivo.
Selecione a versão do Xcode na qual executar o build.
Por padrão, um novo build é disparado sempre que um desenvolvedor envia por push para um branch configurado. Esse processo é chamado de "Integração Contínua". Se você preferir disparar um novo build manualmente, poderá alterar essa configuração na configuração de build.
Quando habilitado, o CFBundleVersion
Info.plist
no do aplicativo é incrementado automaticamente para cada build. A alteração ocorre antes do build e não será confirmada em seu repositório.
Observação
Para fazer o número de build incrementar funcionar, nomeie o .plist file
como *Info.plist
tal como Production-Info.plist
.
Se o esquema selecionado tiver uma ação de teste com um destino de teste selecionado, você poderá configurar os testes a serem executados como parte de cada build. No momento, o App Center pode executar testes de unidade XCTest.
A criação de um aplicativo iOS para dispositivos reais requer a assinatura com credenciais válidas. Para assinar builds no App Center, habilite a assinatura de código no painel de configuração e carregue um perfil de provisionamento (.mobileprovision
) e um certificado válido (.p12
), juntamente com a senha do certificado.
As configurações em seu projeto Xcode devem ser compatíveis com os arquivos que você está carregando. Você pode ler mais sobre a assinatura de código na documentação oficial do Apple Developer.
Aplicativos com extensões de aplicativo ou watchOS exigem que um perfil de provisionamento adicional por extensão seja assinado.
Use o arquivo recém-produzido .ipa
para testar se o aplicativo começa em um dispositivo real. Iniciar em um dispositivo real adicionará aproximadamente mais 10 minutos ao tempo total de compilação. Leia mais sobre como configurar testes de inicialização.
O App Center examina o branch selecionado e, se encontrar um Podfile, ele executará automaticamente uma pod install
etapa no início de cada build. Esta etapa garantirá que todas as dependências sejam instaladas.
Aviso
Se o repositório já contiver uma pasta /Pods , o App Center pressupõe que você fez check-in nos pods no repositório e não executará pod install
mais . Se você remover ou modificar a pasta /Pods , talvez seja necessário salvar novamente a configuração de Build manualmente usando Save
ou Save and Build
para que a atualização entre em vigor.
Você pode configurar cada build bem-sucedido de um branch a ser distribuído para um grupo de distribuição criado anteriormente. Você pode adicionar um novo grupo de distribuição de dentro da seção Distribuir. Há sempre um grupo de distribuição padrão chamado "Colaboradores" que inclui todos os usuários que têm acesso ao aplicativo.
Depois de salvar a configuração, um novo build será iniciado automaticamente.
Depois que um build é disparado, ele pode estar nos seguintes estados:
- enfileirado – o build é enfileirado aguardando a liberação de recursos.
- compilação – o build está executando as tarefas predefinidas.
- bem-sucedido – o build foi concluído e foi bem-sucedido.
- falha - o build foi concluído, mas falhou. Você pode solucionar o que deu errado inspecionando os logs de build.
- cancelado – o build foi cancelado por uma ação do usuário ou atingiu o tempo limite
Para um build concluído (bem-sucedido ou com falha), baixe os logs para entender mais sobre como o build foi. O App Center fornece um arquivo morto com os seguintes arquivos:
|-- 1_build.txt (this is the general build log)
|-- build (this folder contains a separate log file for each build step)
|-- <build-step-1> (e.g. 2_Get Sources.txt)
|-- <build-step-2> (e.g. 3_Pod install.txt)
|--
|-- <build-step-n> (e.g. n_Post Job Cleanup.txt)
Os logs específicos da etapa de build (localizados no build/
diretório do arquivo morto) são úteis para solução de problemas e compreensão em qual etapa e por que o build falhou.
O .ipa
arquivo é um arquivo de arquivo de aplicativo de dispositivo iOS que contém o aplicativo iOS.
- Builds não assinados não produzirão um
.ipa
arquivo. O artefato de um build não assinado é o.xcarchive
arquivo que pode ser usado para gerar um.ipa
arquivo com o organizador do Xcode Archives. - Se o build for assinado corretamente, o
.ipa
arquivo poderá ser instalado em um dispositivo real correspondente ao perfil de provisionamento usado ao assinar. Mais detalhes sobre assinatura e distribuição de código com o App Center podem ser encontrados na documentação de assinatura de código do iOS do App Center. - Se o build não tiver sido assinado, o
.ipa
arquivo poderá ser assinado pelo desenvolvedor (por exemplo, usando localmente codesign) ou usado para outras finalidades (por exemplo, carregar no serviço de teste para teste de interface do usuário em dispositivos reais ou executar no simulador).
Os .dsym
arquivos contêm os símbolos de depuração para o aplicativo.
- Se você tiver integrado anteriormente o SDK do App Center em seu aplicativo ao módulo de relatório de falhas habilitado, o serviço de relatório de falhas exigirá esse
.dsym
arquivo para que um build exiba relatórios de falha legívels (simbólicos). - Se você já integrou outro SDK para fins de relatório de falhas em seu aplicativo (por exemplo, HockeyApp SDK), o serviço correspondente exigirá que o
.dsym
arquivo exiba relatórios de falhas legíveis por humanos.
Tenha em mente que os .dsym
arquivos não são alterados após a assinatura do .ipa
código. Se você decidir assinar o build mais tarde, o .dsym
gerado antes da assinatura de código ainda será válido.
Os detalhes da versão do Xcode do computador de build são atualizados sempre que uma nova versão do Xcode é adicionada. Estamos de olho nas versões mais recentes lançadas pela Apple e incluí-las o mais rápido possível nas VMs usadas para executar as compilações.