Bitcode : qu'est-ce que c'est, bytecode intermédiaire et compilation

Qu'est-ce que Bitcode dans le développement iOS

Bitcode est une représentation intermédiaire d'un programme (Intermediate Representation, IR) générée par l'infrastructure du compilateur LLVM. Apple a introduit la prise en charge de Bitcode à partir de Xcode 7 et iOS 9 comme exigence obligatoire pour les applications watchOS et optionnelle pour iOS et tvOS. À partir de Xcode 14, l'exigence a été supprimée pour toutes les plateformes sauf watchOS.

Histoire de Bitcode

Le concept de représentation intermédiaire de code existe depuis les années 2000 dans le cadre du projet LLVM, fondé par Chris Lattner à l'Université de l'Illinois. Apple a adapté LLVM pour Xcode en 2011, et en 2015 a présenté Bitcode comme un moyen de mettre à jour les applications sans les renvoyer à l'App Store. La technologie a été annoncée à la WWDC 2015 dans la session « What's New in Xcode ».

Différence entre Bitcode et code machine

Le code machine est constitué d'instructions binaires pour un processeur spécifique : arm64, armv7 ou x86_64. Bitcode est stocké dans un format indépendant du matériel, ce qui permet à l'App Store de générer des fichiers binaires optimisés pour différentes architectures à partir d'une seule représentation source. Cette différence fondamentale définit tous les avantages de la technologie.

Bitcode n'est pas un fichier exécutable. C'est LLVM IR au format binaire que le développeur envoie à l'App Store avec les métadonnées du projet. La boutique d'applications exécute le processus de recompilation, adaptant le code pour chaque plateforme cible et version du système d'exploitation.

Comment Bitcode fonctionne dans la compilation iOS

Le processus de génération de Bitcode commence avec le frontal du compilateur, qui convertit le code source Swift ou Objective-C en LLVM IR. Lors de la phase d'édition de liens, Xcode empaquette l'IR dans des fichiers au format .bc (Bitcode), qui sont ensuite envoyés à l'App Store avec l'archive .xcarchive. L'App Store, à son tour, exécute le processus de recompilation de son côté.

Étape LLVM et génération de code intermédiaire

L'infrastructure LLVM se compose de trois parties : le frontal (Clang pour C/ObjC, Swift Frontend pour Swift), l'optimiseur Middle-End et le générateur de code machine (back-end). Bitcode est le résultat des deux premières étapes sans passer à la génération d'instructions assembleur. Le Middle-End effectue des optimisations indépendantes de la plateforme : élimination de code mort, inlinage et repliement de constantes.

// Exemple de code source Swift
func calculateSum(a: Int, b: Int) -> Int {
    return a + b
}

// LLVM IR après compilation (simplifié)
; define i32 @calculateSum(i32 %a, i32 %b)
; %result = add i32 %a, %b
; ret i32 %result

Après la génération de l'IR, le compilateur effectue une série d'optimisations au niveau de la représentation : élimination de code mort, inlinage de fonctions et repliement de constantes. Ces optimisations sont indépendantes de l'architecture et sont conservées dans Bitcode. Lors de la recompilation dans l'App Store, des optimisations dépendantes de l'architecture sont ajoutées, comme le réordonnancement d'instructions pour un processeur spécifique.

Recompilation dans l'App Store

App Store Connect reçoit l'archive avec Bitcode et exécute sa propre infrastructure de compilation. Le système détermine l'architecture cible de l'appareil de l'utilisateur et génère du code machine, en l'optimisant davantage pour les caractéristiques spécifiques du processeur. Pour arm64e (processeurs A12+ et série M), des optimisations de sécurité supplémentaires sont appliquées.

Ce processus s'appelle App Thinning — une technologie qui livre à un appareil uniquement les ressources et le code nécessaires pour son architecture. Un utilisateur d'iPhone avec un processeur A17 Pro reçoit un fichier binaire optimisé pour arm64e, sans instructions superflues pour les architectures plus anciennes. Cela réduit le temps de téléchargement et économise de l'espace sur l'appareil.

Avantages de l'utilisation de Bitcode

Bitcode offre plusieurs avantages clés aux développeurs d'applications iOS. Le principal est l'optimisation automatique pour les nouveaux processeurs Apple sans avoir à renvoyer une mise à jour à l'App Store. Ceci est particulièrement pertinent lors de la transition vers de nouvelles architectures, comme le passage de armv7 à arm64.

Optimisation pour les nouvelles architectures

Lorsqu'Apple publie un processeur avec une nouvelle architecture, les applications envoyées avec Bitcode sont automatiquement recompilées pour celle-ci. Le développeur n'a pas besoin de reconstruire le projet et de publier une mise à jour — l'App Store le fait de son côté lors du premier téléchargement par l'utilisateur. Ceci est particulièrement important pour les applications durables qui sont maintenues pendant des années.

Réduction de la taille du fichier binaire

App Thinning combiné à Bitcode peut réduire la taille de l'application installée de 15 à 40 %. L'App Store génère uniquement les instructions machine nécessaires pour un appareil spécifique, éliminant le code pour d'autres architectures et les variations pour différentes versions d'iOS. En pratique, cela signifie qu'un utilisateur avec un nouvel iPhone reçoit un fichier binaire compact.

