descargar - ios download

¿Qué valores debo usar para CFBundleVersion y CFBundleShortVersionString? (6)

Algo que nunca he visto discutido en ninguna parte es ¿cuál es el número máximo para cada campo en una versión de CFBundleVersion?

Al configurar CFBundleVersion en una aplicación en 1.1.1 y mirando el vaue hexadecimal para la versión en "lsregister -dump", determiné que el valor máximo para el primer campo es (2 ^ 22) -1 o 4194303, y el máximo los valores para el segundo y tercer campo son (2 ^ 21) -1 o 2097151.

Los 3 campos suman hasta 64 bits.

Esto tiene implicaciones para aquellos de nosotros que usamos CFBundleVersion en función de la fecha y la hora.

Estaba estableciendo el primer campo para AAAAMMDD. Esto siempre es mayor que las versiones máximas permitidas y condujo a resultados impredecibles, por decir lo menos, cuando Launch Services decidía qué versión de una aplicación ejecutar cuando tenía múltiples versiones instaladas y utilizaba algo como ''open -a Appname ''desde la línea de comando.

Por favor difúndelo ampliamente. Estoy seguro de que mucha gente se deshará de esto.

Este es mi primer envío de aplicaciones iOS y no quiero que mi aplicación sea rechazada.

Esto es de Apple Docs:

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

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 enteros separados por un período. El primer entero representa revisiones importantes de la aplicación, como revisiones que implementan nuevas características o cambios importantes. El segundo entero denota revisiones que implementan características menos destacadas. El tercer entero representa las versiones de mantenimiento.

El valor de esta clave difiere del valor de "CFBundleVersion", que identifica una iteración (liberada o no publicada) de la aplicación. Esta clave se puede localizar incluyéndola en sus archivos InfoPlist.strings.

Pero parece un poco extraño. Mi interpretación para esto es poner los dos valores iguales, es decir:

CFBundleVersion: 1.0.0 CFBundleShortVersionString: 1.0.0

¿Alguien puede confirmar el 100% que es lo que se supone que debo poner?

El esquema más sensato para mí es usar el número de versión (es decir, CFBundleShortVersionString ) para el número de versión actual, y luego usar el número de compilación (es decir, CFBundleVersion ) para representar el envío al App Store. Entonces, a menos que haya algún problema y, por lo tanto, se vuelvan a enviar, este número siempre es 1. Para una nueva versión, reinicié a 1 si el anterior tenía problemas en las pruebas TestFlight o en revisión.

Los números de compilación proporcionan una forma de nombrar cada una de las presentaciones que proporciona para una publicación en particular. Como se describe en las definiciones anteriores, la colección de todas las compilaciones que usted proporciona para una versión particular de su aplicación se denomina ''tren de publicación'' de esa versión. Para las aplicaciones de iOS, los números de compilación deben ser únicos dentro de cada tren de lanzamiento, pero no es necesario que sean únicos en los distintos trenes de lanzamiento [énfasis mío]. Es decir, para las aplicaciones de iOS puede volver a usar los mismos números de compilación en diferentes trenes de lanzamiento si lo desea.

De la nota técnica TN2420: Números de versión y números de compilación .

La respuesta de rmaddy es correcta. Añadiré dos pensamientos más.

Tercera versión

Tenga en cuenta el tercer número de versión, especificado en el sitio web iTunesConnect como parte de la definición de su aplicación. Si ese número es diferente de los dos en Xcode, Apple le da una advertencia. Puede ignorar la advertencia, ya que no es un show-stopper (no es un "error").

Fecha-Hora como versión

Además, no necesita usar tres números con puntuación. Eso puede tener sentido para algunas aplicaciones, donde tradicionalmente los cambios en el primer número indicaban algún tipo de cambio dramático que generalmente afecta la compatibilidad.

Para otras aplicaciones, es posible que desee utilizar simplemente un valor de fecha y hora en el estilo de formato estándar ISO 8601 (AAAAMMDDHHMM). Por ejemplo, 201606070620 . Ese orden de año-mes-fecha-hora-minuto representa un número cada vez mayor, siempre la misma longitud debido al relleno cero, que cuando se ordena alfabéticamente también es cronológico.

He utilizado con éxito este estilo de números de versión en una aplicación iOS de envío que funciona en iOS 7, 8 y 9.

Incluso puede automatizar la generación de este valor. En el panel Target > Build Phases > Run Script tu proyecto:

Especifique en el campo de Shell : /bin/sh
Pegue el siguiente script de 5 líneas que se ve a continuación.
(opcional) Marque la casilla Show environment variables in build log .
Desmarque la Run script only when installing casilla de verificación.

Cada vez que hace una compilación, se captura la fecha y hora actual en la zona horaria UTC . El -u en el script utiliza UTC en lugar de su zona horaria predeterminada actual. Por lo general, lo mejor para los programadores y administradores de sistemas es utilizar y pensar en UTC en lugar de las zonas horarias locales.

