# Build number no App Store Connect: versão e número de build > A versão é o número que seus clientes veem, o build number identifica cada envio. O par precisa ser único: com Expo, o EAS incrementa o build para você. Página original: [Build number no App Store Connect: versão e número de build](https://devoria.fr/pt-br/blog/build-number-app-store-connect-versao-numero-build) Autor: [Mehdi Azizi](https://devoria.fr/pt-br/mehdi-azizi) Publicação: 2026-11-04 Última revisão do conteúdo: 2026-11-04 O build number do App Store Connect é o número de build: a chave `CFBundleVersion`, que identifica cada envio. A versão, `CFBundleShortVersionString`, é o número que seus clientes veem na App Store. **A Apple exige que o par versão e número de build seja único: um número de build só pode ser usado uma vez para a mesma versão.** Com Expo, você define a versão por conta própria e o EAS pode incrementar o número de build a cada build de produção. Este guia explica os dois números, as regras da Apple, os erros ITMS-90062 e ITMS-90189 e o que conferir quando seu build não aparece. Eu publico meus apps iOS com Expo e EAS, entre eles Solys, TradaZen e Nolera. As configurações mostradas abaixo são as dos arquivos `eas.json` deles. ## Versão e número de build: qual a diferença? Duas chaves do Info.plist identificam seu app. [A documentação da Apple sobre CFBundleShortVersionString](https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundleshortversionstring) a descreve como a versão visível para o usuário: três inteiros separados por pontos, como 10.14.1. [A documentação sobre CFBundleVersion](https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundleversion) fala da versão do build: de um a três inteiros, só com dígitos e pontos. | Elemento | Chave iOS | Quem vê | Campo Expo | | --------------- | -------------------------- | -------------- | ----------------- | | Versão | CFBundleShortVersionString | Seus clientes | `version` | | Número de build | CFBundleVersion | Você e a Apple | `ios.buildNumber` | Exemplo fictício: para a versão 1.4.0, você envia os builds 12, 13 e 14 durante os testes e depois escolhe um deles para a revisão. [A ajuda do App Store Connect](https://developer.apple.com/help/app-store-connect/manage-builds/upload-builds) resume assim: a versão liga o build à sua página, o número de build o identifica em todo o sistema. ## As regras de incremento da Apple 1. **O par precisa ser único.** Segundo [a documentação do Xcode Cloud](https://developer.apple.com/documentation/xcode/setting-the-next-build-number-for-xcode-cloud-builds), o App Store Connect exige uma combinação única de versão e número de build. Então um app de iPhone pode voltar para 1 numa versão nova. Um app de Mac, não: o número dele sempre tem que subir. 2. **Uma versão aprovada está fechada.** Depois que a Apple aprovou a versão 1.4.0, você não pode mais adicionar builds a ela. A próxima precisa ter um número maior. 3. **Cada número é comparado como inteiro.** 1.10 vem depois de 1.9, porque 10 é maior que 9. Uma versão 1.9 enviada depois de uma 1.20 aprovada será recusada. Meu conselho: **mantenha um número de build inteiro que sempre sobe, sem voltar para 1.** Recomeçar do 1 é permitido no iPhone, mas um número único durante toda a vida do app evita confundir dois builds no TestFlight. É o que vejo nos meus apps em modo remoto: o contador continua de uma versão para a outra. ## Gerenciar versão e build com Expo e EAS [A página da Expo sobre versões](https://docs.expo.dev/build-reference/app-versions/), atualizada em 25 de setembro de 2026, separa os papéis. A versão (`version` no app.json) fica com você: você muda quando prepara um novo lançamento. O número de build (`ios.buildNumber`) pode ficar a cargo do EAS. A Expo inclusive cita o esquecimento de incrementá-lo como uma causa comum de rejeição no envio. Tudo se configura no eas.json: ```json { "cli": { "appVersionSource": "remote" }, "build": { "production": { "autoIncrement": true } } } ``` - **`"remote"`**: os servidores do EAS guardam o número de build. É o comportamento recomendado desde o EAS CLI 12. O contador começa pelo valor da sua configuração, ou por 1, e depois `ios.buildNumber` é ignorado. - **`"local"`**: sua configuração é que vale. Com `autoIncrement`, o EAS altera `ios.buildNumber` no seu arquivo, e você precisa fazer commit dessa mudança a cada build. - **`autoIncrement`**: [a referência do eas.json](https://docs.expo.dev/eas/json/) aceita `true` ou `"buildNumber"` para o build, e `"version"` para subir o último dígito da versão. No modo remoto, a Expo avisa que `"version"` não é suportado. Aqui, TradaZen e Nolera estão em `remote`. Solys ficou em `local`: o número de build dela fica no app.json e cada build de produção o incrementa no arquivo. **Os dois funcionam, mas o modo remoto elimina o risco de um commit esquecido.** Dois comandos completam o esquema. `eas build:version:set` inicializa o contador remoto: informe o último número enviado à Apple. `eas build:version:sync` copia os valores remotos para o seu projeto, útil se um dia você compilar com o Xcode. Com EAS Update, o modo remoto não funciona com a política `nativeVersion`: a Expo recomenda `appVersion`. ## ITMS-90062: a versão já foi aprovada A mensagem é parecida com esta (números fictícios): ```text ERROR ITMS-90062: This bundle is invalid. The value for key CFBundleShortVersionString [1.4.0] in the Info.plist file must contain a higher version than that of the previously approved version [1.4.0]. ``` A Apple já aprovou a versão 1.4.0: você não pode mais adicionar builds a ela. **Suba a versão no app.json, por exemplo para 1.4.1, e rode um novo build.** Mudar só o número de build não resolve. Se o erro voltar mesmo com `version` atualizado, procure um campo `ios.version`. Segundo [a referência da configuração da Expo](https://docs.expo.dev/versions/latest/config/app/), ele tem prioridade sobre `version` no iOS. O remédio é o mesmo para o erro primo ITMS-90186, "Invalid Pre-Release Train", que indica uma versão fechada para novos builds. ## ITMS-90189: Redundant Binary Upload Aqui o problema é o número de build: ```text ERROR ITMS-90189: Redundant Binary Upload. You've already uploaded a build with build number '12' for version number '1.4.0'. ``` O par 1.4.0 (12) já existe na Apple. Com Expo, quatro causas aparecem com frequência: - **O perfil usado não tem `autoIncrement`.** Se você cria um perfil separado para o TestFlight, como o do Nolera, coloque a opção nele também. - **O contador remoto está atrasado.** Você mudou para `remote` depois de envios manuais: rode `eas build:version:set` com o último número conhecido pela Apple. - **O commit foi esquecido no modo local.** O build seguinte recomeça do número antigo. - **Você está reenviando o mesmo binário.** Com `eas submit`, escolha o build novo, não o antigo. **A correção é sempre a mesma: um novo build com um número maior.** ## "No builds available": seu build não aparece O build foi enviado, mas sua página não o oferece. Confira nesta ordem. 1. **Ele ainda está em processamento.** A Apple processa cada build antes de exibi-lo e manda um e-mail no final. [A Expo](https://docs.expo.dev/submit/ios/) fala em geral de 10 a 15 minutos. [Segundo a Apple](https://developer.apple.com/help/app-store-connect/manage-builds/view-builds-and-metadata), se passar de 24 horas em processamento, é preciso abrir um chamado no Feedback Assistant. 2. **Ele está esperando sua declaração de criptografia.** É o status Missing Compliance, explicado mais abaixo. 3. **A versão não bate.** Um build 1.4.1 não entra numa página preparada como 1.5.0 no App Store Connect. Alinhe as duas. 4. **Saiu uma versão nesse meio-tempo.** Segundo [a ajuda sobre a escolha do build](https://developer.apple.com/help/app-store-connect/manage-builds/choose-a-build-to-submit), a lista então só mostra os builds enviados desde esse lançamento. 5. **Quem não vê é o testador.** No app TestFlight, "no builds available" muitas vezes quer dizer que o build não está em nenhum grupo, está aguardando a revisão beta ou expirou. Os detalhes estão em [TestFlight para testar seu app de iPhone](https://devoria.fr/pt-br/blog/testflight-como-testar-app-iphone-antes-envio). ### Os status que você precisa conhecer Os status que mais explicam um build ausente, segundo [a lista da Apple](https://developer.apple.com/help/app-store-connect/reference/app-build-statuses). Processing e Failed não estão nela: são status de envio descritos no [acompanhamento de builds](https://developer.apple.com/help/app-store-connect/manage-builds/view-builds-and-metadata). | Status | O que significa | Sua correção | | ------------------ | ---------------------------- | ----------------------- | | Processing | A Apple está processando | Esperar o e-mail | | Failed | Erro no processamento | Ler o erro, reenviar | | Missing Compliance | Criptografia não declarada | Responder ou Info.plist | | Invalid Binary | Envio fora do padrão | Corrigir, novo build | | Expired | Mais de 90 dias | Novo build | | Ready to Submit | Pronto para teste ou revisão | Adicionar a um grupo | ### Declarar a criptografia de uma vez por todas Sem a chave `ITSAppUsesNonExemptEncryption`, [a Apple](https://developer.apple.com/documentation/bundleresources/information-property-list/itsappusesnonexemptencryption) faz as perguntas de conformidade a cada nova versão. Com Expo, o campo se chama `ios.config.usesNonExemptEncryption`: ```json { "expo": { "ios": { "config": { "usesNonExemptEncryption": false } } } } ``` `false` quer dizer: nenhuma criptografia, ou só criptografia isenta. [A Apple explica](https://developer.apple.com/documentation/security/complying-with-encryption-export-regulations) que a criptografia embutida no sistema, como as conexões HTTPS, em geral é isenta, e que a resposta também cobre suas bibliotecas. Meus três apps declaram `false`. **Só coloque `false` se isso for verdade para o seu app: a declaração é de sua responsabilidade.** ## Dá para mudar o número de um build já enviado? Não. O número está gravado no binário assinado: para corrigir, é preciso um novo build. O que você pode mudar é o build vinculado à sua versão. A Apple permite um único build por versão, mas [você pode trocá-lo quantas vezes quiser](https://developer.apple.com/help/app-store-connect/manage-builds/choose-a-build-to-submit) até o envio para revisão: 1. Abra a versão no App Store Connect, seção Build. 2. Passe o mouse sobre o build atual e clique no botão de remoção, o sinal de menos. 3. Clique no botão de adicionar, o sinal de mais, escolha o build certo e salve. Remover um build de uma versão não o apaga da sua conta. Se a versão já estiver em revisão, [retire a submissão primeiro](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/remove-a-submission-from-review): a revisão vai recomeçar do zero. ## Antes do seu próximo envio O número de build é só uma das verificações no envio. A imagem de build pode disparar o [ITMS-90725](https://devoria.fr/pt-br/blog/itms-90725-sdk-version-issue-expo), e a assinatura tem suas próprias armadilhas, explicadas em [certificado de desenvolvedor iOS e provisioning profile](https://devoria.fr/pt-br/blog/certificado-ios-provisioning-profile-expo). O processo completo, do build ao TestFlight, está em [publicar um app iOS sem Mac](https://devoria.fr/pt-br/blog/publicar-app-ios-sem-mac-expo-eas), e os prazos de revisão em [prazo de aprovação da App Store](https://devoria.fr/pt-br/blog/prazo-aprovacao-app-store-quanto-tempo). Todas as etapas estão reunidas na página [publicar um aplicativo na App Store](https://devoria.fr/pt-br/expertise/publicar-app-na-app-store). Se você está preparando seu primeiro lançamento, [faça o diagnóstico gratuito](https://devoria.fr/pt-br/diagnostic): ele mostra o que está travando no seu projeto e te envia meu checklist contra rejeições da Apple. Para construir o app, conectar as assinaturas e publicar, o [iOS & Android Kit](https://devoria.fr/pt-br/kits/ios) segue o caminho em quatro etapas com o código inicial dos meus apps, no seu ritmo. ## Perguntas frequentes ### Qual a diferença entre versão e build number no App Store Connect? A versão é o número público do seu lançamento, como 1.4.0. O build number identifica um binário específico enviado à Apple para essa versão. Você pode enviar vários builds para a mesma versão, cada um com seu número. ### Preciso mudar o número de build a cada envio? Sim, para a mesma versão. A Apple recusa um segundo envio com o mesmo par versão e número de build: é o erro ITMS-90189. Com EAS, o `autoIncrement` cuida disso a cada build de produção. ### O número de build precisa voltar para 1 a cada versão? Não é obrigatório. No iPhone, a Apple aceita um número menor para uma versão nova, porque só o par precisa ser único. Um contador que sempre sobe continua sendo mais fácil de acompanhar. ### Como mudar o build number no App Store Connect? Você não pode alterar o número de um build já enviado. Mas pode trocar o build vinculado à sua versão, na seção Build da página, enquanto ela não estiver em revisão. Para ter um número novo, faça um novo build. ### Por que meu build não aparece no App Store Connect? Na maioria das vezes, ele ainda está em processamento ou esperando sua declaração de criptografia. Confira também se a versão dele bate com a da sua página. Se passar de 24 horas em processamento, a Apple pede para abrir um chamado. ## Seu projeto [Review Kit](https://devoria.fr/pt-br/kits/app-review): Meu checklist de revisão da App Store, as recusas da Apple que corrigi, o checklist do Google Play e três skills do Claude Code. R$ 289. [iOS & Android Kit](https://devoria.fr/pt-br/kits/ios): Crie seu app para iPhone e Android com o Claude Code: o código inicial dos meus apps, o caminho até as lojas e todos os kits. R$ 589. [Diagnóstico: o que te separa do seu app de iPhone](https://devoria.fr/pt-br/diagnostic): 7 perguntas, 60 segundos: descubra o que realmente te impede de publicar seu app de iPhone, seu caminho em 4 etapas e o kit certo para você.