App Store Connect build number : version et numéro de build

Le build number d'App Store Connect, c'est le numéro de build : la clé CFBundleVersion, qui identifie chaque envoi. La version, CFBundleShortVersionString, est le numéro que tes clients voient sur l'App Store. Apple exige que le couple version et numéro de build soit unique : un numéro de build ne sert qu'une fois pour une même version.

Avec Expo, tu fixes la version toi‑même et EAS peut incrémenter le numéro de build à chaque build de production. Ce guide explique les deux numéros, les règles d'Apple, les erreurs ITMS-90062 et ITMS-90189, et quoi vérifier quand ton build n'apparaît pas.

Je publie mes apps iOS avec Expo et EAS, dont Solys, TradaZen et Nolera. Les réglages montrés plus bas sont ceux de leurs fichiers eas.json.

Version et numéro de build : quelle différence ?

Deux clés de l'Info.plist identifient ton app. La documentation d'Apple sur CFBundleShortVersionString la décrit comme la version visible par l'utilisateur : trois entiers séparés par des points, comme 10.14.1. Celle sur CFBundleVersion parle de la version du build : un à trois entiers, avec seulement des chiffres et des points.

Élément	Clé iOS	Qui la voit	Champ Expo
Version	CFBundleShortVersionString	Tes clients	version
Numéro de build	CFBundleVersion	Toi et Apple	ios.buildNumber

Exemple fictif : pour la version 1.4.0, tu envoies les builds 12, 13 et 14 pendant tes tests, puis tu en choisis un pour la revue. L'aide d'App Store Connect le résume : la version rattache le build à sa fiche, le numéro de build l'identifie partout dans le système.

Les règles d'incrément d'Apple

1. Le couple doit être unique. D'après la documentation de Xcode Cloud, App Store Connect exige une combinaison unique de version et de numéro de build. Une app iPhone peut donc repartir à 1 pour une nouvelle version. Une app Mac, non : son numéro doit toujours monter.
2. Une version approuvée est fermée. Une fois qu'Apple a validé la version 1.4.0, tu ne peux plus lui ajouter de build. La suivante doit porter un numéro plus haut.
3. Chaque nombre se compare comme un entier. 1.10 passe après 1.9, parce que 10 est plus grand que 9. Une version 1.9 envoyée après une 1.20 approuvée sera refusée.

Mon conseil : garde un numéro de build entier qui monte toujours, sans le remettre à 1. Repartir à 1 est permis sur iPhone, mais un numéro unique sur toute la vie de l'app évite de confondre deux builds dans TestFlight. C'est ce que je vois sur mes apps en mode distant : le compteur continue d'une version à l'autre.

Gérer version et build avec Expo et EAS

La page d'Expo sur les versions, mise à jour le 25 septembre 2026, sépare les rôles. La version (version dans app.json) reste à toi : tu la changes quand tu prépares une nouvelle sortie. Le numéro de build (ios.buildNumber) peut être confié à EAS. Expo cite d'ailleurs l'oubli de l'incrémenter comme une cause courante de refus à l'envoi.

Tout se règle dans eas.json :

{
  "cli": {
    "appVersionSource": "remote"
  },
  "build": {
    "production": {
      "autoIncrement": true
    }
  }
}

• "remote" : les serveurs d'EAS gardent le numéro de build. C'est le comportement recommandé depuis EAS CLI 12. Le compteur part de la valeur de ta configuration, ou de 1, puis ios.buildNumber est ignoré.
• "local" : ta configuration fait foi. Avec autoIncrement, EAS modifie ios.buildNumber dans ton fichier, et tu dois committer ce changement à chaque build.
• autoIncrement : la référence d'eas.json accepte true ou "buildNumber" pour le build, et "version" pour monter le dernier chiffre de la version. En mode distant, Expo précise que "version" n'est pas pris en charge.

Chez moi, TradaZen et Nolera sont en remote. Solys est restée en local : son numéro de build vit dans app.json et chaque build de production le fait monter dans le fichier. Les deux marchent, mais le mode distant supprime le risque d'un commit oublié.

Deux commandes complètent le dispositif. eas build:version:set initialise le compteur distant : saisis le dernier numéro envoyé à Apple. eas build:version:sync recopie les valeurs distantes dans ton projet, utile si tu compiles un jour avec Xcode. Avec EAS Update, le mode distant ne marche pas avec la politique nativeVersion : Expo conseille appVersion.

ITMS-90062 : la version est déjà approuvée

Le message ressemble à ceci (numéros fictifs) :

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 a déjà approuvé la version 1.4.0 : tu ne peux plus y ajouter de build. Monte la version dans app.json, par exemple en 1.4.1, puis relance un build. Changer seulement le numéro de build ne suffit pas.

Si l'erreur revient alors que version est à jour, cherche un champ ios.version. D'après la référence de la configuration Expo, il prend le pas sur version pour iOS. Même remède pour l'erreur cousine ITMS-90186, « Invalid Pre-Release Train », qui signale une version fermée aux nouveaux builds.

ITMS-90189 : Redundant Binary Upload

Ici, c'est le numéro de build qui coince :

ERROR ITMS-90189: Redundant Binary Upload. You've already uploaded
a build with build number '12' for version number '1.4.0'.

Le couple 1.4.0 (12) existe déjà chez Apple. Avec Expo, quatre causes reviennent :

• Le profil utilisé n'a pas autoIncrement. Si tu crées un profil à part pour TestFlight, comme celui de Nolera, remets-y l'option.
• Le compteur distant est en retard. Tu es passé en remote après des envois manuels : lance eas build:version:set avec le dernier numéro connu d'Apple.
• Le commit a été oublié en mode local. Le build suivant repart de l'ancien numéro.
• Tu renvoies le même binaire. Avec eas submit, choisis le nouveau build, pas l'ancien.

