Développement d'applications mobiles multiplateformes

Nous développons des applications iOS et Android à partir d’une seule base de code React Native : une équipe, un backend, des publications simultanées sur les deux stores. Si votre produit a intérêt à être natif, nous vous le disons avant l’estimation.

Quand une seule base de code est la bonne réponse

Le développement multiplateforme fonctionne quand l’application repose sur du contenu et des requêtes vers un serveur. Il fonctionne mal quand le produit vit de graphismes lourds, de traitements permanents en arrière-plan ou des toutes dernières fonctionnalités des plateformes.

Il vous faut un MVP sur iOS et Android et vous voulez tester le marché avant de financer deux applications natives
L'application s'articule autour de fils d'actualité, de catalogues, de formulaires, de réservations, de profils et de messagerie
Les nouvelles fonctionnalités doivent arriver le même jour chez les utilisateurs d'iPhone et d'Android
Le budget couvre une équipe de développement, pas deux
Votre plateforme web a besoin d'une application compagnon avec les mêmes comptes et les mêmes données
Vous avez une application React Native développée par une autre équipe, à terminer ou à remettre à niveau

Ce qui est inclus

Évaluation de la plateforme

Avant l’estimation, nous passons en revue les fonctionnalités et vous disons si React Native convient. Si une partie critique exige du code natif, nous vous montrons où elle se trouve et quelle part de l’application elle concerne.

Design pour les deux plateformes

Un seul design adapté aux conventions d’iOS et d’Android : navigation, gestes, boîtes de dialogue système, bouton retour. Pas un design d’iPhone étiré sur Android.

Développement React Native

Code partagé pour les écrans, la logique métier et les requêtes au serveur. Le travail avance par sprints, et chacun se termine par une version pour les deux plateformes que vous pouvez installer et essayer.

Modules natifs

Là où le code partagé ne suffit pas, par exemple pour le SDK d’un fournisseur, une fonction matérielle ou un traitement en arrière-plan, nous écrivons des modules natifs en Swift et en Kotlin et les connectons à l’application.

Un seul backend pour les deux applications

API, base de données, back-office et notifications push développés une fois et utilisés par les deux applications, et par une version web si besoin. Python ou PHP (Laravel), selon la tâche.

QA, publication et mises à jour

Tests sur de vrais iPhone et téléphones Android, publication sur l’App Store et Google Play, et mises à jour après le lancement, y compris les montées de version de React Native et de ses bibliothèques.

Où le multiplateforme fonctionne, et où il ne fonctionne pas

Une seule base de code pour iOS et Android coûte généralement nettement moins cher que deux applications natives et prend moins de temps, car l’essentiel du code, du design et des tests est partagé. Ce compromis fonctionne quand l’application affiche du contenu, des listes et des formulaires et dialogue avec un serveur. Il fonctionne mal quand le produit dépend d’interfaces très animées, de fonctionnalités centrées sur l’appareil photo, de longs traitements en arrière-plan ou d’API de plateforme qui arrivent d’abord dans les SDK natifs. Nous vous disons dans quel cas se trouve votre produit avant l’estimation, pas après la première version.

Bien adapté : applications de contenu, catalogues, marketplaces, applications de réservation et de services
Bien adapté : MVP qui doivent être sur les deux stores dès le premier jour
Mieux en natif : graphismes et animations lourds, fonctionnalités centrées sur l'appareil photo
Mieux en natif : traitements permanents en arrière-plan et API de plateforme les plus récentes

Une équipe, un backend, un calendrier de publication

Avec deux applications natives, vous gérez deux bases de code, deux séries de bugs et souvent deux dates de publication. Avec React Native, une fonctionnalité est écrite une fois et part en même temps sur les deux stores, et les mêmes personnes répondent des deux plateformes. La partie serveur est elle aussi partagée : une API et un back-office servent les deux applications et, si besoin, un client web. Metacognit.me, une application de correction métacognitive et de diagnostic du psychotype, est construite exactement ainsi : un client React Native pour iOS et Android et un backend en Python.

Prêt pour un passage au natif, si le jour vient

Commencer en multiplateforme ne vous enferme pas. Le backend et l’API survivent à un passage au natif ; le code client, non. C’est pourquoi nous concevons l’API pour qu’un futur client natif ou web puisse l’utiliser tel quel, et isolons les parties propres à chaque plateforme dans des modules natifs. Nous avons réalisé des migrations dans les deux sens. Pour Quaker, une application de cuisine destinée à une société de livraison de repas à Dubaï, nous avons remplacé une application hybride sur une technologie dépassée par deux clients natifs, dès que les différences entre plateformes ont commencé à compter pour le produit.

