¿Qué versión o número de compilación de la aplicación iOS DEBEN incrementarse con el lanzamiento de la App Store?


107

Los campos de versión / compilación para una aplicación iOS incluyen:

  • "Versión" CFBundleShortVersionString (String - iOS, OS X) especifica el número de versión de lanzamiento del paquete, que identifica una iteración lanzada de la aplicación. El número de versión de lanzamiento es una cadena compuesta por tres números enteros separados por puntos.

  • "Build" CFBundleVersion (String - iOS, OS X) especifica el número de versión de compilación del paquete, que identifica una iteración (publicada o no publicada) del paquete. El número de versión de compilación debe ser una cadena compuesta por tres enteros separados por puntos no negativos, siendo el primer entero mayor que cero. La cadena solo debe contener caracteres numéricos (0-9) y punto (.). Los ceros iniciales se truncan de cada entero y se ignorarán (es decir, 1.02.3 es equivalente a 1.2.3). Esta clave no es localizable.

  • "Número de versión de iTunes Connect" : número de versión que especifica al crear una nueva versión de la aplicación en iTunes Connect.

Mi pregunta es:

¿Qué números de versión / compilación se deben incrementar cuando se carga una nueva versión de la aplicación en iTunes Connect y / o se lanza a la App Store?

¿Puede la "versión" CFBundleShortVersionStringo la "compilación" CFBundleVersionpermanecer igual entre las actualizaciones de la aplicación?

Puntos adicionales para las fuentes de Apple o los mensajes de error exactos que iTunesConnect muestra al cargar una versión / número de compilación no válido.


Nota de Android / Google Play:

La discusión que suscita esta pregunta es que la "versión" pública de una aplicación de Android en Google Play Store no necesita incrementarse y no está validada de ninguna manera . El android:versionNamepuede seguir siendo el mismo entre los lanzamientos, mejorar, reducir, o ser cualquier cadena aleatoria en lugar de algo que parece ser un "número de versión" válido.

android:versionName - Un valor de cadena que representa la versión de lanzamiento del código de la aplicación, como se debe mostrar a los usuarios.

El valor es una cadena para que pueda describir la versión de la aplicación como una <major>.<minor>.<point>cadena o como cualquier otro tipo de identificador de versión absoluta o relativa.

Diferencia entre versionName y versionNumber en Android

Mientras que android:versionCodese obliga a que sea un entero que se incrementa en el lanzamiento.


Documentación de Apple

Como se señaló en la respuesta recientemente aceptada , Apple ha publicado recientemente una Nota técnica que detalla su esquema de número de versión y compilación:

Nota técnica de Apple TN2420 - Números de versión y números de compilación


Una respuesta detallada con captura de pantalla: stackoverflow.com/a/31921249/936957
Yunus Nedim Mehel

Respuestas:


115

Nota técnica de Apple TN2420, números de versión y números de compilación

Resumen:

  • El par ( Version, Build number) debe ser único.
    • La secuencia es válida: (1.0.1, 12) -> (1.0.1, 13) -> (1.0.2, 13) -> (1.0.2, 14) ...
  • Version( CFBundleShortVersionString ) debe estar en orden secuencial ascendente.
  • Build number( CFBundleVersion ) debe estar en orden secuencial ascendente.

Lista de verificación de número de versión y número de compilación

Aquí hay algunas cosas que puede verificar al enviar una nueva compilación a la App Store. Asegurarse de tener su Número de versión y Número de compilación configurados correctamente lo ayudará a evitar que su aplicación sea rechazada automáticamente por tenerlos configurados incorrectamente.

  1. Para cada nueva versión de su aplicación, debe inventar un nuevo número de versión. Este número debe ser un valor mayor que el último número de versión que utilizó. Aunque puede proporcionar muchas compilaciones para cualquier versión particular de su aplicación, solo necesita usar un nuevo número de versión para cada nueva versión de su aplicación.
  2. No puede reutilizar los números de versión.
  3. Por cada nueva compilación que envíe, deberá inventar un nuevo Número de compilación cuyo valor sea mayor que el último Número de compilación que utilizó (para esa misma versión).
  4. Puede reutilizar los números de compilación en diferentes trenes de lanzamiento, pero no puede reutilizar los números de compilación dentro del mismo tren de lanzamiento. Para las aplicaciones macOS, no puede reutilizar los números de compilación en ningún tren de lanzamiento.

Según la lista de verificación, la siguiente (Version, Build Number)secuencia también es válida.

  • Caso: reutilización Build Numberen diferentes trenes de liberación. (NOTA: NO es la aplicación macOS)

    (1.0.0, 1) -> (1.0.0, 2) -> ... -> (1.0.0, 11) -> ( 1.0.1 , 1 ) -> (1.0.1, 2)


