Il s'agit de ma première soumission d'application iOS et je ne veux pas que mon application soit rejetée.

Ceci est tiré des documents Apple:

CFBundleVersion (String - iOS, OS X) spécifie le numéro de version de build du bundle, qui identifie une itération (publiée ou non) du bundle. Le numéro de version de build doit être une chaîne composée de trois entiers non négatifs séparés par des points, le premier entier étant supérieur à zéro. La chaîne ne doit contenir que des caractères numériques (0-9) et point (.). Les zéros non significatifs sont tronqués à partir de chaque entier et seront ignorés (c'est-à-dire que 1.02.3 équivaut à 1.2.3). Cette clé n'est pas localisable.

CFBundleShortVersionString (String - iOS, OS X) spécifie le numéro de version de l'édition du bundle, qui identifie une itération publiée de l'application. Le numéro de version de la version est une chaîne composée de trois entiers séparés par des points. Le premier entier représente les révisions majeures de l'application, telles que les révisions qui implémentent de nouvelles fonctionnalités ou des changements majeurs. Le deuxième entier désigne les révisions qui implémentent des fonctionnalités moins importantes. Le troisième entier représente les versions de maintenance.

La valeur de cette clé diffère de la valeur de «CFBundleVersion», qui identifie une itération (publiée ou non) de l'application. Cette clé peut être localisée en l'incluant dans vos fichiers InfoPlist.strings.

Mais cela semble un peu étrange. Mon interprétation pour cela est de mettre les deux valeurs de la même manière, à savoir:

CFBundleVersion: 1.0.0
CFBundleShortVersionString: 1.0.0

Quelqu'un peut-il confirmer à 100% que c'est ce que je suis censé mettre?

Pensez-y de cette façon: la "version courte" ( CFBundleShortVersionString) est le numéro de version publique. La "version" ( CFBundleVersion) est plus un numéro de version interne qui pourrait changer beaucoup plus fréquemment que la "version courte" publique. Personnellement, j'utilise la même chose pour les deux mais beaucoup de gens mettent à jour la "version" sur chaque build. Dans les deux cas, vous mettez généralement à jour la «version courte» lorsque vous la publiez sur Apple. La fréquence de mise à jour de la «version» dépend de vous et de vos besoins.

CFBundleShortVersionString vous donne la version de votre application. Il est généralement incrémenté chaque fois que vous publiez votre application sur l'App Store. Il s'agit de la version visible dans la section "Version" de la page App Store de votre application.

CFBundleVersion vous donne le numéro de build qui est utilisé pour le développement et les tests, à savoir à des fins "techniques". L'utilisateur final est rarement intéressé par le numéro de build, mais pendant le développement, vous devrez peut-être savoir ce qui est développé et corrigé sur chaque build. Ceci est généralement incrémenté à chaque itération de la version interne. Et vous pouvez utiliser des outils d'intégration continue comme Jenkins pour incrémenter automatiquement le numéro de build sur chaque build.

Les deux nombres ne dépendent pas l'un de l'autre, mais c'est une bonne idée de les garder parallèles pour éviter toute confusion. Gardez à l'esprit qu'une fois que votre application a passé l'examen de l'App Store, vous devez incrémenter le numéro de version comme Phil et likeTheSky l'ont déclaré, que vous la publiez ou non.

Cas d'utilisation: disons que vous avez une version bien testée, prête à être soumise. Son numéro de version est 1.0.0 et le numéro de build est 1.0.0.32 . Une fois que vous avez soumis votre application, vous devez mettre à jour la version comme 1.0.1 et le numéro de build comme build 1.0.1.0 .

La réponse par rmaddy est correcte. J'ajouterai encore deux réflexions.

Numéro de troisième version

Tenez compte du troisième numéro de version, spécifié sur le site Web iTunesConnect dans le cadre de la définition de votre application. Si ce nombre est différent des deux dans Xcode, Apple vous avertit. Vous pouvez ignorer l'avertissement, car ce n'est pas un show-stopper (pas une "erreur").

Date-Heure comme version

De plus, vous n'avez pas besoin d'utiliser trois nombres avec ponctuation. Cela peut avoir un sens pour certaines applications, où traditionnellement les changements dans le premier nombre indiquaient une sorte de changement radical affectant généralement la compatibilité.

Pour d'autres applications, vous voudrez peut-être utiliser simplement une valeur date-heure dans le style de format standard ISO 8601 (AAAAMMJJHHMM). Par exemple 201606070620,. Cet ordre année-mois-date-heure-minute rend un nombre toujours croissant, toujours de la même longueur en raison du remplissage de zéro, qui, lorsqu'il est trié par ordre alphabétique, est également chronologique.

J'ai utilisé avec succès ce style de numéros de version sur une application iOS d'expédition fonctionnant sous iOS 7, 8 et 9.

Vous pouvez même automatiser la génération de cette valeur. Dans votre projet Target> Build Phases> Run Scriptpanneau:

1. Précisez dans le Shellchamp:/bin/sh
2. Collez le script de 5 lignes ci-dessous.
3. (facultatif) Cochez la Show environment variables in build logcase.
4. Décochez la Run script only when installingcase.

Chaque fois que vous effectuez une génération, la date-heure actuelle dans le fuseau horaire UTC est capturée. L' -uindicateur dans le script utilise UTC plutôt que votre fuseau horaire par défaut actuel. Il est généralement préférable pour les programmeurs et les administrateurs système d'utiliser et de penser en UTC plutôt qu'en fuseaux horaires locaux.

#!/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"

Ou faites un hybride, avec un conventionnel 1.2.3pour le numéro de version et une date-heure comme numéro de build. Pour faire l'hybride, commentez simplement la CFBundleShortVersionStringligne avec un #devant.

Le schéma le plus judicieux pour moi est d'utiliser le numéro de version (c'est-à-dire CFBundleShortVersionString) pour le numéro de version réel, puis d'utiliser le numéro de version (c'est-à-dire CFBundleVersion) pour représenter la soumission à l'App Store. Donc, à moins qu'il y ait des problèmes et donc des re-soumissions, ce nombre est toujours 1. Pour une nouvelle version, je réinitialise à 1 si la précédente avait des problèmes lors des tests TestFlight ou en révision.