Une API conçue pour servir n'importe quel futur client, natif ou web
Code propre à chaque plateforme isolé dans des modules natifs
Un signal honnête quand l'application dépasse les limites de la base de code partagée
Des comptes et des données qui suivent le produit, quel que soit le langage du client

Déroulement d'un projet multiplateforme

Évaluation et estimation

Nous passons en revue les fonctionnalités et les intégrations et vérifions ce qui exige du code natif. Vous recevez un périmètre écrit, une recommandation React Native ou natif et une estimation.

Design

Prototype et interface finale adaptés aux deux plateformes. Vous validez les écrans iOS et Android avant le développement.

Développement

D’abord le code partagé, des modules natifs là où c’est nécessaire, le backend en parallèle. Après chaque sprint, vous installez de nouvelles versions sur les deux plateformes.

Tests sur appareils

QA sur de vrais iPhone et téléphones Android, avec différents écrans et versions d’OS. Vous recevez une version testée pour les deux stores.

Publication et support

Publication sur l’App Store et Google Play sous vos comptes, puis mises à jour, corrections et montées de version du framework aussi longtemps que nécessaire.

Technologies

Multiplateforme

Modules natifs

Backend et API

Nos formules de collaboration

Périmètre fixe

Liste de fonctionnalités, estimation et calendrier validés pour les deux plateformes. Un choix courant pour un MVP qui doit sortir sur les deux stores.

Équipe dédiée

Une équipe multiplateforme qui travaille en continu sur votre application. Convient aux produits qui publient souvent et planifient leur feuille de route sprint après sprint.

À l'heure

Paiement des heures réellement passées. Convient aux audits d’une application React Native existante, aux montées de version du framework et aux petites fonctionnalités.

Projets associés

Metacognit.mePython, React.Native QuakerKotlin, SWIFT, PHP, Laravel

Témoignages

Nous traitons chaque client et son projet avec attention.

L’équipe Revol continue de renforcer les capacités de développement du client grâce à un travail de grande qualité et à un support fiable. Elle communique efficacement et fait preuve d’une solide compréhension des besoins et de l’activité du client.

Tomas

PDG (Yukon, Canada)

Le travail de Revol a pleinement répondu aux attentes et a satisfait le client. Leur approche nouvelle et leur disponibilité pour le support ont été de vrais atouts. On peut faire appel à eux pour disposer d’une équipe communicative et orientée client, qui aide à atteindre ses objectifs.

Andrey

PDG, Stellium (États-Unis)

Questions fréquentes

Les utilisateurs verront-ils que l'application n'est pas native ?

Dans les cas où le multiplateforme est adapté, non. Là où ils le verraient, comme les interfaces très animées, les fonctionnalités centrées sur l'appareil photo ou les longs traitements en arrière-plan, nous recommandons le développement natif au lieu de promettre que le code partagé suivra.

Combien le multiplateforme coûte-t-il de moins que deux applications natives ?

En général, nettement moins cher et plus rapide, car l'essentiel du code, du design et des tests est partagé. L'écart exact dépend du nombre de fonctionnalités propres à chaque plateforme. Nous donnons des chiffres concrets dans l'estimation de votre application plutôt qu'un pourcentage général.

Peut-on commencer en multiplateforme et passer au natif plus tard ?

Oui, et nous avons réalisé cette migration dans les deux sens. Mieux vaut l'anticiper tôt, car le backend et l'API survivent au changement, contrairement au code client.

Publiez-vous les applications sur les stores ?

Oui. Nous préparons les builds, les fiches et les métadonnées, passons la validation de l'App Store et de Google Play et apportons les corrections demandées. Les applications sont publiées sous vos propres comptes développeur.

Comment le prix est-il calculé ?

Nous découpons l'application en fonctionnalités, estimons chacune en heures et ajoutons le design, le backend, la QA et la publication. Vous choisissez ensuite un périmètre fixe, une équipe dédiée ou un travail à l'heure. Les tarifs ne sont pas publiés, car l'effort varie trop d'une application à l'autre.

Pouvez-vous reprendre une application React Native existante ?

En général, oui. Nous commençons par une revue du code : versions de React Native et des bibliothèques, modules natifs, processus de build. Vous obtenez une image claire de l'état de l'application et de ce que représenteront les premiers mois, y compris la nécessité éventuelle d'une montée de version ou d'une réécriture partielle.