Build et déploiement dans le développement mobile : ce que c'est, quels formats et comment ça fonctionne

Formats de build : APK, AAB, IPA

APK vs AAB

APK (Android Package Kit) — le format traditionnel de build et de publication d'applications mobiles sur Android. L'APK contient tout le code, les ressources et le manifeste de l'application. AAB (Android App Bundle) — un format introduit par Google en 2018 et devenu obligatoire pour les nouvelles applications depuis août 2021. L'AAB ne s'installe pas directement — Google Play génère dynamiquement un APK optimisé pour chaque appareil à partir de l'AAB.

Avantages de l'AAB : la taille du téléchargement est en moyenne 15 % inférieure (en ne délivrant que les ressources nécessaires : bonnes densités d'écran, langues, architectures CPU). L'AAB prend également en charge la livraison modulaire — vous pouvez charger des modules à la demande (Play Feature Delivery) ou différés (Play On-Demand). Pour les développeurs, l'AAB est obligatoire ; pour la distribution hors Google Play (sideloading, marketplaces) — seulement l'APK.

IPA

IPA (iOS App Store Package) — le fichier installable d'iOS, qui est une archive ZIP contenant une application signée. L'IPA contient un dossier Payload/ avec le bundle .app, le Provisioning Profile et la signature. L'IPA est construit uniquement sur macOS via Xcode, qui crée une archive (.xcarchive) et exporte l'IPA. Pour la distribution via l'App Store, l'IPA est signé avec un Apple Distribution Certificate ; pour Ad Hoc ou Enterprise — avec les certificats correspondants.

Compilation et optimisation : JIT, AOT, ART, Bitcode

JIT vs AOT

JIT (Just-In-Time) — compilation du code pendant l'exécution de l'application, affectant la vitesse de build et de publication. Sur Android jusqu'à la version 5.0 (Lollipop), Dalvik VM avec compilation JIT était utilisé. À chaque lancement de l'application, le bytecode DEX était converti en code machine « à la volée ». Inconvénient : ralentissement au premier lancement et consommation d'énergie supplémentaire. AOT (Ahead-Of-Time) — compilation du code avant le lancement de l'application, pendant l'installation. À partir d'Android 7.0 (Nougat), ART (Android Runtime) compile complètement l'application lors de l'installation.

ART (Android Runtime) — l'environnement d'exécution qui a remplacé Dalvik dans Android 5.0. ART utilise une approche hybride : compilation AOT lors de l'installation + JIT pour les méthodes fréquemment exécutées. Cela combine la vitesse d'AOT (démarrage rapide) avec la flexibilité de JIT (optimisation adaptative). Résultat : les performances des applications Android ont augmenté de 20 à 30 % par rapport à Dalvik. Pour les développeurs, la transition vers ART est transparente — le code ne nécessite aucune modification.

Bitcode et App Thinning

Bitcode — une représentation intermédiaire de code (IR) qu'Apple utilise pour recompiler l'IPA pour différentes architectures de processeur. Bitcode est optionnel : pour les applications iOS, il est activé par défaut ; pour watchOS et tvOS, il est obligatoire. Apple peut recompiler le Bitcode lors de la sortie de nouveaux processeurs sans intervention du développeur. App Thinning — la technologie d'Apple qui inclut Slicing (livraison uniquement des ressources nécessaires à l'appareil) et On-Demand Resources (chargement des ressources à la demande). App Thinning réduit la taille du téléchargement depuis l'App Store de 30 à 50 %.

DEX — format de bytecode pour Android, exécuté par ART/Dalvik. Le code source Kotlin/Java est compilé en fichiers class, puis en DEX via dx ou d8 (un outil moderne et plus rapide). Multidex — un mécanisme pour les applications qui dépassent la limite de 65 536 méthodes dans un seul fichier DEX. Dans les projets modernes, multidex est activé automatiquement si targetSdkVersion >= 21.

Signature de code : Code Signing, Keystore, Provisioning Profile

Android : Keystore