Les numéros de build permettent de nommer chacune des soumissions que vous fournissez pour une version particulière. Comme décrit dans les définitions ci-dessus, la collection de toutes les versions que vous fournissez pour une version particulière de votre application est appelée «train de versions» de cette version. Pour les applications iOS, les numéros de build doivent être uniques dans chaque train de versions, mais ils n'ont pas besoin d'être uniques dans différents trains de versions [je souligne]. C'est-à-dire que pour les applications iOS, vous pouvez à nouveau utiliser les mêmes numéros de version dans différents trains de versions si vous le souhaitez.

Extrait de la note technique TN2420: numéros de version et numéros de construction .

J'utilise CFBundleVersion pour indiquer la construction interne de CFBundleShortVersionString . J'utilise le vol d'essai pour soumettre des builds à mes testeurs, donc la différence entre eux a été extrêmement utile.

Selon les documents Apple, CFBundleVersion "devrait être une chaîne composée de 3 entiers non négatifs séparés par des points" Mais en réalité, cela peut être PLUS DE 3 parties (comme le montre la réponse ci-dessus). J'utilise cela pour indiquer ma version de développement, disons que mon CFBundleShortVersionString est 1.0.0, je peux utiliser 1.0.0.11 pour CFBundleVersion pour indiquer qu'il s'agit de ma 11e version pour la version 1.0.0

Chaque version CFBundleVersion soumise à l'App Store doit être plus volumineuse qu'avant, sinon vous obtiendrez ERREUR ITMS-90478 : "Version non valide. La version avec la version" xxx "ne peut pas être importée car une version ultérieure a été fermée pour les soumissions de nouvelles versions. Choisissez un numéro de version différent. "

