Build iOS na Unity: Precisa de Mac? Caminhos Reais

Quem procura "unity ios build on windows" quer uma resposta curta, então aqui vai: a Unity no Windows gera o projeto Xcode do seu jogo, mas compilar, assinar e enviar para a App Store exige macOS, porque o Xcode só roda em Mac. Não existe atalho oficial que pule essa etapa. O que existe são caminhos para ter um Mac sem comprar um Mac novo.

Aqui você vê o que cada parte do processo faz, quatro caminhos reais (Mac usado, Mac na nuvem, Unity Build Automation e CI com runner macOS), quanto cada um custa onde há preço oficial, e o que a Apple exige de conta e certificado em qualquer um deles.

A resposta curta: precisa de macOS

A própria documentação da Unity sobre configuração de ambiente iOS diz que builds locais exigem um Mac porque o Xcode só está disponível para macOS. A mesma página aponta o Unity Build Automation como alternativa para quem desenvolve no Windows.

Some a isso a exigência atual da Apple: desde 28/04/2026, a App Store Connect só aceita envios de iOS compilados com Xcode 26 ou superior contra o SDK do iOS 26 (página "SDK minimum requirements" da Apple). E a tabela de requisitos do Xcode mostra que o Xcode 26.0 roda a partir do macOS Sequoia 15.6, enquanto as versões mais novas do Xcode 26 pedem macOS Tahoe 26.2. Ou seja: não basta "um Mac", precisa ser um Mac que roda um macOS recente.

O que a Unity faz no Windows e o que o Xcode faz

Entender a divisão evita gastar dinheiro no lugar errado.

A Unity, em qualquer sistema, converte o seu C# em C++ com IL2CPP, empacota cenas, assets e configurações, e escreve uma pasta com um projeto Xcode completo: arquivo .xcodeproj, código C++ gerado, bibliotecas da Unity e o Info.plist. Essa parte funciona no Windows.

O Xcode, só no macOS, compila esse C++ para ARM64 do iPhone, linka as bibliotecas, assina o pacote com o seu certificado e perfil de provisionamento, gera o arquivo .ipa (via Archive) e envia para a App Store Connect.

Na prática, todo o desenvolvimento do jogo (cenas, scripts, testes no editor) pode ficar no Windows. Você só precisa do Mac na hora de transformar a pasta Xcode num app instalável. Isso muda a conta: um Mac para build não precisa ser rápido como a sua máquina de trabalho.

Unity iOS build on Windows: Build Support e projeto Xcode

Os passos no Windows:

1. No Unity Hub, vá em Installs, clique na engrenagem da sua versão 6.3 LTS e escolha Add modules. Marque iOS Build Support.
2. No projeto, abra File > Build Profiles, selecione iOS e clique em Switch Platform.
3. Em Project Settings > Player > iOS, preencha Bundle Identifier (ex.: com.seuestudio.nomedojogo), Version e Build. O Bundle Identifier tem que bater com o App ID que você cria na Apple.
4. Ainda em Player, defina Target minimum iOS Version conforme os aparelhos que quer atender.
5. Clique em Build e escolha uma pasta vazia. O resultado é a pasta do projeto Xcode.

Se você quiser já deixar o signing automático configurado para o Mac só abrir e arquivar, preencha o Signing Team ID em Player Settings e marque Automatically Sign. Também dá para configurar isso por script de editor. Arquivo Assets/Editor/IosBuildSettings.cs:

using UnityEditor;
using UnityEditor.Build;

public static class IosBuildSettings
{
    private const string TeamId = "ABCDE12345"; // seu Team ID da Apple

    [MenuItem("Tools/iOS/Aplicar configuração de build")]
    public static void Apply()
    {
        PlayerSettings.SetApplicationIdentifier(NamedBuildTarget.iOS, "com.seuestudio.nomedojogo");
        PlayerSettings.iOS.appleDeveloperTeamID = TeamId;
        PlayerSettings.iOS.appleEnableAutomaticSigning = true;
        PlayerSettings.iOS.targetOSVersionString = "15.0";
    }
}

O Team ID fica na sua conta Apple Developer, em Membership. Essa pasta Xcode é o que você leva para qualquer um dos caminhos abaixo.

Opção 1: Mac próprio ou usado

O caminho mais barato no longo prazo e o que dá menos dor de cabeça. Você copia a pasta (ou usa Git), abre o Unity-iPhone.xcodeproj no Xcode, conecta o iPhone, roda, e depois usa Product > Archive para enviar à loja.

O que conferir antes de comprar usado:

• Chip Apple (M1 ou mais novo). Roda o macOS atual com folga e compila IL2CPP bem mais rápido que os Intel da mesma faixa de preço.
• Que o modelo roda o macOS Tahoe 26.2 ou superior, porque é o que o Xcode 26 mais recente pede. Confira na página da Apple de compatibilidade do macOS pelo nome exato do modelo.
• Armazenamento: Xcode, simuladores e caches passam fácil de dezenas de GB. 256 GB é o mínimo confortável.
• 8 GB de RAM funciona para jogo pequeno; 16 GB evita travadas no Archive.

Um Mac mini usado com chip M1 é a escolha comum de quem desenvolve no Windows e só precisa da máquina para build. Ele fica ligado na rede e você acessa por compartilhamento de tela.

