Build number en App Store Connect: versión y número de build
Por Mehdi Azizi
Publicado el , 8 min
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.
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 la describe como la versión visible para el usuario: tres enteros separados por puntos, como 10.14.1. La de 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 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
- La pareja debe ser única. Según la documentación de Xcode Cloud, 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.
- 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.
- 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, 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:
{
"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ésios.buildNumberse ignora."local": manda tu configuración. ConautoIncrement, EAS modificaios.buildNumberen tu archivo y tienes que hacer commit de ese cambio en cada build.autoIncrement: la referencia de eas.json aceptatrueo"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):
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, 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:
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
remotedespués de envíos manuales: ejecutaeas build:version:setcon 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.
- Todavía se está procesando. Apple procesa cada build antes de mostrarlo y te envía un correo al terminar. Expo habla en general de 10 a 15 minutos. Según Apple, si pasan más de 24 horas en procesamiento, hay que abrir un ticket en Feedback Assistant.
- Espera tu declaración de cifrado. Es el estado Missing Compliance, que explico más abajo.
- 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.
- Salió una versión mientras tanto. Según la ayuda sobre la elección del build, la lista entonces solo muestra los builds enviados desde ese lanzamiento.
- 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.
Los estados que debes conocer
Estos son los estados que más a menudo explican un build ausente, según la lista de Apple. Processing y Failed no aparecen ahí: son los estados de envío descritos en el seguimiento de builds.
| 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 te hace las preguntas de cumplimiento en cada nueva versión. Con Expo, el campo se llama ios.config.usesNonExemptEncryption:
{
"expo": {
"ios": {
"config": {
"usesNonExemptEncryption": false
}
}
}
}
false significa: sin cifrado, o solo con cifrado exento. Apple aclara 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 hasta enviarla a revisión:
- Abre la versión en App Store Connect, sección Build.
- Pasa el cursor sobre el build actual y haz clic en el botón de eliminar, el signo menos.
- 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: 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, y la firma tiene sus propias trampas, explicadas en certificado de desarrollador iOS y provisioning profile. La cadena completa, del build a TestFlight, está en publicar una app iOS sin Mac, y los plazos de revisión en tiempo de revisión del App Store. Todos los pasos están reunidos en la página publicar una aplicación en el App Store.
Si estás preparando tu primer lanzamiento, haz el diagnóstico gratuito: 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 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.