CFBundleShortVersionString ne peut avoir que 3 parties ou vous obtiendrez ERREUR ITMS-90060: La valeur de la clé CFBundleShortVersionString 'xxx' dans le fichier Info.plist doit être une liste séparée par des points d' au plus trois entiers non négatifs. "

Le troisième numéro mentionné par Basil Bourque, c'est-à-dire le numéro de version affiché sur iTunesConnect, est celui où les choses peuvent se compliquer.

J'utilise un numéro iTunesConnect différent de CFBundleShortVersionString parce que lorsque j'ai soumis mon application pour la première fois à l' App Store, nous avons déjà de nombreuses séries de versions internes. J'ai donc utilisé 1.0 pour le numéro iTunesConnect et 5.x pour CFBundleShortVersionString. Dans la prochaine version de l'App Store, j'ai fourni une fonction pour vérifier s'il existe une version plus récente dans l'App Store et j'ai réalisé que j'avais des problèmes maintenant parce que je ne peux obtenir que le numéro iTunesConnect (en utilisant http://itunes.apple.com/lookup?bundleId=) donc je dois faire un calcul avant de le comparer avec le numéro CFBundleShortVersionString.

J'ai essayé de résoudre ce problème en utilisant le numéro iTunesConnect comme CFBundleShortVersionString, mais j'ai obtenu l'erreur ERROR ITMS-90062 : "Ce bundle n'est pas valide. La valeur de la clé CFBundleShortVersionString [xxx] dans le fichier Info.plist doit contenir une version supérieure à celle-ci de la version précédemment approuvée [xxx]. "

Je suggérerai donc de toujours les faire de même.

Quelque chose que je n'ai jamais vu discuté nulle part est quel est le nombre maximum pour chaque champ dans une CFBundleVersion?

En définissant CFBundleVersion dans une application sur 1.1.1 et en regardant la valeur hexadécimale de la version dans "lsregister -dump", j'ai déterminé que la valeur maximale du premier champ est (2 ^ 22) -1 ou 4194303, et la valeur maximale les valeurs des deuxième et troisième champs sont (2 ^ 21) -1 ou 2097151.

Les 3 champs ajoutent jusqu'à 64 bits.

Cela a des implications pour ceux d'entre nous qui utilisent CFBundleVersion en fonction de la date et de l'heure.

Je définissais le premier champ sur AAAAMMJJ. C'est toujours supérieur aux versions maximales autorisées et cela conduisait à des résultats imprévisibles, c'est le moins qu'on puisse dire, lorsque Launch Services décidait de la version d'une application à exécuter lorsque plusieurs versions étaient installées et que vous utilisiez quelque chose comme `` open -a Appname 'depuis la ligne de commande.

Veuillez diffuser largement cela. Je suis sûr que beaucoup de gens ne sont pas d'accord avec cela.

À partir de maintenant, la documentation Apple pour lesCFBundleVersion États [c'est moi qui souligne]:

La version de build qui identifie une itération du bundle.

...

Cette clé est une chaîne lisible par machine composée d' un à trois entiers séparés par des points, tels que 10.14.1. La chaîne ne peut contenir que des caractères numériques (0-9) et des points.

...

Vous pouvez inclure plus d'entiers mais le système les ignore.

Pour CFBundleShortVersionString[c'est moi qui souligne]:

La version ou le numéro de version du bundle.

...

Cette clé est une chaîne visible par l'utilisateur pour la version du bundle. Le format requis est trois entiers séparés par des points, tels que 10.14.1. La chaîne ne peut contenir que des caractères numériques (0-9) et des points.

Je suggérerais simplement d'incrémenter automatiquement CFBundleVersionpour chaque build (ou chaque version de TestFlight) et de le réinitialiser à 0 chaque fois que vous changez CFBundleShortVersionString.

Vous devez explicitement planifier, ou concevoir un moyen cohérent, de mettre à jour la version visible par l'utilisateur dans CFBundleShortVersionString.