Opção 2: Mac na nuvem

Serviços de Mac remoto alugam uma máquina macOS por hora ou por mês, acessada por área de trabalho remota. Os mais conhecidos são os provedores dedicados a Mac (como MacinCloud e MacStadium) e as instâncias Mac da AWS (EC2 Mac).

O que pesa na escolha:

• Acesso de administrador: para instalar uma versão específica do Xcode você precisa dele. Planos mais baratos às vezes vêm com Xcode pré-instalado e sem admin.
• Cobrança mínima: a AWS aloca Mac como host dedicado e cobra um período mínimo de 24 horas por alocação, por causa da licença da Apple. Bom para build contínuo, caro para uma build por semana.
• Teste no aparelho: com Mac remoto você não pluga o iPhone. O fluxo vira Archive, envio para a App Store Connect e instalação pelo TestFlight.
• Latência: mexer no Xcode por área de trabalho remota é lento, mas suportável se você só arquiva e envia.

Os preços mudam com frequência e variam por região; consulte a página de cada provedor no dia em que for contratar.

Opção 3: Unity Build Automation e CI

Unity Build Automation

É o serviço de build na nuvem da própria Unity (parte do Unity DevOps). Você conecta o repositório Git, escolhe a plataforma iOS, envia certificado e perfil de provisionamento, e a Unity gera a build num Mac dela. Segundo o artigo de suporte da Unity sobre cobranças do DevOps, desde 01/03/2026 cada organização recebe por mês 100 minutos de build em Mac, 200 em Windows e 100 em Linux, mais 25 GB de armazenamento. O excedente é cobrado por minuto. Uma build iOS de jogo pequeno leva alguns minutos a algumas dezenas, então a franquia cobre testes esporádicos.

O ponto forte: você não mexe em macOS em nenhum momento. O ponto fraco: quando a build falha numa etapa do Xcode, você lê o log e tenta adivinhar a causa sem poder abrir o projeto.

CI com runner macOS

GitHub Actions, GitLab CI e outros têm máquinas macOS que você usa por minuto. O fluxo típico com Unity: um job gera a pasta Xcode (pode ser em Linux, usando as actions do GameCI) e outro job, num runner macOS, roda o xcodebuild ou o fastlane para arquivar, assinar e enviar ao TestFlight. Minuto de runner macOS custa mais caro que Linux nesses serviços, então separar a etapa Unity da etapa Xcode economiza.

Se você nunca montou pipeline, o post sobre builds automatizados e CI/CD para jogos mostra a lógica com um exemplo completo. Vale lembrar que CI exige paciência para depurar certificado em máquina que você não vê.

Escolher entre esses caminhos é a parte fácil. O difícil é chegar com um jogo que mereça a viagem até a App Store: toque bem resolvido, desempenho estável em iPhone mais antigo, menus, salvamento e um loop que segura o jogador. Quem aprende sozinho costuma travar justamente nessa costura entre sistemas.

Conta Apple Developer, certificado e provisioning

Em qualquer caminho, a Apple exige as mesmas peças:

• Apple ID gratuito: permite instalar o jogo no seu próprio iPhone pelo Xcode, com um perfil temporário que expira em poucos dias. Bom para testar.
• Apple Developer Program: US$ 99 por ano, em moeda local onde disponível, segundo a página de inscrição da Apple consultada em outubro de 2026. Obrigatório para TestFlight, App Store, Game Center e compras no app.
• Certificado de distribuição (Apple Distribution): identifica você como quem assina o app. Gerado no portal da Apple ou pelo próprio Xcode.
• App ID com o mesmo Bundle Identifier da Unity, e as capacidades que o jogo usa marcadas (Game Center, In-App Purchase, Push).
• Provisioning profile: une certificado, App ID e (no caso de desenvolvimento) os aparelhos autorizados. Com Automatically manage signing no Xcode, ele é criado sozinho.

Para Unity Build Automation e CI, você exporta o certificado como arquivo .p12 com senha e baixa o provisioning profile de distribuição. Guarde os dois como guarda a keystore do Android.

Quando adiar o iOS

Às vezes a melhor resposta para "como buildar iOS sem Mac" é "ainda não". Adie se:

• O jogo ainda não foi validado em nenhuma loja. Lançar no Android primeiro, com teste fechado, mostra se as pessoas jogam antes de você gastar com Mac e conta anual.
• O jogo depende de plugin que você nunca testou no iOS (anúncio, login social). Cada plugin traz configuração própria no Xcode.
• Seu público é majoritariamente Android. No Brasil, a maior parte dos celulares em uso é Android, então muitos indies começam por lá.

Quando o jogo já tem retenção no Android, o iOS vira porta 2 com custo justificado. Se você usa Godot em outro projeto, o processo é parecido e está em exportar jogo Godot para iOS.

Próximo passo

Gere hoje a pasta Xcode no Windows com iOS Build Support. Ela custa zero e já mostra se algum plugin quebra na plataforma. Depois escolha o caminho: Unity Build Automation para testar na franquia gratuita, Mac usado se for publicar com frequência. E para o panorama de publicação nas duas lojas, leia publicar jogos mobile no Google Play e na App Store.