#!/bin/bash buildNumber=$(date -u "+%Y%m%d%H%M") /usr/libexec/PlistBuddy -c "Set :CFBundleShortVersionString $buildNumber" "$INFOPLIST_FILE" # Version number /usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$INFOPLIST_FILE" # Build number echo "DateTime for app version number: $buildNumber"

O haga un híbrido, con un 1.2.3 convencional para el número de versión y una fecha y hora como el número de compilación. Para hacer el híbrido, simplemente comente la línea CFBundleShortVersionString con un # al frente.

Piénselo de esta manera: la "versión corta" ( CFBundleShortVersionString ) es el número de versión pública. La "versión" ( CFBundleVersion ) es más un número de versión interna que podría cambiar con mucha más frecuencia que la versión corta pública. Personalmente utilizo el mismo para ambos, pero muchas personas actualizan la "versión" en cada compilación. De cualquier manera, normalmente actualiza la "versión corta" cuando la lanza a Apple. La frecuencia con la que actualice la "versión" depende de usted y de sus necesidades.

Yo uso CFBundleVersion para indicar compilación interna para CFBundleShortVersionString . Utilizo el vuelo de prueba para enviar compilaciones para mis probadores, por lo que la diferencia entre ellos ha sido extremadamente útil.

Los documentos de Apple dicen que CFBundleVersion "debería ser una cadena compuesta por 3 enteros separados, no negativos y separados por un período" Pero en realidad puede ser MÁS DE 3 partes (como muestra la respuesta anterior). Lo uso para indicar mi versión de desarrollo, digamos que mi CFBundleShortVersionString es 1.0.0, puedo usar 1.0.0.11 para CFBundleVersion para indicar que es mi undécima versión para la versión 1.0.0

Cada CFBundleVersion enviada a la tienda de aplicaciones debería ser más grande que antes o obtendrá ERROR ITMS-90478 : "Versión inválida. La compilación con la versión" xxx "no se puede importar porque se ha cerrado una versión posterior para nuevas entregas de compilación. un número de versión diferente ".

CFBundleShortVersionString solo puede tener 3 partes o obtendrá ERROR ITMS-90060: El valor de la clave CFBundleShortVersionString ''xxx'' en el archivo Info.plist debe ser una lista separada por períodos de un máximo de tres enteros no negativos. "

El tercer número que Basil Bourque mencionó, es decir, el número de versión que aparece en iTunes Connect es donde las cosas pueden complicarse.

Utilizo un número iTunesConnect diferente a CFBundleShortVersionString porque cuando presenté mi aplicación por primera vez en la tienda de aplicaciones ya tenemos muchas rondas de lanzamientos internos. Así que utilicé 1.0 para iTunesConnect number y 5.x para CFBundleShortVersionString. En el próximo lanzamiento a la tienda de aplicaciones proporcioné una función para verificar si hay una versión más nueva en la tienda de aplicaciones y me di cuenta de que ahora tenía problemas porque solo puedo obtener el número de iTunes Connect (usando http://itunes.apple.com/lookup?bundleId= ) entonces necesito hacer algunos cálculos antes de compararlo con CFBundleShortVersionString number.

Intenté solucionarlo utilizando el número iTunesConnect como mi CFBundleShortVersionString, pero recibí el error ERROR ITMS-90062 : "Este paquete no es válido. El valor de la clave CFBundleShortVersionString [xxx] en el archivo Info.plist debe contener una versión superior a esa de la versión previamente aprobada [xxx]. "

Así que les sugiero que siempre los hagan iguales.

CFBundleShortVersionString te brinda la versión de tu aplicación. Por lo general, se incrementa cada vez que publica su aplicación en la tienda de aplicaciones. Esta es la versión que está visible en la sección "Versión" para la página de la App Store de su aplicación.

CFBundleVersion le proporciona el número de compilación que se utiliza para el desarrollo y las pruebas, es decir, para fines "técnicos". El usuario final rara vez está interesado en el número de compilación, pero durante el desarrollo es posible que necesite saber qué se está desarrollando y solucionando en cada compilación. Esto generalmente se incrementa en cada iteración de la versión interna. Y puede usar herramientas de integración continua como Jenkins para auto incrementar el número de compilación en cada compilación.

Los dos números no dependen el uno del otro, pero es una buena idea mantenerlos paralelos para evitar confusiones. Tenga en cuenta que una vez que su aplicación haya superado la revisión de la App Store, necesita aumentar el número de compilación como Phil y como TheTheky ha indicado, independientemente de si lo publica o no.

Caso de uso: supongamos que tienes una compilación bien probada, lista para enviar. Su número de versión es 1.0.0 y el número de compilación es 1.0.0.32 . Una vez que envíe su aplicación, debe actualizar la versión como 1.0.1 y el número de compilación como 1.0.1.0 .