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.

Saiba mais sobre linhas do tempo e alternativas de suporte.

Para criar seu primeiro aplicativo iOS nativo, você deve executar as seguintes ações:

1. Conectar-se à sua conta de serviço do repositório (GitHub, Bitbucket, VSTS, Azure DevOps)
2. Selecione um repositório e um branch onde seu aplicativo reside
3. 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.

1. Vinculando seu repositório

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.

2. Selecionando uma ramificação

Depois de selecionar um repositório, selecione o branch que você deseja criar. Por padrão, todos os branches ativos serão listados.

3. Configurando seu primeiro build

Configure seu projeto do iOS antes do primeiro build.

3.1 Projeto/workspace e esquema

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.

3.2. Versão Xcode

Selecione a versão do Xcode na qual executar o build.

3.3. Gatilhos de 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.

3.4. Incrementar número de build

Quando habilitado, o CFBundleVersionInfo.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.

3.5. Testes

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.

3.6. Assinatura de código

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.

3.7. Iniciar sua compilação bem-sucedida em um dispositivo real

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.

3.8. CocoaPods

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 installmais . 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.

3.9. Distribuir para um grupo de distribuição

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.

4. Resultados de build

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

4.1. Logs de build

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.

4.2. O aplicativo (.ipa)

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).

4.3. O arquivo de símbolos (.dsym)

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 .ipacódigo. Se você decidir assinar o build mais tarde, o .dsym gerado antes da assinatura de código ainda será válido.

Versões e requisitos com suporte

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.