Réponse courte : oui, Apple autorise les live updates, dans certaines limites. Vous pouvez pousser du nouveau JavaScript, HTML et CSS vers une app iOS sans nouvelle revue de l'App Store, tant que la mise à jour ne change pas la nature de l'app. Vous ne pouvez pas télécharger de code natif.
La confusion vient souvent de la confusion entre deux choses : les live updates de code interprétés (autorisés) et le téléchargement de nouveaux code exécutables (non autorisés). Cette page cite les règles, montre où se situe la limite et explique comment Apple l'applique.
Ceci ne constitue pas un conseil juridique. C'est ainsi que les règles sont rédigées aujourd'hui et ainsi que des milliers d'apps les utilisent en production.
Ce que disent réellement les règles d’Apple
Deux textes sont essentiels. Le premier est la directive 2.5.2 de l'App Store Review:
Les applications doivent être autonomes dans leurs bundles et ne peuvent ni lire ni écrire de données en dehors de la zone de conteneur désignée, ni télécharger, installer ou exécuter code qui introduit ou modifie des fonctionnalités de l'application, y compris d'autres applications.
Pris isolément, cela ressemble à une interdiction. L'exception se trouve dans le second texte, section 3.3.1(B) du Contrat de licence Apple Developer Program, que chaque développeur signe :
Du code interprété peut être téléchargé vers une application, mais seulement tant que ce code : (a) ne modifie pas l'objectif principal de l'application en fournissant des fonctionnalités incompatibles avec l'objectif prévu et annoncé de l'application telle que soumise à l'App Store, (b) ne crée pas un store ou une vitrine pour d'autres code ou applications, et (c) ne contourne pas la signature, le sandbox ou d'autres fonctions de sécurité de l'OS.
La règle n'est donc pas « pas de code téléchargé ». C'est « pas de natif code téléchargé, et du code interprété uniquement sous trois conditions ».
La couche web d'une application Capacitor est composée de JavaScript, HTML et CSS s'exécutant dans WKWebView, qui est le moteur WebKit d'Apple. Celui-ci est interprété code, il entre donc dans l'exception. La règle 4.7 va dans le même sens : Apple autorise explicitement les apps à exécuter du contenu HTML5 et JavaScript qui n'est pas intégré au binaire.
Où se situe la limite
| Autorisé avec un live update | Non autorisé avec un live update |
|---|---|
| Corrections de bugs en JavaScript, HTML, CSS | Téléchargement de Swift, Objective-C ou de tout binaire compilé |
| Changements d'UI, de textes ou nouveaux écrans dans votre stack web existante | Transformer l'app en un produit différent (une app de notes qui devient un casino) |
| Tests A/B et déploiements progressifs de code web | Débloquer des fonctionnalités cachées à l'App Review |
| Mise à jour d'images, de traductions, de config | Créer un store qui installe d'autres apps ou code |
| Faire un rollback d'une mauvaise release | Contourner le sandbox, la signature ou les permissions iOS |
Capgo ne déploie que la colonne de gauche. Il remplace le bundle web à l'intérieur de votre application. Tout ce qui est natif, comme un nouveau plugin Capacitor, une nouvelle permission ou une mise à jour SDK, nécessite toujours une release classique sur l'App Store. Les Capgo ciblage de version garantissent qu'un bundle nécessitant de nouveaux code natifs n'atteigne jamais un ancien binaire.
Comment Apple l’applique
Apple juge le fond, pas la technologie. Personne n'est sanctionné pour corriger une faute de frappe via une mise à jour OTA. Ce que Apple traque, c'est une application qui passe la revue en étant une chose et qui en devient une autre après. Cela concerne autant la règle 2.3.1 (pas de fonctionnalités cachées ou non documentées) que la 2.5.2.
En pratique :
- Déployez ce que vous auriez soumis, mais plus rapidement.
- Gardez chaque mise à jour conforme à l'usage décrit dans votre fiche App Store.
- Passez les lancements de fonctionnalités majeures par l'App Review, et utilisez les live updates pour les correctifs et l'itération entre les releases.
- N'utilisez jamais un live update pour activer un comportement que les relecteurs n'ont pas vu.
Dans cette logique, les live updates font naturellement partie de la livraison d'une app iOS. Les équipes React Native le font depuis des années avec CodePush et Expo Updates, et les équipes Capacitor le font avec Capgo.
Quelles stacks le permettent sur iOS ?
La possibilité pour votre app de déployer des mises à jour OTA sur iOS dépend d'une question : votre logique applicative est-elle interprétée au runtime ? JavaScript et les autres code interprétés, oui. Swift, Objective-C et C++ compilés en code machine, non. Les frameworks compilés AOT comme Flutter ne sont éligibles que via un interpréteur.
Compatibilité live update sur iOS par stack
| Stack | Comment le code s'exécute sur iOS | Live updates autorisés ? | Outils |
|---|---|---|---|
| Capacitor | JavaScript, HTML, CSS dans WKWebView (WebKit) | Oui | Capgo |
| Ionic (sur Capacitor) | Identique à Capacitor | Oui | Capgo |
| Cordova | JavaScript dans WKWebView | Oui | Capgo après la migration vers Capacitor, les anciens plugins Cordova |
| React Native / Expo | bundle JS sur Hermes ou JavaScriptCore | Oui, uniquement du JavaScript | Expo Updates, alternatives self-hosted à CodePush |
| NativeScript | JavaScript sur un moteur embarqué | Oui, uniquement du JavaScript | Limité, principalement du sur-mesure |
| Flutter | Dart compilé en AOT vers le code machine code | Uniquement via un interpréteur | Shorebird (interpréteur Dart pour les patchs) |
| Swift / Objective-C natif | Code machine code | Non pour le code natif ; oui pour le JavaScript dans WebKit ou JavaScriptCore | Config à distance et UI pilotée par le serveur |
| .NET MAUI / Xamarin | C# compilé en code machine via AOT | Non | Configuration à distance uniquement |
| Kotlin / Compose Multiplatform | Kotlin/Native compilé en code machine | Non | Configuration à distance uniquement |
| Unity / Unreal | C# via IL2CPP ou C++, compilé | Non pour code, oui pour le contenu | Bundles d'assets, contenu scripté (Lua) |
| Web wrapper (URL distante) | Site web chargé dans une WebView | Toujours en direct, mais risque de revue | Aucun requis, voir la note ci-dessous |
Capacitor, Ionic et Cordova : entièrement couverts
Your app’s web UI and JavaScript business logic run in WKWebView, tandis que le shell natif et les plugins restent natifs. La section 3.3.1(B) du contrat de licence du programme Apple Developer autorise le code interprété téléchargé uniquement s'il préserve la fonction principale de l'app, ne crée pas une code de type storefront, et ne contourne pas la sécurité de l'OS. La directive 4.7 régit séparément les apps proposant des mini-apps HTML5 et JavaScript et ajoute des exigences supplémentaires.
Un live update remplace le bundle web. Le shell natif, les plugins et les permissions restent ceux qu'Apple a examinés. C'est pourquoi Capgo est conforme par conception : il ne peut pas modifier les code natifs, même si vous le vouliez. Les nouveaux plugins ou permissions natifs nécessitent toujours une release sur l'App Store.
React Native et Expo : le JavaScript oui, les modules natifs non
React Native exécute votre bundle JavaScript sur Hermes ou JavaScriptCore. Ce bundle est un code interprété et peut être mis à jour via Live Update, ce qui est précisément le rôle d'Expo Updates et de Microsoft CodePush (retiré en 2025). Les équipes qui quittent CodePush un remplacement.
Tout changement des modules natifs, de la version React Native, ou Info.plist nécessite un nouveau binaire.
Flutter : uniquement via un interpréteur
Sur iOS, Flutter compile le Dart à l'avance en code machine ARM code. Le téléchargement d'un nouveau code machine est interdit, donc le Flutter standard ne peut pas utiliser les live updates. Shorebird résout cela en exécutant du Dart patché code via un interpréteur, ce qui le place sous l'exception de l'code interprété. En savoir plus dans les live updates pour les apps Flutter.
Swift natif, .NET MAUI, Kotlin Multiplatform : pas de mises à jour code natives
Ces stacks produisent du code machine natif. Elles ne peuvent pas télécharger de code natif de remplacement. Une application native peut tout de même télécharger et exécuter du code interprété, comme du JavaScript via JavaScriptCore, si elle respecte les conditions d'Apple. Ce que vous pouvez aussi faire via OTA, c'est modifier des données : remote config, feature flags pour des fonctionnalités déjà validées, UI pilotée par le serveur, images et textes.
Unity et moteurs de jeu : contenu oui, code non
Le code de jeu est compilé. Les asset bundles (niveaux, art, données d'équilibrage) sont du contenu et peuvent être téléchargés. Les langages de scripting embarqués comme Lua sont des code interprétés et suivent les mêmes règles que le JavaScript.
Wrappers d'URL distants : possible, mais risqué pour la validation
Une application qui ne fait que charger votre site web dans une WebView est « mise à jour » à chaque déploiement du site. Le problème n'est pas la règle 2.5.2, mais la règle 4.2 (fonctionnalité minimale) : Apple rejette les apps qui ne sont qu'un site web dans une frame. Compiler l'app web avec Capacitor, ajouter des fonctionnalités natives et utiliser les live updates permet d'éviter cela.
Ce qu'aucune stack ne peut faire sur iOS
Quel que soit votre framework, un live update ne peut pas :
- Télécharger des code natifs, des frameworks ou des bibliothèques dynamiques
- Ajouter de nouvelles permissions ou entitlements
- Transformer l'app en quelque chose que la fiche de l'App Store ne décrit pas
- Activer des fonctionnalités qui ont été cachées lors de l'App Review
Quelle est la suite ?
- La réponse pour Android : Google autorise-t-il les live updates sans revue du Play Store ?
- Détails sur l'application des règles : Comment Apple impose les restrictions sur les mises à jour OTA
- Workflow d'approbation : Capacitor mises à jour OTA : guide d'approbation sur l'App Store
- Histoires de rejets réels : Histoires d'horreur de rejets sur l'App Store
Ship fixes today, not after review
les live updates Capgo envoyez vos changements JavaScript, HTML et CSS vers votre application Capacitor en quelques minutes, avec des canaux, des rollbacks, des mises à jour delta et un chiffrement de bout en bout. C'est open source et auto-hébergeable.
bunx @capgo/cli@latest initConsultez la démarrage rapide pour envoyer votre première mise à jour.
