Passer au contenu principal
Fugen Services logo

Applications mobiles

Un seul codebase, les deux stores, sans les compromis habituels

Le multiplateforme est la solution par défaut pour la plupart des applications professionnelles : vous ne gérez qu'un seul codebase, vous publiez sur les deux stores, et vous investissez l'économie dans le produit plutôt que dans sa duplication. Le savoir-faire réside dans savoir quelles parties nécessitent encore un traitement spécifique à la plateforme.

Indicatif

À partir de £22,000

Prix fixe convenu par écrit avant le début de la réalisation.

Demander un devis+44 7488 265083

Background photo by Gül Işık on Pexels

Le problème que cela résout

Mal exécuté, le multiplateforme produit une application qui semble étrangère sur les deux plateformes — comportement de retour Android sur iOS, sélecteurs iOS sur Android, et animations saccadées. L'économie disparaît dans les tickets de support et les mauvaises critiques.

Ce que vous obtenez

Recommandation de framework

Flutter ou React Native choisi en fonction de votre jeu de fonctionnalités, des compétences existantes de votre équipe et de vos projets de recrutement — car vous assurerez la maintenance après la livraison.

Interface adaptative à la plateforme

Logique partagée avec navigation, commandes et gestes adaptés à chaque plateforme, pour une expérience native sur chacune d'elles.

Modules natifs si nécessaire

Swift ou Kotlin développé directement pour les fonctionnalités mal couvertes par le framework — pipelines de caméra, géolocalisation en arrière-plan, SDK matériels.

Logique métier et tests partagés

Validation, gestion d'état et traitement des API écrits une seule fois, avec couverture de tests automatisés.

Soumission aux deux stores

Listings App Store et Play Store, conformité et gestion des révisions pour les deux.

Mises à jour en direct (OTA)

Lorsque la politique des stores le permet, mises à jour au niveau JavaScript pour diffuser du contenu et des corrections logiques sans passer par un cycle complet de révision.

Notre méthode de travail

  1. Cadre et choix du framework

    Recommandation écrite avec les compromis exposés, à prix fixe.

  2. Architecture partagée

    Mise en place de la gestion d'état, de la navigation et de la couche API.

  3. Développement

    Cycles de deux semaines avec builds sur les deux plateformes à chaque cycle — jamais l'une puis l'autre.

  4. Tests sur appareils

    Matériel iOS et Android réel couvrant les différentes gammes de performance.

  5. Soumission double

    Préparation et soumission simultanées aux deux stores.

  6. Support

    Trente jours inclus, puis un plan de maintenance commun.

Ce à quoi vous devez vous attendre

  • Une base de code unique pour les deux boutiques
  • Coût généralement inférieur de 30 à 40 % à deux builds natifs
  • Navigation adaptée à chaque système d'exploitation
  • Modules natifs uniquement là où ils sont vraiment nécessaires

Créé avec

  • Flutter
  • Dart
  • React Native
  • TypeScript
  • Expo
  • Riverpod
  • Firebase
  • Swift
  • Kotlin
  • Fastlane

Mainstream, well-supported technology — chosen so you can hire for it and so another team could take the project over.

Applications multiplateformes — your questions

Y compris les questions relatives au coût, que la plupart des agences omettent sur leur site.

Flutter offre un rendu plus cohérent et des performances supérieures pour les interfaces gourmandes en animations, mais Dart dispose d'un vivier de talents plus restreint. React Native permet à une équipe déjà familiarisée avec React de partager ses compétences et une partie du code avec votre application web. Si vous avez des développeurs React, React Native est généralement plus avantageux en termes de coût total de possession ; dans le cas contraire, Flutter est le choix technique le plus sûr.

Pour la grande majorité des applications professionnelles, la différence est imperceptible. Elle devient tangible dans le cas d'applications 3D intensives, de traitement vidéo continu ou d'animations complexes. Si votre application relève de ces cas, nous recommanderons une solution native pour cette partie ou l'ensemble de l'application, plutôt que de faire semblant que cette différence n'existe pas.

Généralement entre 30 et 40 % par rapport à deux builds natifs, avec une économie continue : une seule base de code à maintenir, une seule série de fonctionnalités à synchroniser. Cette économie diminue si votre application nécessite beaucoup de développement natif spécifique à chaque plateforme, ce que nous évaluons lors de l'étude de faisabilité.

En partie. Les deux frameworks permettent de cibler le web, et la logique métier est effectivement réutilisable. Cependant, les interfaces conçues pour le tactile ne se transposent pas bien sur desktop. Nous partageons généralement la logique et la couche API, puis développons une interface web dédiée séparément.

Parlez à quelqu'un qui l'a déjà développé

A short call is usually enough to tell you whether this is the right service for your situation — including when it is not.