Share via

Criando aplicativos Xamarin para iOS

  • Artigo

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.

Observação

As versões e requisitos com suporte do App Center dão suporte a projetos PCL (Biblioteca de Classes Portátil) e .NET Standard . Consulte Cloud Build Machines para versões do .NET Standard. O App Center não dá suporte a componentes do Repositório de Componentes do Xamarin e aconselhamos usar pacotes NuGet sempre que disponíveis. Se você estiver usando um Componente que não pode ser substituído, entre em contato conosco. Confira ajuda e comentários.

Para começar a criar seu primeiro aplicativo Xamarin iOS, você precisará:

  1. Conecte-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. Configure o projeto ou o workspace do build e o esquema que você deseja criar.

Observação

Para que o aplicativo seja executado em um dispositivo real, o build precisa ser assinado por código 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á conectá-la. Depois que sua conta estiver conectada, selecione o repositório em que o projeto do iOS está localizado. Para configurar um build para um repositório, você precisa de permissão de administrador e pull para ele.

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

Antes do primeiro build, o projeto Xamarin precisa ser configurado.

3.1. Projeto/solução

O App Center detectará automaticamente os arquivos de solução e projeto em seu repositório se eles estiverem localizados dentro do intervalo de análise. Selecione o .sln ou .csproj/.fsproj que você deseja compilar.

Observação

Para obter melhor desempenho, a análise está atualmente limitada a dois níveis de diretório para .sln e quatro níveis de diretório para .csproj/fsproj , incluindo a raiz do repositório.

3.1.1. Compilação do arquivo de solução (.sln)

Em seu código, desabilite projetos Android e UWP para configurações de build destinadas a builds do iOS: acesse os mapeamentos de configuração da solução e, para todos os mapeamentos direcionados ao iPhone e ao iPhoneSimulator, desmarque todos os projetos direcionados a outras plataformas. Essa alteração garantirá que, quando o .sln estiver sendo criado, ele não tentará compilar os outros projetos. Há mais informações de mapeamento de configurações de solução que você pode ler.

3.1.2. Compilação do arquivo de projeto (.csproj/.fsproj)

Para compilar a partir de um arquivo .csproj/.fsproj , todos os projetos referenciados (por exemplo, seu projeto PCL) devem conter a configuração com o mesmo nome do projeto iOS de origem. Portanto, se você executar a configuração de Depuração para o simulador no App Center, seu projeto PCL deverá ter a configuração Depurar|iPhoneSimulator . Caso elas não existam e para evitar erros adicionais, adicionamos essas configurações antes de criar seus projetos. Essas configurações têm configurações padrão básicas somente para Depuração e Versão.

3.2. Configuração

Selecione a configuração com a qual você deseja compilar. As configurações são detectadas automaticamente dependendo do arquivo de origem escolhido na etapa anterior.

3.3. Versão mono

O App Center permite o uso de diferentes ambientes Mono agrupados com o respectivo SDK do Xamarin.iOS para seu build para manter a compatibilidade com versões anteriores ao liberar um suporte para novos recursos. O Mono padrão para uma nova configuração de branch será o mais recente estável. Você pode optar por usar um dos ambientes Mono anteriores para criar versões mais antigas de estruturas ou bibliotecas. Ao escolher uma versão diferente do Mono, você verá a versão do SDK do Xamarin.iOS que é agrupada com ela. Para acompanhar as atualizações de versão do SDK do Xamarin, você pode ler postagens no blog de versão do Xamarin.

3.3.1. Versão do .NET

A versão adequada do .NET será selecionada automaticamente com base na versão do Xamarin.iOS usada para build e não poderá ser substituída. Você pode exibir o mapeamento do Xamarin.iOS para o .NET usado por nossos serviços na tabela abaixo:

Xamarin.iOS .NET
13.20 3.1.401
14.0 3.1.401
14,2 3.1.401
14,4 3.1.401
14.6 5.0.100
14,8 5.0.100
14.10 5.0.100
14.14 5.0.100
14.16 5.0.100
14.20 5.0.100
15 5.0.100
15.2 5.0.100
15,4 5.0.100
15.6 5.0.100
15.8 5.0.100
15.10 5.0.100
15.12 5.0.100
16,0 5.0.100
16.0 (.NET 6) 6.0.405
16.1 6.0.405
16,2 6.0.405

3.4. Versão do Xcode

As versões com suporte no momento do Xamarin exigem o Xcode 11.7 ou superior

3.5. Gatilhos de build

Por padrão, um novo build é disparado sempre que um desenvolvedor envia por push para um branch configurado. Se preferir disparar um novo build manualmente, você poderá alterar essa configuração no painel de configuração.

3.6. Build do simulador