Selon Apple WWDC 2015 Session 102, l'utilisation de Bitcode et d'App Thinning peut réduire la taille de l'application téléchargée en moyenne de 25 % par rapport à un fichier binaire universel contenant toutes les architectures. Pour une application de 100 Mo, l'économie peut atteindre jusqu'à 40 Mo sur l'appareil de l'utilisateur.

• Adaptation automatique aux nouveaux processeurs sans que le développeur ait à reconstruire le projet
• Réduction du temps de téléchargement de l'application sur l'appareil de l'utilisateur
• Distribution simplifiée — une archive pour toutes les architectures, un ensemble de métadonnées
• Compatibilité future — l'application fonctionne sur des processeurs Apple pas encore sortis

Comment activer Bitcode dans un projet Xcode

La configuration de Bitcode se fait dans les paramètres de compilation de Xcode. Le paramètre Enable Bitcode se trouve dans les Build Settings et est activé par défaut pour les nouveaux projets, mais les développeurs peuvent le désactiver pour le débogage ou lors de l'utilisation de bibliothèques tierces sans prise en charge de Bitcode.

Configuration via Build Settings

// Build Settings -> Apple Clang - Code Generation
// Enable Bitcode = YES

// Ou via Info.plist pour des cibles individuelles
@property (nonatomic, assign) BOOL enableBitcode;
- (void)configureBuildSettings {
    // Vérification du statut Bitcode dans la configuration
    if (self.enableBitcode) {
        NSLog(@"Bitcode is enabled for this target");
    } else {
        NSLog(@"Bitcode is disabled");
    }
}

Pour vérifier si l'archive contient Bitcode, ouvrez le fichier .xcarchive via Xcode Organizer ou exécutez la commande otool -l dans le Terminal. La présence d'une section __LLVM dans le fichier binaire confirme que Bitcode est activé et correctement empaqueté. Si la section est absente, Bitcode n'a pas été généré lors de la compilation.

Vérification via le Terminal

# Vérification de la présence de Bitcode dans l'archive
otool -l YourApp.app/YourApp | grep __LLVM

# Sortie : s'il y a une section __LLVM — Bitcode est présent
# Si la sortie est vide — Bitcode n'est pas activé ou n'a pas été généré

# Vous pouvez également vérifier avec la commande size
size -m -l YourApp.app/YourApp | grep __LLVM

Lors de l'utilisation de bibliothèques tierces via CocoaPods ou SPM, assurez-vous que toutes les dépendances sont compilées avec Bitcode. Si au moins une bibliothèque ne prend pas en charge Bitcode, Xcode générera une erreur d'édition de liens lors de l'archivage. Pour CocoaPods, vérifiez le flag bitcode_enabled dans les subspecs ou utilisez use_frameworks ! avec enable_bitcode.

Limitations et pièges de Bitcode

Bitcode n'est pas une solution universelle pour tous les types de projets iOS. La technologie a des limitations que le développeur doit prendre en compte avant d'activer l'option dans la configuration de compilation. Comprendre ces limitations aide à éviter les problèmes lors de l'archivage et de la publication.

Compatibilité avec les bibliothèques

Toutes les bibliothèques tierces ne sont pas fournies avec la prise en charge de Bitcode. Si une bibliothèque est distribuée uniquement sous forme de fichier binaire compilé sans Bitcode, le projet avec l'option activée ne compilerait pas. Dans ce cas, le développeur devra soit désactiver Bitcode, soit demander une version avec Bitcode au fournisseur. Ceci est particulièrement pertinent pour les anciennes bibliothèques qui ne sont plus mises à jour.

Débogage et rapports d'incidents

Les rapports d'incidents provenant d'applications compilées avec Bitcode nécessitent un traitement supplémentaire. Les symboles (dSYM) pour le code recompilé sont générés par l'App Store et sont disponibles en téléchargement via Xcode Organizer. Sans le chargement des fichiers dSYM correspondants, la pile d'appels dans les rapports d'incidents sera illisible, ce qui rend le diagnostic des problèmes difficile.

• Téléchargement dSYM — obligatoire pour décoder les journaux d'incidents de l'App Store après la recompilation
• Taille de l'archive — .xcarchive avec Bitcode prend plus de place sur le disque du développeur
• Temps de compilation — la génération de Bitcode augmente la phase de compilation du projet d'environ 10 à 15 %
• macOS — Bitcode n'est pas pris en charge pour les applications macOS et les applications watchOS
• Projets hérités — la migration de grands projets peut nécessiter la mise à jour de toutes les dépendances

À partir d'iOS 17 et Xcode 15, Apple n'exige pas l'activation obligatoire de Bitcode pour la publication sur l'App Store. Cependant, pour les applications watchOS, Bitcode reste une exigence obligatoire au niveau de la politique d'App Store Connect. Il est recommandé aux développeurs d'activer Bitcode pour les nouveaux projets si toutes les dépendances le prennent en charge.