React Native géré par Expo, en solo

React Native nu implique de gérer directement les fichiers de projet natifs iOS et Android — vrai pouvoir, vraie complexité, un lourd fardeau de maintenance pour une personne. Le workflow managé d'Expo abstrait ça : écris du React Native et du TypeScript, Expo gère le pipeline de build natif, fournit des wrappers pré-construits pour la caméra, le push, le système de fichiers et le stockage sécurisé sans code natif, et donne des mises à jour OTA pour les changements JS uniquement sans resoumission au store.

Les notifications push passent par expo-server-sdk côté serveur. L'application s'enregistre au lancement, obtient un jeton de push d'appareil, l'envoie au back-end, qui le stocke dans device_push_tokens clé sur l'utilisateur avec un champ de plateforme et un drapeau is_active. Quand quelque chose doit sortir, le processeur d'outbox récupère l'événement et appelle le SDK avec les jetons stockés.

const messages = tokens.map((token) => ({
  to: token,
  sound: "default",
  title: notification.title,
  body: notification.body,
  data: notification.payload_json,
}));
await expo.sendPushNotificationsAsync(messages);

Les jetons vivent dans leur propre table plutôt qu'un champ sur users parce qu'un utilisateur peut avoir plusieurs appareils actifs — téléphone et tablette, ou une réinstallation qui génère un nouveau jeton pendant que l'ancien est encore enregistré quelque part. is_active laisse l'application envoyer à chaque appareil valide et marquer les périmés inactifs quand Expo signale un jeton comme mort.

Quelques réalités mobiles qui n'existent pas sur le web

• Les cycles de revue des app stores font qu'un changement de binaire natif — un nouveau module, un changement de permission — prend des jours de délai, contrairement à un déploiement web en ligne en quelques minutes. C'est exactement pour ça que les mises à jour OTA comptent : les correctifs JS uniquement sortent instantanément, tout ce qui touche au code natif ne peut pas.
• L'état arrière-plan et premier plan — une application mobile se fait tuer ou perd la connectivité bien plus imprévisiblement qu'un onglet de navigateur, donc les fonctionnalités temps réel ont besoin d'une gestion explicite de reconnexion-au-premier-plan qu'une application web obtient surtout gratuitement.
• Le mode sombre et le RTL doivent être de première classe, pas hérités — le mobile ne peut pas réutiliser le CSS du web comme une mise en page responsive le peut, donc chaque ajustement visuel doit être délibérément reflété dans la couche de style React Native.

La sortie mobile est un pipeline vraiment différent du flux Docker build-push-deploy des applications web — le service de build d'Expo et la soumission au store, rien en commun avec un push d'image Docker — c'est pourquoi c'est un workflow complètement séparé.