As compilações do simulador só podem ser executadas em simuladores e não podem ser instaladas no dispositivo, no entanto, as compilações são concluídas mais rapidamente do que as compilações do dispositivo. Se o build não for um build de simulador, você precisará carregar arquivos de assinatura de código na próxima etapa.

3.7. Incrementar número de build

Quando habilitado, o CFBundleVersion no Info.plist do aplicativo é incrementado automaticamente para cada build. A alteração ocorre antes do build e não será confirmada no repositório.

3.8. Assinatura de código

Uma compilação de dispositivo bem-sucedida produzirá um arquivo IPA. Para instalar o build em um dispositivo, ele precisa ser assinado com um perfil de provisionamento e um certificado válidos. Para assinar os builds produzidos de um branch, 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. Você pode ler mais sobre assinatura de código e provisionamento de dispositivos de aplicativos Xamarin iOS na documentação do Xamarin.

Aplicativos com extensões de aplicativo ou watchOS exigem que um perfil de provisionamento adicional por extensão seja assinado.

Observação

Há um problema existente ao executar nuget restore em projetos que contêm aplicativos watchOS do Xamarin. A criação de um aplicativo watchOS no App Center sem uma solução alternativa resultará em um erro:

Project <project> is not compatible with xamarinios10 (Xamarin.iOS,Version=v1.0) / win-x86. Project <project> supports: xamarinwatchos10 (Xamarin.WatchOS,Version=v1.0).

Para criar aplicativos watchOS no App Center, é necessária uma solução alternativa. Dentro do projeto iOS que contém, que faz referência ao aplicativo Watch, uma linha adicional deve ser incluída:

<ReferenceOutputAssembly>False</ReferenceOutputAssembly>

Exemplo de referência de WatchApp com solução alternativa:

    <ProjectReference Include="..\MyWatchApp\MyWatchApp.csproj">
      <Project>{59EB034F-3D29-43A5-B89F-124879504771}</Project>
      <Name>MyWatchApp</Name>
      <IsWatchApp>True</IsWatchApp>
      <ReferenceOutputAssembly>False</ReferenceOutputAssembly>
    </ProjectReference>

3.9. Inicie sua compilação bem-sucedida em um dispositivo real

Use o arquivo .ipa recém-produzido para testar se o aplicativo é iniciado em um dispositivo real. O teste de inicialização adiciona cerca de 10 minutos a mais ao tempo de compilação. Talvez você queira marcar guia mais abrangente sobre como testar seus builds

3.10. Restauração do NuGet

Se o arquivo deNuGet.config for verificado para o repositório e estiver sentado ao lado do .sln ou do nível raiz do repositório, o App Center restaurará seus feeds NuGet privados quando eles forem adicionados, conforme mostrado no exemplo abaixo. As credenciais podem ser adicionadas com segurança usando variáveis de ambiente:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="nuget" value="https://api.nuget.org/v3/index.json" />
    <add key="MyGet" value="https://www.myget.org/F/MyUsername/api/v2/index.json" />
    <add key="MyAuthNuget" value="https://nuget.example.com/v2/index.json" />
  </packageSources>
  <activePackageSource>
    <add key="All" value="(Aggregate source)" />
  </activePackageSource>
  <packageSourceCredentials>
    <MyAuthNuget>
      <add key="Username" value="$USER_VARIABLE" />
      <add key="ClearTextPassword" value="$PASSWORD_VARIABLE" />
    </MyAuthNuget>
  </packageSourceCredentials>
</configuration>

Se você tiver configurações complexas e precisar de mais informações, consulte Configurando o comportamento do NuGet.

3.11. 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 tiver sido disparado, ele poderá estar nos seguintes estados:

  • enfileirado – o build está em uma fila aguardando a liberação de recursos.
  • building – o build está executando e executando as tarefas predefinidas.
  • bem-sucedido – o build foi concluído com êxito.
  • falha – o build foi interrompido devido a uma falha. Você pode solucionar o que deu errado baixando e inspecionando o log 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 obter um build concluído (com êxito ou 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 solucionar problemas e entender em qual etapa e por que o build falhou.

4.2. O aplicativo (.ipa ou .app)

O .ipa é um arquivo morto do aplicativo iOS que contém o aplicativo iOS. Se o build tiver sido assinado corretamente, o .ipa poderá ser instalado em um dispositivo real, correspondente ao perfil de provisionamento usado ao assinar. Há mais detalhes sobre assinatura e distribuição de código com o App Center.

Se o aplicativo for um build de simulador, você poderá executar o .app arquivo em um simulador, mas não poderá usá-lo em um dispositivo real.

4.3. Os arquivos de símbolo (.dsym)

Os arquivos de símbolo são gerados apenas para builds de dispositivo. Os arquivos .dsym contêm os símbolos de depuração para o aplicativo.

  • Se tiver integrado anteriormente o SDK do App Center ao seu aplicativo com o 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ê tiver integrado anteriormente outro SDK para relatórios 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.