Super apps React Native : partager le runtime sans dupliquer le natif

Le showcase de super app de Callstack met en lumière un risque discret des architectures mobiles fédérées : les équipes peuvent être indépendantes sans que les instances natives le soient. Il faut choisir explicitement ce qui vit dans le binaire et ce qui peut être chargé plus tard.

Trois rôles avec des frontières précises

Le Super App Showcase (nouvelle fenêtre) utilise Re.Pack et Module Federation V2. Le Host Shell possède le binaire natif, le boot et la navigation racine. Les mini-apps fournissent des domaines fonctionnels ; un Shared SDK singleton porte les contrats et ressources partagées.

Callstack insiste sur deux règles : ne pas enregistrer deux fois le même module natif et aligner les dépendances partagées. Une seconde instance de React peut aussi casser hooks et état. La fédération ne dispense donc pas d’un contrat de versions.

Définir la compatibilité d’une mini-app

Avant de distribuer un bundle indépendamment, préciser le Host minimal qu’il accepte et les fonctionnalités natives dont il dépend. Une mini-app JavaScript ne peut pas faire apparaître un module absent du binaire installé.

Le cas de test décisif n’est pas seulement « le dernier host ouvre la dernière mini-app ». Il faut aussi essayer une version plus ancienne encore installée et un lancement sans réseau après une première utilisation. Définir un comportement lorsque le bundle n’est pas compatible évite de transformer un problème de livraison en écran blanc.

Éviter de fédérer trop tôt

Une équipe qui partage simplement un design system n’a pas nécessairement besoin de chargement dynamique. Le coût comprend l’observabilité, les caches, le rollback et les contrats entre équipes, en plus du bundler.

Le showcase est une référence pour examiner ces choix, pas une preuve qu’une super app améliore tous les projets. Un prototype sur un seul domaine fonctionnel permet de mesurer la taille, le temps d’ouverture et la complexité opérationnelle avant d’étendre le modèle.