La correction est toujours la même : un nouveau build avec un numéro plus haut.

« No builds available » : ton build n'apparaît pas

Le build est parti, mais ta fiche ne le propose pas. Vérifie dans cet ordre.

1. Il est encore en traitement. Apple traite chaque build avant de l'afficher et t'envoie un e-mail à la fin. Expo parle en général de 10 à 15 minutes. Selon Apple, au-delà de 24 heures en traitement, il faut ouvrir un ticket Feedback Assistant.
2. Il attend ta déclaration de chiffrement. C'est le statut Missing Compliance, détaillé plus bas.
3. La version ne correspond pas. Un build en 1.4.1 ne se range pas sous une fiche préparée en 1.5.0 dans App Store Connect. Aligne les deux.
4. Une version est sortie entre-temps. D'après l'aide sur le choix du build, la liste ne montre alors que les builds envoyés depuis cette sortie.
5. C'est le testeur qui ne le voit pas. Dans l'app TestFlight, « no builds available » veut souvent dire que le build n'est dans aucun groupe, attend la revue bêta ou a expiré. Le détail est dans TestFlight pour tester ton app iPhone.

Les statuts à connaître

Les statuts qui expliquent le plus souvent un build absent, d'après la liste d'Apple. Processing et Failed n'y figurent pas : ce sont les statuts d'envoi décrits dans le suivi des builds.

Statut	Ce qu'il veut dire	Ta correction
Processing	Apple traite le build	Attendre l'e-mail
Failed	Erreur au traitement	Lire l'erreur, renvoyer
Missing Compliance	Chiffrement non déclaré	Répondre ou Info.plist
Invalid Binary	Envoi non conforme	Corriger, nouveau build
Expired	90 jours dépassés	Nouveau build
Ready to Submit	Prêt pour test ou revue	L'ajouter à un groupe

Déclarer le chiffrement une fois pour toutes

Sans la clé ITSAppUsesNonExemptEncryption, Apple te pose les questions de conformité à chaque nouvelle version. Avec Expo, le champ s'appelle ios.config.usesNonExemptEncryption :

{
  "expo": {
    "ios": {
      "config": {
        "usesNonExemptEncryption": false
      }
    }
  }
}

false veut dire : pas de chiffrement, ou seulement un chiffrement exempté. Apple précise que le chiffrement intégré au système, comme les connexions HTTPS, est en général exempté, et que la réponse couvre aussi tes bibliothèques. Mes trois apps déclarent false. Ne mets false que si c'est vrai pour ton app : la déclaration t'engage.

Peut-on changer le numéro d'un build déjà envoyé ?

Non. Le numéro est inscrit dans le binaire signé : pour le corriger, il faut un nouveau build.

Ce que tu peux changer, c'est le build rattaché à ta version. Apple autorise un seul build par version, mais tu peux le remplacer autant de fois que tu veux jusqu'à l'envoi en revue :

1. Ouvre la version dans App Store Connect, section Build.
2. Survole le build actuel et clique sur le bouton de suppression, le signe moins.
3. Clique sur le bouton d'ajout, le signe plus, choisis le bon build, puis enregistre.

Retirer un build d'une version ne le supprime pas de ton compte. Si la version est déjà en revue, retire d'abord la soumission : la revue repartira de zéro.

Avant ton prochain envoi

Le numéro de build n'est qu'un des contrôles à l'envoi. L'image de build peut déclencher ITMS-90725, et la signature a ses propres pièges, détaillés dans certificat développeur iOS et provisioning profile. La chaîne complète, du build à TestFlight, est dans publier une app iOS sans Mac, et les délais de revue dans délai de validation App Store. Toutes les étapes sont réunies sur la page publier une application sur l'App Store.

Si tu prépares ta première sortie, fais le diagnostic gratuit : il te dit ce qui bloque dans ton projet et t'envoie ma checklist anti-refus Apple. Pour construire l'app, brancher les abonnements et la publier, le Kit iOS suit le parcours en quatre étapes avec le code de départ de mes apps, à ton rythme.

Questions fréquentes

Quelle différence entre version et build number sur App Store Connect ?

La version est le numéro public de ta sortie, comme 1.4.0. Le build number identifie un binaire précis envoyé à Apple pour cette version. Tu peux envoyer plusieurs builds pour une même version, chacun avec son numéro.

Faut-il changer le numéro de build à chaque envoi ?

Oui, pour une même version. Apple refuse un deuxième envoi avec le même couple version et numéro de build, c'est l'erreur ITMS-90189. Avec EAS, autoIncrement s'en charge à chaque build de production.

Le numéro de build doit-il repartir à 1 à chaque version ?

Ce n'est pas obligatoire. Sur iPhone, Apple accepte un numéro plus bas pour une nouvelle version, car seul le couple doit être unique. Un compteur qui monte toujours reste plus simple à suivre.

Comment changer le build number dans App Store Connect ?

Tu ne peux pas modifier le numéro d'un build déjà envoyé. Tu peux en revanche remplacer le build attaché à ta version, depuis la section Build de la fiche, tant qu'elle n'est pas en revue. Pour un nouveau numéro, refais un build.

Pourquoi mon build n'apparaît pas dans App Store Connect ?

Le plus souvent, il est encore en traitement ou attend ta déclaration de chiffrement. Vérifie aussi que sa version correspond à celle de ta fiche. Au-delà de 24 heures en traitement, Apple demande d'ouvrir un ticket.