Choisissez une PWA quand la portée et la vitesse d'itération comptent plus que l'intégration profonde au téléphone : elle s'installe depuis un lien, se met à jour au déploiement et réutilise votre stack web. Choisissez React Native avec Expo quand la présence sur les stores, le push fiable sur iOS ou les APIs matérielles sont non négociables. En 2026, le choix par défaut raisonnable pour beaucoup de produits : PWA d'abord, React Native quand le store devient important. Les deux peuvent, et doivent, partager la même API backend.
Que comparez-vous exactement ?
Une PWA est une application web dotée d'un manifest et d'un service worker : installable, capable de fonctionner hors ligne, distribuée par URL et mise à jour à chaque chargement. Une application React Native est une vraie application native pilotée en JavaScript : elle passe par l'App Store et Google Play et accède aux capacités natives via des modules.
Cette définition tranche déjà une partie du débat. Une PWA (web.dev consacre une collection complète au sujet) est votre site web, en mieux : rien à installer pour l'utilisateur, sauf s'il le souhaite. React Native rend de vraies vues natives depuis JavaScript, et depuis que sa New Architecture est devenue le défaut fin 2024, les goulots d'étranglement de l'ancien bridge ont largement disparu. Le développement natif complet en Swift ou Kotlin constitue une troisième catégorie : légitime pour la 3D lourde ou l'intégration profonde à l'OS, hors de notre périmètre (notre pratique couvre les applications React Native et Expo, les PWA et les backends qui les servent), et inutile pour la plupart des applications produit.
La présence sur les stores et la friction d'installation comptent-elles ?
La question du store tranche plus de projets que n'importe quel critère purement technique. Si vos utilisateurs s'attendent à vous trouver en cherchant sur l'App Store, veulent une icône installée par défaut et lisent les avis, React Native justifie son coût. S'ils arrivent par un lien, un e-mail ou un QR code, une PWA supprime tout le tunnel d'installation.
La friction est asymétrique. Ouvrir une URL prend un geste. Une installation depuis un store demande une recherche, un téléchargement, parfois une connexion, et chaque étape supplémentaire fait perdre des utilisateurs. Sur Android, une PWA peut même être publiée sur Google Play sous forme de Trusted Web Activity. Apple n'offre aucun équivalent : ses règles de validation sur la fonctionnalité minimale écartent les simples encapsulations web, donc une présence sur l'App Store implique une application réellement native, exactement le terrain de React Native.
Vous hésitez entre PWA et React Native ? Décrivez votre application : diagnostic d'une page sous 48 h.
Recevoir mon diagnostic →Une PWA peut-elle envoyer des notifications push en 2026 ?
Oui sur Android et desktop ; oui sous conditions sur iOS. Depuis iOS 16.4 (mars 2023), Safari prend en charge le Web Push, mais uniquement pour les applications web ajoutées à l'écran d'accueil, et seulement après une demande de permission déclenchée par un geste de l'utilisateur. Si le push iOS porte votre rétention, React Native reste la voie fiable.
Les limites pratiques pèsent plus que l'annonce. iOS ne propose jamais d'installer une PWA : l'utilisateur doit trouver Partager, puis Sur l'écran d'accueil, une étape que peu de gens franchissent spontanément. La fiabilité de livraison a progressé depuis 2023, mais la prise en charge varie encore selon le navigateur et la version : testez sur les appareils que votre audience possède réellement avant d'y adosser votre rétention. La référence Push API de MDN suit l'état du support. Sur Android, Chrome gère le Web Push et les invites d'installation depuis des années.
Hors ligne, arrière-plan, APIs matérielles : où passe la frontière ?
Les deux gèrent bien le hors-ligne de base. Un service worker met en cache les assets et les réponses d'API ; une application React Native persiste ses données dans SQLite ou un stockage clé-valeur. L'écart se creuse sur l'exécution en arrière-plan et le matériel : synchronisation en arrière-plan, géolocalisation continue et Bluetooth restent limités ou absents dans les navigateurs, surtout dans Safari sur iOS.
Début 2026, Safari n'embarque toujours ni Background Sync ni Web Bluetooth : traitez donc toute exigence forte d'arrière-plan ou de matériel comme un signal en faveur de React Native. Côté React Native, l'écosystème de modules Expo couvre caméra, biométrie, stockage sécurisé et la plupart des capteurs sans écrire de code natif. Pour de la simple lecture hors ligne et une file de requêtes, un petit service worker suffit largement :
// sw.js : cache d'abord pour les assets statiques, réseau d'abord pour l'API
self.addEventListener('fetch', (event) => {
const url = new URL(event.request.url);
if (url.pathname.startsWith('/api/')) return; // l'API reste sur le réseau
event.respondWith(
caches.match(event.request).then((hit) => hit || fetch(event.request))
);
});
Comment vos mises à jour atteignent-elles les utilisateurs ?
Une PWA se met à jour au chargement suivant : déployé, terminé. Une application React Native construite avec Expo livre ses changements JavaScript en OTA (over the air) avec EAS Update, dans les limites des règles des stores, et ne repasse en validation que pour les changements natifs. Cette différence se cumule sur une année d'itérations hebdomadaires.
EAS Update d'Expo pousse de nouveaux bundles JavaScript directement vers les applications installées, en réservant la validation aux rares changements natifs. En 2026, une validation aboutit généralement en un à deux jours, mais rien n'est garanti et les rejets existent : ne placez jamais un correctif urgent derrière ce guichet. Une PWA n'a aucun portier : corrigez, déployez, le prochain chargement est à jour.
PWA ou React Native : le comparatif critère par critère
Aucun critère ne l'emporte seul ; c'est le motif d'ensemble qui compte. Lisez le tableau en entourant ce qui est non négociable pour votre produit. Une seule exigence dure dans la colonne de droite (présence sur les stores, push iOS, accès matériel) suffit à justifier React Native. Aucune : la PWA gagne sur le coût et la vitesse.
| Critère | PWA | React Native (Expo) |
|---|---|---|
| Présence sur les stores | Google Play via Trusted Web Activity ; pas d'App Store | App Store et Google Play |
| Friction d'installation | Aucune : on ouvre une URL, l'installation est optionnelle | Recherche sur le store, téléchargement, permissions |
| Notifications push | Complètes sur Android et desktop ; iOS depuis 16.4, PWA installées uniquement | Complètes sur les deux plateformes (APNs, FCM) |
| Hors ligne | Bon niveau, via le cache du service worker | Bon niveau, via stockage local ou SQLite |
| Tâches en arrière-plan | Limitées ; au plus bas dans Safari | Étendues, via les modules natifs |
| APIs matérielles | Un sous-ensemble, variable selon le navigateur | Quasi complètes via l'écosystème de modules |
| Modèle de mise à jour | Instantanée au déploiement | OTA pour le JavaScript (EAS Update) ; validation pour le natif |
| Base de code | Votre stack web existante | Une base JS/TS pour les deux plateformes |
Quand la bonne réponse est-elle les deux ?
Souvent, et ce n'est pas un compromis. Livrez la PWA d'abord : elle valide le produit auprès de vrais utilisateurs à la vitesse du web, sans friction d'installation. Ajoutez une application React Native quand le store devient important : push iOS pour la rétention, fonctions matérielles, ou clients qui demandent où télécharger l'application. La PWA continue de servir tous les autres.
Ce séquencement protège aussi le budget : la version web est rarement du travail perdu, parce que le site, le tableau de bord et l'application peuvent partager un même design system et une même API. Quand l'étape store arrive, notre travail de développement mobile part de ce contrat existant plutôt que d'une page blanche.
Et pour votre backend, qu'est-ce que ça change ?
Une seule API sert les deux clients, à condition de la concevoir indépendante du client dès le premier jour. Cela signifie une authentification par jetons plutôt que des sessions à cookies seuls, un service de push qui stocke les abonnements Web Push à côté des tokens d'appareils, et des contrats versionnés pour qu'une application installée l'an dernier ne casse jamais. Le passage de PWA à application de store devient alors un ajout, pas une réécriture.
// Un seul endpoint d'abonnement pour les deux clients
const reg = await navigator.serviceWorker.ready;
if ('pushManager' in reg) {
const sub = await reg.pushManager.subscribe({
userVisibleOnly: true,
applicationServerKey: VAPID_PUBLIC_KEY,
});
// Le même endpoint stocke aussi les tokens d'appareils natifs
await fetch('/api/push/subscriptions', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(sub),
});
}
Réussir ce contrat relève plus du travail d'API que du mobile, et c'est là que l'approche PWA d'abord paie deux fois : le même effort de développement d'API sert l'application web aujourd'hui et l'application de store demain.
Check-list de décision
Passez votre produit au crible avant d'écrire la moindre ligne :
- Vos utilisateurs arrivent par lien, e-mail ou QR code : commencez par la PWA.
- La rétention repose sur les notifications push iOS : React Native.
- Bluetooth, géolocalisation en arrière-plan ou usage matériel intensif : React Native.
- Vous livrez des correctifs chaque semaine ou plus vite : PWA, ou React Native avec EAS Update.
- La crédibilité du store compte pour vos acheteurs : React Native (ou une Trusted Web Activity, Android uniquement).
- Toujours indécis : construisez la PWA, gardez l'API indépendante du client, réévaluez dans deux trimestres.