Apps natives, iOS et Android.

Pourquoi React Native plutôt que du natif Swift / Kotlin

Sur une application mobile métier moderne, environ 90% du code est partageable entre iOS et Android : la logique métier, la navigation, le state management, les appels API, la gestion offline, l'authentification. Tout cela vit dans un codebase unique TypeScript. Concrètement, sur un projet de développement application mobile suisse typique, un développeur React Native couvre les deux plateformes là où une approche native demande deux équipes (Swift côté iOS, Kotlin côté Android), avec une velocity 2 à 3 fois supérieure à scope égal.

L'accès au natif n'est pas sacrifié. Quand un module a besoin de capacités spécifiques (Bluetooth Low Energy, NFC, capteurs ARKit / ARCore, intégrations SDK propriétaires), on écrit un Expo module ou un native module custom en Swift et Kotlin, exposé proprement à la couche JavaScript. La frontière est nette : 95% du code en TypeScript partagé, 5% en natif quand c'est justifié. Pas de compromis sur l'expérience utilisateur perçue.

Le trade-off de performance est documenté et limité. Sur 95% des apps métier (auth, listes, formulaires, dashboards, paiements, notifications), le delta de performance entre RN et natif tourne autour de 5 à 10%, imperceptible pour l'utilisateur final. Les cas où le natif vaut encore mieux : jeux à 60fps avec moteur custom, computer vision lourde (TensorFlow Lite intensif, traitement vidéo temps réel), réalité augmentée AR avancée, animations physiques complexes combinées à des interactions tactiles très fines. En dehors de ces cas, RN est un choix d'ingénierie sain.

L'adoption en 2026 confirme la maturité du framework : Discord, Coinbase, Shopify, Microsoft (Office mobile), Mercari, Bloomberg tournent sur React Native en production, sur des bases utilisateurs de plusieurs dizaines de millions. La New Architecture (Fabric pour le rendu et TurboModules pour les ponts natifs), généralisée à partir de RN 0.74, rapproche encore les performances du natif pur en supprimant le bridge asynchrone historique.

Architecture mobile : navigation, état, offline-first

Notre pattern de référence : React Navigation pour la structure (stack pour les écrans hiérarchiques, tab navigator pour la navigation principale, drawer pour les menus latéraux, modals pour les flows transverses comme un onboarding ou un paiement). Le typage TypeScript des routes garantit qu'aucun écran ne reçoit de paramètres invalides et que les deep links sont cohérents avec l'arborescence.

Pour l'état global, nous utilisons Zustand quand le besoin reste léger (préférences, session, cache local) ou Redux Toolkit quand le projet exige une discipline plus stricte (audit trail, time travel debugging, équipes plus larges). Pour les données asynchrones, TanStack Query gère le fetching, le cache, le retry exponentiel, l'invalidation et les optimistic updates. Cette combinaison couvre la quasi-totalité des cas d'une app métier sans réinventer un store maison.

