# Build number en App Store Connect: versión y número de build > La versión es el número que ven tus clientes y el build number identifica cada envío. La pareja debe ser única: con Expo, EAS sube el build por ti. Página original: [Build number en App Store Connect: versión y número de build](https://devoria.fr/es/blog/app-store-connect-build-number-version) Autor: [Mehdi Azizi](https://devoria.fr/es/mehdi-azizi) Publicación: 2026-11-04 Última revisión del contenido: 2026-11-04 El build number de App Store Connect es el número de build: la clave `CFBundleVersion`, que identifica cada envío. La versión, `CFBundleShortVersionString`, es el número que tus clientes ven en el App Store. **Apple exige que la pareja de versión y número de build sea única: un número de build solo sirve una vez para una misma versión.** Con Expo, tú defines la versión y EAS puede incrementar el número de build en cada build de producción. Esta guía explica los dos números, las reglas de Apple, los errores ITMS-90062 e ITMS-90189, y qué revisar cuando tu build no aparece. Publico mis apps iOS con Expo y EAS, entre ellas Solys, TradaZen y Nolera. Los ajustes que verás más abajo son los de sus archivos `eas.json`. ## Versión y número de build: ¿cuál es la diferencia? Dos claves del Info.plist identifican tu app. [La documentación de Apple sobre CFBundleShortVersionString](https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundleshortversionstring) la describe como la versión visible para el usuario: tres enteros separados por puntos, como 10.14.1. [La de CFBundleVersion](https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundleversion) habla de la versión del build: de uno a tres enteros, solo con dígitos y puntos. | Elemento | Clave iOS | Quién la ve | Campo de Expo | | --------------- | -------------------------- | ------------ | ----------------- | | Versión | CFBundleShortVersionString | Tus clientes | `version` | | Número de build | CFBundleVersion | Tú y Apple | `ios.buildNumber` | Ejemplo ficticio: para la versión 1.4.0, envías los builds 12, 13 y 14 durante tus pruebas y luego eliges uno para la revisión. [La ayuda de App Store Connect](https://developer.apple.com/help/app-store-connect/manage-builds/upload-builds) lo resume: la versión vincula el build con su ficha y el número de build lo identifica en todo el sistema. ## Las reglas de incremento de Apple 1. **La pareja debe ser única.** Según [la documentación de Xcode Cloud](https://developer.apple.com/documentation/xcode/setting-the-next-build-number-for-xcode-cloud-builds), App Store Connect exige una combinación única de versión y número de build. Por eso una app de iPhone puede volver a empezar en 1 con una nueva versión. Una app de Mac, no: su número siempre debe subir. 2. **Una versión aprobada queda cerrada.** Cuando Apple aprueba la versión 1.4.0, ya no puedes agregarle builds. La siguiente debe llevar un número mayor. 3. **Cada número se compara como un entero.** 1.10 va después de 1.9, porque 10 es mayor que 9. Una versión 1.9 enviada después de una 1.20 aprobada será rechazada. Mi consejo: **mantén un número de build entero que siempre suba, sin volver a 1.** Reiniciar en 1 está permitido en iPhone, pero un número único durante toda la vida de la app evita confundir dos builds en TestFlight. Es lo que veo en mis apps en modo remoto: el contador sigue de una versión a otra. ## Gestionar versión y build con Expo y EAS [La página de Expo sobre versiones](https://docs.expo.dev/build-reference/app-versions/), actualizada el 25 de septiembre de 2026, separa los roles. La versión (`version` en app.json) es cosa tuya: la cambias cuando preparas un nuevo lanzamiento. El número de build (`ios.buildNumber`) se puede dejar en manos de EAS. De hecho, Expo menciona olvidar incrementarlo como una causa frecuente de rechazo al enviar. Todo se configura en eas.json: ```json { "cli": { "appVersionSource": "remote" }, "build": { "production": { "autoIncrement": true } } } ``` - **`"remote"`**: los servidores de EAS guardan el número de build. Es el comportamiento recomendado desde EAS CLI 12. El contador parte del valor de tu configuración, o de 1, y después `ios.buildNumber` se ignora. - **`"local"`**: manda tu configuración. Con `autoIncrement`, EAS modifica `ios.buildNumber` en tu archivo y tienes que hacer commit de ese cambio en cada build. - **`autoIncrement`**: [la referencia de eas.json](https://docs.expo.dev/eas/json/) acepta `true` o `"buildNumber"` para el build, y `"version"` para subir el último dígito de la versión. En modo remoto, Expo aclara que `"version"` no está soportado. En mi caso, TradaZen y Nolera están en `remote`. Solys se quedó en `local`: su número de build vive en app.json y cada build de producción lo sube en el archivo. **Los dos funcionan, pero el modo remoto elimina el riesgo de un commit olvidado.** Dos comandos completan el sistema. `eas build:version:set` inicializa el contador remoto: escribe el último número enviado a Apple. `eas build:version:sync` copia los valores remotos en tu proyecto, útil si algún día compilas con Xcode. Con EAS Update, el modo remoto no funciona con la política `nativeVersion`: Expo recomienda `appVersion`. ## ITMS-90062: la versión ya está aprobada El mensaje se ve así (números ficticios): ```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]. ``` Apple ya aprobó la versión 1.4.0: no puedes agregarle más builds. **Sube la versión en app.json, por ejemplo a 1.4.1, y vuelve a lanzar un build.** Cambiar solo el número de build no basta. Si el error vuelve aunque `version` esté actualizada, busca un campo `ios.version`. Según [la referencia de la configuración de Expo](https://docs.expo.dev/versions/latest/config/app/), tiene prioridad sobre `version` en iOS. El mismo remedio sirve para el error pariente ITMS-90186, "Invalid Pre-Release Train", que indica una versión cerrada a nuevos builds. ## ITMS-90189: Redundant Binary Upload Aquí el problema es el 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'. ``` La pareja 1.4.0 (12) ya existe en Apple. Con Expo, hay cuatro causas habituales: - **El perfil usado no tiene `autoIncrement`.** Si creas un perfil aparte para TestFlight, como el de Nolera, vuelve a ponerle la opción. - **El contador remoto está atrasado.** Pasaste a `remote` después de envíos manuales: ejecuta `eas build:version:set` con el último número que conoce Apple. - **Se olvidó el commit en modo local.** El siguiente build vuelve a partir del número anterior. - **Estás reenviando el mismo binario.** Con `eas submit`, elige el build nuevo, no el anterior. **La solución siempre es la misma: un nuevo build con un número mayor.** ## "No builds available": tu build no aparece El build se envió, pero tu ficha no lo ofrece. Revisa en este orden. 1. **Todavía se está procesando.** Apple procesa cada build antes de mostrarlo y te envía un correo al terminar. [Expo](https://docs.expo.dev/submit/ios/) habla en general de 10 a 15 minutos. [Según Apple](https://developer.apple.com/help/app-store-connect/manage-builds/view-builds-and-metadata), si pasan más de 24 horas en procesamiento, hay que abrir un ticket en Feedback Assistant. 2. **Espera tu declaración de cifrado.** Es el estado Missing Compliance, que explico más abajo. 3. **La versión no coincide.** Un build en 1.4.1 no se coloca bajo una ficha preparada en 1.5.0 en App Store Connect. Alinea las dos. 4. **Salió una versión mientras tanto.** Según [la ayuda sobre la elección del build](https://developer.apple.com/help/app-store-connect/manage-builds/choose-a-build-to-submit), la lista entonces solo muestra los builds enviados desde ese lanzamiento. 5. **Es el tester quien no lo ve.** En la app TestFlight, "no builds available" suele significar que el build no está en ningún grupo, espera la revisión beta o expiró. Los detalles están en [TestFlight para probar tu app de iPhone](https://devoria.fr/es/blog/testflight-probar-app-iphone-antes-de-enviarla). ### Los estados que debes conocer Estos son los estados que más a menudo explican un build ausente, según [la lista de Apple](https://developer.apple.com/help/app-store-connect/reference/app-build-statuses). Processing y Failed no aparecen ahí: son los estados de envío descritos en [el seguimiento de builds](https://developer.apple.com/help/app-store-connect/manage-builds/view-builds-and-metadata). | Estado | Qué significa | Tu solución | | ------------------ | ---------------------------- | ----------------------- | | Processing | Apple procesa el build | Esperar el correo | | Failed | Error al procesar | Leer el error, reenviar | | Missing Compliance | Cifrado no declarado | Responder o Info.plist | | Invalid Binary | Envío no conforme | Corregir, nuevo build | | Expired | Pasaron los 90 días | Nuevo build | | Ready to Submit | Listo para prueba o revisión | Agregarlo a un grupo | ### Declarar el cifrado de una vez por todas Sin la clave `ITSAppUsesNonExemptEncryption`, [Apple](https://developer.apple.com/documentation/bundleresources/information-property-list/itsappusesnonexemptencryption) te hace las preguntas de cumplimiento en cada nueva versión. Con Expo, el campo se llama `ios.config.usesNonExemptEncryption`: ```json { "expo": { "ios": { "config": { "usesNonExemptEncryption": false } } } } ``` `false` significa: sin cifrado, o solo con cifrado exento. [Apple aclara](https://developer.apple.com/documentation/security/complying-with-encryption-export-regulations) que el cifrado integrado en el sistema, como las conexiones HTTPS, suele estar exento, y que la respuesta también cubre tus bibliotecas. Mis tres apps declaran `false`. **Pon `false` solo si es cierto para tu app: la declaración te compromete.** ## ¿Se puede cambiar el número de un build ya enviado? No. El número está grabado en el binario firmado: para corregirlo, necesitas un nuevo build. Lo que sí puedes cambiar es el build vinculado a tu versión. Apple permite un solo build por versión, pero [puedes reemplazarlo tantas veces como quieras](https://developer.apple.com/help/app-store-connect/manage-builds/choose-a-build-to-submit) hasta enviarla a revisión: 1. Abre la versión en App Store Connect, sección Build. 2. Pasa el cursor sobre el build actual y haz clic en el botón de eliminar, el signo menos. 3. Haz clic en el botón de agregar, el signo más, elige el build correcto y guarda. Quitar un build de una versión no lo borra de tu cuenta. Si la versión ya está en revisión, [retira primero el envío](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/remove-a-submission-from-review): la revisión empezará desde cero. ## Antes de tu próximo envío El número de build es solo uno de los controles al enviar. La imagen de build puede provocar [ITMS-90725](https://devoria.fr/es/blog/itms-90725-sdk-version-issue-expo), y la firma tiene sus propias trampas, explicadas en [certificado de desarrollador iOS y provisioning profile](https://devoria.fr/es/blog/certificado-ios-provisioning-profile-expo). La cadena completa, del build a TestFlight, está en [publicar una app iOS sin Mac](https://devoria.fr/es/blog/publicar-app-ios-sin-mac-expo-eas), y los plazos de revisión en [tiempo de revisión del App Store](https://devoria.fr/es/blog/tiempo-revision-app-store-cuanto-esperar). Todos los pasos están reunidos en la página [publicar una aplicación en el App Store](https://devoria.fr/es/expertise/publicar-una-app-en-app-store). Si estás preparando tu primer lanzamiento, [haz el diagnóstico gratuito](https://devoria.fr/es/diagnostic): te dice qué bloquea tu proyecto y te envía mi checklist antirrechazo de Apple. Para construir la app, conectar las suscripciones y publicarla, el [iOS & Android Kit](https://devoria.fr/es/kits/ios) sigue el recorrido en cuatro etapas con el código base de mis apps, a tu ritmo. ## Preguntas frecuentes ### ¿Qué diferencia hay entre versión y build number en App Store Connect? La versión es el número público de tu lanzamiento, como 1.4.0. El build number identifica un binario concreto enviado a Apple para esa versión. Puedes enviar varios builds para una misma versión, cada uno con su número. ### ¿Hay que cambiar el número de build en cada envío? Sí, para una misma versión. Apple rechaza un segundo envío con la misma pareja de versión y número de build: es el error ITMS-90189. Con EAS, `autoIncrement` se encarga en cada build de producción. ### ¿El número de build debe volver a 1 en cada versión? No es obligatorio. En iPhone, Apple acepta un número menor para una nueva versión, porque solo la pareja debe ser única. Un contador que siempre sube es más fácil de seguir. ### ¿Cómo cambiar el build number en App Store Connect? No puedes modificar el número de un build ya enviado. En cambio, sí puedes reemplazar el build vinculado a tu versión, desde la sección Build de la ficha, mientras no esté en revisión. Para tener un número nuevo, haz otro build. ### ¿Por qué mi build no aparece en App Store Connect? Casi siempre se está procesando todavía o espera tu declaración de cifrado. Revisa también que su versión coincida con la de tu ficha. Si pasan más de 24 horas en procesamiento, Apple pide abrir un ticket. ## Tu proyecto [Review Kit](https://devoria.fr/es/kits/app-review): Mi checklist de revisión de App Store, mis rechazos de Apple corregidos, la de Google Play y tres skills de Claude Code. 49 €. [iOS & Android Kit](https://devoria.fr/es/kits/ios): Crea tu app para iPhone y Android con Claude Code: el código base de mis apps, el camino hasta las tiendas y todos los kits. 99 €. [Diagnóstico: lo que te separa de tu app para iPhone](https://devoria.fr/es/diagnostic): 7 preguntas, 60 segundos: descubre qué te frena de verdad para publicar tu app para iPhone, tu ruta en 4 etapas y el kit ideal para ti.