Estoy confundido. Una de las condiciones es "No se pueden reutilizar los números de versión", pero en el último ejemplo, los números de versión permanecen iguales mientras que los números de compilación aumentan. ¿Estoy malinterpretando algo?
Emil

@Emil, creo que su par (Versión, Número de compilación) no se puede reutilizar.
AechoLiu

6
Los números de versión de @EmilParikh se pueden cargar en Apple varias veces antes del lanzamiento , cada uno con un número de compilación único. Pero una vez que se ha publicado, no puede reutilizar ese número de versión.
pkamb

1
TN2420 dice "Los números de versión y los números de compilación pueden tener hasta tres componentes separados por puntos" y luego proporciona el siguiente ejemplo ilegal 1.10000.1.5 . Sin embargo, parece que muchas aplicaciones, incluido Chrome, usan un número de versión que contiene 4 componentes (por ejemplo, 68.0.3440.83 ). Supongo que esto podría explicarse por el hecho de que la página TN2420 menciona " Importante: este documento ya no se actualiza " . Sin embargo, no he podido encontrar un documento actualizado que defina las nuevas reglas. ¿Alguien más confundido?
catanman

@catanman Me gusta esta versión semántica . Que la versión se componga con (major, minor, patch)estilo. Y había usado 4 componentes antes, pero la App Store no acepta ese formato con 4 componentes.
AechoLiu

38

El CFBundleShortVersionStringdebe coincidir con el número de versión que da iTunes Connect. También es el número de versión que aparece cuando el usuario mira su aplicación en la App Store.

El número de versión se muestra en la tienda y esa versión debe coincidir con el número de versión que ingrese más tarde en iTunes Connect.

Fuente

No CFBundleVersionse muestra en la App Store, pero iTunes lo utiliza para determinar cuándo se ha actualizado su aplicación.

Si actualiza la cadena de compilación, como se describe en "Configuración del número de versión y la cadena de compilación", iTunes reconoce que la cadena de compilación cambió y sincroniza correctamente el nuevo paquete de la App Store de iOS para probar los dispositivos.

Fuente

Respondiendo a sus preguntas de manera más específica ...

¿Qué números de versión / compilación deben incrementarse cuando se carga una nueva versión de la aplicación en la tienda de aplicaciones?

Ambos. Uno se muestra en la App Store, el otro lo usa iTunes para actualizar la aplicación.

¿CFBundleShortVersionString o CFBundleVersion pueden permanecer iguales entre las actualizaciones de la aplicación?

No. (Meta pregunta, ¿cuál sería el caso de uso aquí? Si ha editado la carga útil de alguna manera, la compilación será diferente y el usuario querrá saberlo). Si lo intenta, verá mensajes de error como los siguientes:

Error de mensajes

¿O se comparan con el número respectivo anterior para garantizar que se cargue un número numéricamente mayor con la nueva versión de la aplicación?

Si. Usando el estándar semver.org .

¿Se comparan los números CFBundleShortVersionString y CFBundleVersion de alguna manera entre sí?

No.


2
Bien, sé cómo se usan los dos números. La pregunta es: ¿se requiere que ambos aumenten al lanzar una nueva versión de la aplicación?
pkamb

2
Sí, si intenta insertar una aplicación en la App Store sin actualizar ambas, verá un mensaje de error, por ejemplo, stackoverflow.com/questions/19367893/…
Andy

Gracias, gran edición. Especialmente por ese enlace. El validador del organizador muestra errores "debe contener una versión superior" tanto para CFBundleVersion como para CFBundleShortVersionString.
pkamb

1
+1 para el enlace SemVer ... Dado un número de versión MAJOR.MINOR.PATCH, incremente: la versión MAJOR cuando realiza cambios de API incompatibles, la versión MINOR cuando agrega funcionalidad de una manera compatible con versiones anteriores y la versión PATCH cuando realiza cambios hacia atrás -correcciones de errores compatibles.
jeet.chanchawat

Respecto a esto: ¿cuál sería el caso de uso aquí? Si ha editado la carga útil de alguna manera, la compilación será diferente y el usuario querrá saberlo . Mi caso de uso es que mi aplicación fue revisada con éxito por Apple, pero nunca antes se lanzó en la App Store. Encontré un error y quiero corregirlo, sin cambiarlo CFBundleShortVersionString. es posible? Quiero rechazar mi propia aplicación.
prueba el

31

CFBundleShortVersionString es el "nombre" público de la versión (ejemplo: "2.5" o "3.8.1"). Debe aumentarlo en cada lanzamiento .

CFBundleVersion es el número de compilación privado . No se ve en la AppStore. Debe aumentarlo en cada carga . Significa que si alguna vez rechaza un binario antes de que se conecte y desea cargar un nuevo binario, tendrá el mismo CFBundleShortVersionString pero debe tener un CFBundleVersion más alto (ejemplo: público "2.5", privado "2.5", y luego rechazo binario, y vuelva a cargar privado "2.5.1")