Keystore — un fichier contenant la clé privée et le certificat pour signer une application Android lors du build. Keystore est créé via keytool (la commande -genkey) ou Android Studio. Important : Keystore ne peut pas être perdu — sans lui, vous ne pouvez pas mettre à jour l'application sur Google Play. Paramètres de signature : keyAlias, keyPassword, storePassword et storeFile. Format : JKS (Java KeyStore) ou PEPK (Play Encrypted Private Key) pour AAB.

App Bundle ID (Android) — l'identifiant unique de l'application en notation de paquet (com.example.app). Version Code — un entier pour la numérotation interne des versions (chaque nouveau build l'incrémente). Version Name — une chaîne affichée à l'utilisateur (1.2.3). Ces paramètres sont définis dans build.gradle au niveau de l'application.

iOS : Apple Certificate et Provisioning Profile

Apple Certificate — un certificat numérique qui vérifie l'identité du développeur. Types : Development (pour le débogage), Distribution (pour l'App Store), Ad Hoc (pour une distribution limitée). Les certificats sont créés dans Apple Developer Account et téléchargés dans Keychain. Provisioning Profile — un fichier qui lie le certificat, l'App ID (Bundle Identifier) et une liste d'appareils autorisés. Sans Provisioning Profile, l'application ne s'exécutera pas sur un appareil.

Bundle ID (iOS) — l'identifiant unique de l'application (com.example.app). Build Number — le numéro de build, incrémenté à chaque build. Marketing Version — la version affichée à l'utilisateur. Gestion des versions : pour iOS, les paramètres sont définis dans Info.plist et Project Settings ; pour Android — dans build.gradle. Chez IT Sectr, nous automatisons les mises à jour de version via Fastlane — cela élimine les erreurs humaines lors de la publication.

Processus de publication dans les magasins

Google Play Console

Google Play Console — un outil pour publier des applications Android. Processus : inscription d'un compte développeur ($25 unique), création d'une application, remplissage des métadonnées (nom, description, captures d'écran, catégorie), téléchargement de l'AAB, configuration des prix et de la distribution, révision. Google vérifie l'application automatiquement (virus, conformité aux politiques) et manuellement pour certaines catégories. La révision prend de quelques heures à 2-3 jours.

App Store Connect

App Store Connect — la plateforme d'Apple pour publier des applications iOS. Processus : compte développeur Apple ($99/an), création d'une application dans App Store Connect, préparation de l'IPA dans Xcode (Archive → Distribute App → App Store Connect), téléchargement via Transporter ou Xcode, remplissage des métadonnées, soumission à la révision. App Review — la révision manuelle d'Apple peut prendre de 24 heures à 7 jours. Raisons typiques de rejet : boutons non fonctionnels, contenu incomplet, demande d'autorisations sans explication.

Tests bêta : TestFlight, Closed/Open Beta

TestFlight (iOS)

TestFlight — l'outil officiel d'Apple pour les tests bêta d'applications iOS. TestFlight prend en charge Internal Testing (jusqu'à 100 testeurs par e-mail, sans révision) et External Testing (jusqu'à 10 000 testeurs, avec révision Apple). Les builds sont disponibles pendant 90 jours, après quoi un nouveau build doit être téléchargé. TestFlight met automatiquement à jour l'application chez les testeurs lors du téléchargement d'un nouveau build.

Internal / Closed / Open Beta (Android)

Internal Testing (Android) — jusqu'à 100 testeurs, sans révision Google, le build est disponible immédiatement. Closed Beta — jusqu'à 1000 testeurs par e-mail ou Google Groups, sans révision. Open Beta — testeurs illimités via un lien public, avec révision Google. Staged Rollout — augmentation progressive du pourcentage d'utilisateurs recevant la mise à jour (5 % → 20 % → 50 % → 100 %). C'est la méthode de publication la plus sûre.

App Thinning (iOS) — réduction automatique de la taille de l'IPA téléchargé : Slicing (uniquement les ressources nécessaires à l'appareil), Bitcode (optimisation du processeur), On-Demand Resources (téléchargement à la demande). Chez IT Sectr, nous utilisons TestFlight pour les tests bêta iOS et Internal Testing pour Android — cela permet de détecter les problèmes avant une publication massive.