La persistance locale repose sur AsyncStorage pour les cas simples ou MMKV quand la performance compte (MMKV est environ 10 fois plus rapide qu'AsyncStorage sur les lectures et écritures, basé sur mmap natif). L'offline-first est traité comme un sujet d'architecture, pas comme un patch : queue de mutations persistée, sync différé à la reconnexion, conflict resolution explicite (last-write-wins par défaut, CRDT pour les cas collaboratifs avancés type édition partagée), gestion intelligente de la latence réseau et des reconnexions intermittentes.

Comparé à une approche natif pur — Core Data + URLSession + Combine côté iOS, Room + Retrofit + Coroutines côté Android — React Native consolide tout en TypeScript, sur un seul codebase. Deux stacks à maintenir deviennent une, deux courbes d'apprentissage deviennent une, et les évolutions produit se déploient simultanément sur les deux plateformes. Le coût total de possession sur 3 à 5 ans s'en ressent directement.

Notifications push (APNs et FCM) bien faites

Côté client, nous utilisons Expo Notifications pour les projets sur Expo managed ou react-native-firebase (firebase/messaging) pour les projets bare avec besoins avancés. Les deux exposent les tokens APNs (iOS) et FCM (Android) côté serveur, gèrent les permissions de manière idiomatique, et supportent les rich notifications (image, action buttons, replies inline) sur les deux OS. Le silent push permet de déclencher des updates en arrière-plan sans notification visible — utile pour rafraîchir des données critiques.

Côté backend, l'envoi passe par FCM HTTP v1 ou APNs token-based authentication (plus simple à opérer que les certificats P12 historiques). Nous segmentons les utilisateurs par profil, fuseau horaire, langue et opt-in, et nous envoyons conditionnellement plutôt que par broadcast. Le deep linking est branché systématiquement : un tap sur une notif ouvre la vue exacte concernée (commande, message, alerte), pas l'écran d'accueil générique.

L'opt-in UX est traité avec soin. Le prompt système au lancement de l'app conduit à environ 95% de refus. Nous prompt-onons après une action utilisateur qui justifie naturellement les notifications (premier achat, premier message, premier favori), avec un écran intermédiaire qui explique la valeur. Le taux d'acceptation passe alors typiquement de 5% à 40-60% selon le contexte produit.

In-app payments : App Store, Play Store et Stripe

Les règles Apple sont strictes : toute transaction de bien digital consommé dans l'app (abonnement, crédits in-app, contenu payant déverrouillable) doit passer par In-App Purchase. La commission est de 15% pour les revenus inférieurs à 1M USD/an (Small Business Program) et de 30% au-delà. Google Play applique un régime similaire. Les exceptions existent : services physiques (livraison de repas, transport, réservations), achats consommés hors app (cours, événements physiques), facturation B2B SaaS — tous peuvent passer par un autre PSP.

Implémentation côté code : expo-in-app-purchases ou react-native-iap (plus complet pour les bare workflows, abonnements promotionnels, family sharing). Pour les paiements hors store, Stripe gère le paiement web (typiquement via un browser in-app ou un redirect) puis l'activation in-app via deep link sécurisé. Twint est branché en parallèle quand l'app cible le grand public suisse, via la passerelle Stripe + SIX.

La validation server-side des receipts est obligatoire, jamais optionnelle. App Store Server API et Google Play Developer API permettent de vérifier qu'un receipt est authentique, non révoqué, et bien rattaché à l'utilisateur. Sans cette étape, l'app est trivialement piratable (jailbreak iOS, modded APKs Android). Notre implémentation systématise la validation et la persistance des entitlements côté backend.

Géolocalisation, cartes et tâches en arrière-plan

Pour les cartes, nous utilisons react-native-maps qui s'appuie sur Google Maps natif (Android) et Apple Maps ou Google Maps (iOS), avec un fallback MapLibre quand le client veut éviter les coûts d'API Google ou Apple. Mapbox commercial reste pertinent pour les cas qui demandent du styling très poussé, du 3D ou des données vectorielles custom. Le choix se fait en discovery selon le volume d'usage projeté et le budget tile API.

La géolocalisation passe par expo-location avec une gestion fine des permissions : iOS distingue When in Use (app au premier plan) et Always (background tracking, demande explicite renforcée), Android sépare ACCESS_FINE_LOCATION et ACCESS_COARSE_LOCATION. Nous expliquons toujours pourquoi la permission est demandée, avec un texte de purpose string clair — ce point est aussi un critère de revue stores.

Les tâches en arrière-plan reposent sur Expo TaskManager pour les cas comme un tracking de course de livraison ou un check de geofencing. Le coût batterie est réel et nous l'exposons honnêtement : un background tracking permanent peut consommer 5 à 15% de batterie/heure selon la fréquence GPS. Nous l'utilisons parcimonieusement, avec des stratégies adaptatives (réduction de la précision quand l'utilisateur est immobile). Le geofencing déclenche des notifications contextuelles (entrée ou sortie d'une zone) sans tracking continu. Côté conformité RGPD et nLPD : opt-in explicite, retention courte des positions, anonymisation après usage.

Soumission stores : éviter les rejets

Checklist Apple : Privacy Manifests v2 obligatoires depuis mai 2024 (déclaration des SDK tiers et de leurs accès aux required reason APIs), App Tracking Transparency si l'app track l'utilisateur cross-app, Sign in with Apple obligatoire si d'autres SSO sont proposés (Google, Facebook), IAP propre pour tout bien digital, métadonnées exactes (titre, sous-titre, description), screenshots aux bonnes tailles pour iPhone 6.7", 6.5", 5.5" et iPad si compatible. Les rejets viennent à 80% de ces points oubliés.

Checklist Google Play : target API à jour annuellement (target API 35 obligatoire en août 2025, target API 36 en août 2026, sous peine de gel des updates de l'app), permissions justifiées dans le manifest avec fichier de déclaration sensitive permissions si concerné, data safety form rempli avec exactitude (collecte, partage, sécurité), Play Integrity API branchée pour vérifier l'intégrité du device et bloquer les builds modifiés.

Notre process : binaire prêt en semaine 8-12 du projet, comptes Apple Developer et Google Play déjà configurés en amont avec le client (Apple : 99 USD/an, environ 200 CHF avec les frais de change ; Google Play : 25 USD one-time). Soumission en semaine 12, validation moyenne 1 à 3 jours côté Apple, 1 à 3 heures côté Google. Plan B en cas de rejet : itération rapide, souvent dans les 24 heures, avec re-soumission. Les rejets pour des points listés au-dessus sont quasi systématiquement résolvables sans refonte structurelle.

Les certificats et profiles de provisioning sont gérés via EAS Build pour éviter les pièges historiques d'Xcode (manual signing, certificats expirés, profiles orphelins). Le pipeline est reproductible, les builds sont signés automatiquement, les rotations de certificats deviennent un non-événement.

Maintenance long terme : OS updates et dette technique

iOS et Android imposent des migrations annuelles non négociables. Côté iOS, Apple sort une nouvelle version majeure chaque septembre (iOS 18 en 2024, iOS 19 en 2025, iOS 20 en 2026), avec un calendrier de deprecated APIs visible 6 à 12 mois à l'avance. Côté Android, Google Play impose un target SDK minimum un an après la release : target API 35 obligatoire en août 2025, target API 36 en août 2026. Une app non maintenue pendant 2 ans devient invendable au store : les updates sont gelées, et le binaire historique devient inéligible aux nouveaux devices.

Le coût d'une TMA mobile typique se situe entre 800 et 3000 CHF/mois selon le scope : monitoring crash-free rate via Sentry, mises à jour OS trimestrielles, bumps de dépendances (RN, Expo SDK, libs critiques), évolutions mineures (textes, écrans, petits flows), re-soumission stores quand requis. Nous documentons explicitement ce qui est inclus et ce qui ne l'est pas, pour éviter les zones grises classiques des contrats forfaitaires.

Le stack moderne (Expo SDK + React Native + Hermes) facilite drastiquement la maintenance. EAS Update permet de pousser des bug fixes JavaScript en OTA, sans repasser par une review store : un patch critique est en prod chez les utilisateurs en quelques minutes, pas 1 à 3 jours. Hermes, le moteur JavaScript optimisé pour RN, remplace JavaScriptCore historique : démarrage plus rapide, consommation mémoire réduite, meilleure performance sur les apps lourdes. Cette stack rend une app maintenable à long terme par une équipe restreinte.

Quand choisir une agence vs un studio dev

Les agences suisses spécialisées mobile ont leurs forces : équipes pluridisciplinaires, doubles équipes iOS et Android natif, designers UX et UI dédiés, QA spécialisé mobile, capacité à porter des projets B2C grand public à très large échelle. Pour un projet stratégique avec besoin de mobilisation simultanée de 5 à 10 personnes pendant plusieurs mois, ce format reste pertinent.

Un studio dev comme fastdigital a un format différent. Équipe restreinte (1 à 2 développeurs full-stack mobile + backend), stack moderne (Expo + RN 0.74+ avec New Architecture + Hermes) qui partage 90% du code entre iOS et Android, décisions techniques rapides, livraisons fréquentes. Pour un MVP de startup, une app compagnon de SaaS, ou une refonte mobile sous contrainte budgétaire, le format est souvent mieux adapté au besoin réel.

Pour un projet mobile à l'échelle d'une grande entreprise (gros comités, gouvernance complexe, exigences compliance lourdes type FINMA, équipes internes nombreuses à coordonner), une agence avec son organisation reste pertinente. Pour tout le reste — la majorité des projets mobile B2B, B2C de PME, MVP startup — un studio dev avec RN+Expo livre le même résultat technique en moins de temps et à un coût plus accessible.

Le résultat technique est équivalent côté livrable : crash-free rate au-dessus de 99.5%, 60fps sur les écrans critiques, sécurité conforme OWASP MASVS niveau 1+ minimum (jailbreak detection, certificate pinning quand pertinent, secure storage des tokens). Format différent, coût plus accessible, qualité comparable.

FAQ technique