Editar el 16 de noviembre de 2016:

/ ! \ La propiedad CFBundleVersion también se usa (junto con CFBundleName ) en el User-Agentencabezado enviado por NSURLConnection en su código.

Ejemplo: si CFBundleName es MyApp y CFBundleVersion es 2.21, entonces cualquier consulta HTTP programática enviada directamente por su código usando NSURLConnection incrustará el encabezado:

User-Agent: MyApp/2.21 CFNetwork/... Darwin/...

(Esto no se aplica a las solicitudes emitidas automáticamente por UIWebView).


2
Gran distinción entre los requisitos de carga / publicación.
pkamb

@gabriel, he intentado establecer el número de compilación en XX-rc2 pero el validador del Organizador no me permite establecer nada diferente de XYZ donde X, Y y Z son números enteros: S. Sería genial tener un número de compilación -rc2, ¿alguna vez has podido enviar una versión con él?
Néstor

1
@nestor Tienes razón, estaba equivocado. Solo se permiten números. Déjame editar mi respuesta.
Gabriel

@gabriel, utilizo un script para analizar X.X-rc2a X.X.2, para el sistema de CI para generar el buildNumberpara subir a iTunesConnect.
AechoLiu

5

CFBundleVersion y CFBundleShortVersionString deben ser mayores que el último número de versión de la aplicación. Es una buena práctica mantenerlos igual. Debería encontrarlos en su -info.plist.

Cuando intenta validar la aplicación en el organizador, arrojará un error si alguno de ellos no se ha incrementado. Me pasó anoche.


Mencioné ambas claves en mi pregunta. ¿Su respuesta aquí es que ambos valores deben incrementarse? ¿Puede apoyar mejor su respuesta?
pkamb

Sí, ambos deben incrementarse. Anoche, cuando traté de enviarlos antes de incrementarlos, se quejó de ambas claves.
xoail

Gracias por la información adicional. Debes editar tu respuesta para agregar tu experiencia al cargar una compilación.
pkamb

6
"Es una buena práctica mantenerlos igual", esto no es necesariamente cierto. Si tiene probadores trabajando en su aplicación, es posible que desee incrementar su número de compilación a medida que se aplican los cambios, pero mantenga el mismo número de versión. Con la integración continua, puede hacer que actualice su número de compilación antes de implementarlo para los probadores, por ejemplo.
Andy

@Andy tienes razón, tiene sentido. Gracias por señalar el caso de uso. Solo estaba pensando en términos de un único entorno de desarrollador / probador.
xoail

5

Ambos CFBundleVersiony CFBundleShortVersionString DEBEN incrementarse al lanzar una nueva versión en la App Store.

Además, una de las cadenas debe coincidir con la versión especificada en iTunes Connect.

Error de Xcode Organizer Validator: debe incrementar el número de versión.

Esta pregunta incluye la captura de pantalla anterior del validador de Xcode Organizer que se niega a validar la aplicación cuando CFBundleVersiony CFBundleShortVersionStringno se han incrementado.

  • Este paquete no es válido. El valor de la clave CFBundleVersion[1.0] en el archivo Info.plist debe contener una versión superior a la de la versión cargada anteriormente [1.134].

  • Este paquete no es válido. El valor de la clave CFBundleShortVersionString[1.0] en el archivo Info.plist debe contener una versión superior a la de la versión cargada anteriormente [1.134].

El validador también arroja un error que prueba que una de las cadenas debe coincidir con la versión de la aplicación creada en iTunes Connect.

  • Versión no coincide. Ni CFBundleVersion ['1.0'] ni CFBundleShortVersionString ['1.0'] en Info.plist coinciden con la versión de la aplicación configurada en iTunes Connect ['1.4'].

2

La nota técnica actual de Apple TN2420, números de versión y números de compilación dice (mi negrita):

  1. Para las aplicaciones de iOS, puede reutilizar números de compilación en diferentes trenes de lanzamiento, pero no puede reutilizar números de compilación dentro del mismo tren de lanzamiento. Para las aplicaciones macOS, no puede reutilizar los números de compilación en ningún tren de lanzamiento .

Desafortunadamente, esto significa que no puede reutilizar un número de compilación que rastrea el número de tren de lanzamiento en iOS cuando está intentando lanzar la misma compilación en Mac Catalyst.

En mi caso, por ejemplo, debido a algunos problemas anteriores, terminé lanzando 1.0.2 (4) como una aplicación Mac Catalyst que correspondía a 1.0.2 (1) en iOS. Ahora, al intentar lanzar 1.0.3 (1) en ambos, la aplicación falla la verificación en MacOS debido al número de compilación, mientras pasa la verificación en iOS.

