Version et build de l'application iOS en Swift : une solution simple

Formateur Python en ligne pour débutants

Apprenez Python facilement sans surcharge théorique. Résolvez des tâches pratiques avec vérification automatique et écrivez du code directement dans le navigateur.

Start Course

Comment obtenir la version et le numéro de build de l'application en Swift : explication complète avec code

\n\n

Avez-vous déjà demandé pourquoi dans l'App Store une même application peut s'appeler « MonMessager 3.2 », alors que dans les paramètres du téléphone elle est « 3.2.1 (45) » ? Ou pourquoi les développeurs vous demandent d'envoyer le « numéro de build » lorsque vous signalez un bug ? La réponse est simple : à l'intérieur de chaque application iOS vivent deux nombres cachés — la version de l'application et le numéro de build. Et aujourd'hui, nous allons apprendre à les extraire avec Swift. C'est l'une des questions les plus populaires sur Stack Overflow (des dizaines de milliers de vues !), et ce n'est pas pour rien : connaître ces deux lignes de code peut vous sauver des heures de débogage et de nerfs d'utilisateurs.

\n\n

Dans cet article, nous ne nous contenterons pas de copier une réponse de forum. Nous allons comprendre ce qu'est la version et le build, à quoi ils servent, comment les obtenir correctement et, surtout, comment éviter les pièges. C'est parti !

\n\n

Qu'est-ce que la version (version) et le numéro de build (build number) ?

\n\n

Avant d'écrire du code, clarifions les termes. Dans Xcode, dans le fichier Info.plist (ou dans les paramètres du projet), il y a deux clés :

\n\n
    \n
  • CFBundleShortVersionString — c'est ce que l'utilisateur voit dans l'App Store et dans les paramètres de l'application. Cela ressemble généralement à « 1.0 », « 2.3.1 », etc. C'est la version pour l'utilisateur.
  • \n
  • CFBundleVersion — c'est le numéro de build interne. Il peut être n'importe quoi : « 42 », « 20240315 », « 1.0.0.123 ». C'est la version pour le développeur, qui permet de distinguer différents builds d'une même version.
  • \n
\n\n

Pourquoi séparer ? Imaginez que vous ayez publié la version 1.0, mais que vous ayez trouvé un bug critique. Vous le corrigez sans changer les fonctionnalités — c'est toujours la version 1.0 pour l'utilisateur, mais vous augmentez le numéro de build (par exemple, de 1 à 2). Ainsi, vous ne trompez pas l'utilisateur et vous voyez dans Crashlytics quel build exact a planté.

\n\n

La méthode la plus simple : Bundle.main

\n\n

Apple fournit un accès pratique à ces données via l'objet Bundle.main. Voici la solution classique que vous trouverez sur Stack Overflow :

\n\n
import UIKit\n\nclass ViewController: UIViewController {\n\n    override func viewDidLoad() {\n        super.viewDidLoad()\n        \n        // Obtenir la version de l'application\n        let appVersion = Bundle.main.infoDictionary?["CFBundleShortVersionString"] as? String ?? "Inconnue"\n        // Obtenir le numéro de build\n        let buildNumber = Bundle.main.infoDictionary?["CFBundleVersion"] as? String ?? "Inconnu"\n        \n        print("Version de l'application : \\(appVersion)")\n        print("Numéro de build : \\(buildNumber)")\n        \n        // Exemple d'utilisation dans l'interface\n        versionLabel.text = "Version \\(appVersion) (build \\(buildNumber))"\n    }\n}\n
\n\n

Le génie est dans la simplicité. Mais détaillons chaque ligne :

\n
    \n
  • Bundle.main — c'est le bundle principal de votre application (fichier .app).
  • \n
  • infoDictionary — un dictionnaire qui lit le Info.plist.
  • \n
  • Nous utilisons un cast optionnel avec as? String et l'opérateur ?? au cas où la clé serait absente (bien que cela soit peu probable).
  • \n
\n\n

Approche avancée : lire depuis ProcessInfo

\n\n

Vous voulez avoir l'air d'un pro ? Utilisez ProcessInfo. Cette classe en sait plus sur le système qu'un simple plist. Mais pour la version de l'application, elle n'apporte rien de nouveau, mais elle peut afficher le système d'exploitation. Cependant, il y a une astuce : si vous encapsulez la récupération des données dans une extension, le code devient plus propre et réutilisable.

\n\n
import Foundation\n\nextension Bundle {\n    var appVersion: String {\n        return infoDictionary?["CFBundleShortVersionString"] as? String ?? "Inconnue"\n    }\n    \n    var buildNumber: String {\n        return infoDictionary?["CFBundleVersion"] as? String ?? "Inconnu"\n    }\n    \n    var fullVersion: String {\n        return "Version \\(appVersion) (build                

Blogs

Book Recommendations