Supongo que ahora que estoy lanzando la misma aplicación en iOS y MacOS de forma rutinaria, adoptaré números de compilación que correspondan a la fecha, como 20200111 y los incrementaré con un punto decimal si necesito cambiar el número de compilación dentro de una versión determinada.


1

Necesitas incrementar ambos .

Al cargar una nueva versión, deberá crear una nueva versión en iTunes Connect, que automáticamente será más alta que las versiones anteriores. Esta versión en iTunes Connect esperará un binario con el mismo número de versión, por lo CFBundleShortVersionStringque debe incrementarse.

Si actualiza la versión pero se olvida de incrementar la CFBundleVersion , encontrará un error durante la carga. Vea la respuesta y la captura de pantalla de pkamb.

Para obtener detalles sobre CFBundleShortVersionStringy CFBundleVersion, consulte: https://stackoverflow.com/a/31921249/936957


1

Puedo confirmar, habiéndolo probado en ambos sentidos, que una secuencia de versiones y números de compilación como ...

1.0.0 (1)
1.0.1 (1)
1.0.2 (1)

... será aceptado para aplicaciones de iOS, pero para aplicaciones de Mac (Catalyst) devuelve este error:

ERROR ITMS-90061: "Este paquete no es válido. El valor de la clave CFBundleVersion [1] en el archivo Info.plist debe contener una versión superior a la versión cargada anteriormente [2]".

La versión de Mac y los números de compilación deberían ser como ...

1.0.0 (1)
1.0.1 (2)
1.0.2 (3)

Para iOS, solía ingresar números de compilación como el número de versión más un cuarto dígito, como ...

1.0.0 (1.0.0.1)
1.0.1 (1.0.1.1)
1.0.2 (1.0.2.1)

... pero eso tampoco está permitido para las aplicaciones de Mac. Cuando intenté enviar mi primera aplicación Mac (Catalyst), Apple solo aceptaba un número de compilación con tres o menos dígitos:

ERROR ITMS-9000: "Este paquete no es válido. El valor de la clave CFBundleVersion [1.0.0.1] en el archivo Info.plist debe ser una lista separada por puntos de un máximo de tres enteros no negativos".

Así que cambié a un solo número que se incrementa para cada compilación y continúa incrementándose en los números de versión.


¿Tiene alguno de los mensajes de error que le dio? ¡Cítelos si es así!
pkamb

0

Me estoy preparando para lanzar una nueva aplicación de Mac App Store. Usando el formato CalVer de YEAR.release (build).

He subido varias construcciones: 2020.0 (1), 2020.0 (2), etc., finalmente presenté 2020.0 (8)para la App Store Review. Que pasó la revisión y está en el estado Pendiente de lanzamiento para desarrolladores .

Quería arreglar algunas cosas antes del lanzamiento, así que agregué una nueva compilación al mismo tren de lanzamiento: 2020.0 (9) .

Eso resulta en el error:

Error de operación de conexión de App Store

ERROR ITMS-90062 : "Este paquete no es válido. El valor de la clave CFBundleShortVersionString[2020.0] en el archivo Info.plist debe contener una versión superior a la de la versión aprobada anteriormente [2020.0]. Encontrará más información sobre CFBundleShortVersionStringen https: // developer.apple.com/documentation/bundleresources/information_property_list/cfbundleshortversionstring "

lo cual es molesto ya que mi 2020.0versión nunca fue lanzada . A partir de la respuesta aceptada a esta pregunta, tenía la impresión de que hasta que la aplicación estuviera disponible en la App Store, podría continuar lanzando nuevas compilaciones con la misma versión.

La solución parece ser que un "tren de lanzamiento" (Misma versión + Nueva compilación) no se puede actualizar si el estado de la aplicación es Lanzamiento de desarrollador pendiente . Publica tu compilación existente y luego aumenta la versión, o cancela esta versión en App Store Connect para permitir más cargas para este tren de versiones.


-2

AFAIK, fuera de mi cabeza, solo necesitas aumentar el número de compilación CFBundleVersion. Incrementar la cadena de la versión corta no es necesariamente necesario, aunque probablemente debería incrementarlo, ya que le dice al usuario que la aplicación es nueva. Sin embargo, Apple dice que la numeración debe seguir las convenciones tradicionales de versiones de software, y iTunes Connect puede quejarse si intenta volver a cargar una versión ya existente.

En pocas palabras, puede funcionar, pero probablemente no.


Buscando respuestas autorizadas sobre qué claves deben incrementarse. Si CFBundleShortVersionStringno es necesario incrementarlo, la "misma" versión para el usuario se puede cargar en la App Store varias veces.
pkamb
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.