Lun-Sam 9h00-19h00
07 44 90 44 53
Applications mobiles : illustration
Développement

Natives en SwiftUI et Kotlin ou multiplateformes avec Flutter et React Native : nous concevons des applications mobiles fiables, de la maquette à la publication sur les boutiques.

Le bon choix technique dès le départ

Sur mobile, les décisions prises au début engagent le projet pour des années : choix entre natif et multiplateforme, gestion des données hors connexion, stratégie de notifications, modèle économique dans les boutiques. Nous les abordons franchement lors du cadrage, à partir de vos usages réels. Une application de terrain utilisée dans des sous-sols sans réseau n’a pas les mêmes besoins qu’une application grand public qui doit convaincre en quelques secondes sur sa fiche de l’App Store.

Nous connaissons ces contraintes de l’intérieur, puisque nous éditons notre propre application iOS. Revue des boutiques, abonnements intégrés, demandes d’autorisation (localisation, caméra, notifications), compatibilité avec les anciennes versions du système : ces sujets sont anticipés dans le planning plutôt que découverts la veille du lancement. Côté serveur, nous construisons aussi l’API et l’espace d’administration dont l’application a besoin, pour que vos équipes puissent gérer les contenus sans publier de nouvelle version.

Notre périmètre mobile

Tout ce qu’il faut pour qu’une application vive au-delà de sa première version.

  • Applications natives iOS et Android
  • Applications multiplateformes
  • Synchronisation et mode hors connexion
  • Notifications push ciblées
  • Abonnements et achats intégrés
  • Publication et suivi des versions
  • API et back-office associés

Natif ou multiplateforme ?

Les deux approches sont solides ; le bon choix dépend de vos priorités et de vos ressources.

CritèreNatif (SwiftUI, Kotlin)Multiplateforme (Flutter, React Native)
Base de codeUne par systèmeUne seule, partagée entre iOS et Android
Accès aux nouveautés du systèmeImmédiat, dès leur sortieVia des modules, parfois avec délai
Fluidité et renduRendu natif, au plus près du systèmeTrès bons pour la plupart des usages
Effort de développementPlus important si deux plateformesGénéralement plus contenu
Compétences mobiliséesSwift et KotlinDart ou TypeScript
Cas idéalProduit phare, usage intensif du matérielOutil métier, budget ou calendrier serrés

De la maquette aux boutiques

La publication fait partie du projet : elle se prépare dès les premières semaines.

  1. Étape 01
    Prototype cliquable

    Les écrans clés sont testés sur téléphone avant toute ligne de code, pour valider la navigation, les gestes et le moment où l’application demande ses autorisations.

  2. Étape 02
    Versions de test

    Chaque sprint produit une version installable via TestFlight sur iPhone et les tests internes de Google Play, distribuée à vos testeurs pour recueillir leurs retours sur de vrais appareils.

  3. Étape 03
    Préparation des fiches

    Captures d’écran, description, mots-clés, classification par âge, déclarations de confidentialité exigées par Apple et Google : nous préparons l’ensemble avec vous pour limiter les risques de refus.

  4. Étape 04
    Soumission et revue

    Nous soumettons l’application, répondons aux éventuelles remarques des équipes de revue et planifions une diffusion progressive, afin d’observer les premiers retours avant de l’étendre à tous les utilisateurs.

  5. Étape 05
    Suivi après lancement

    Rapports de plantage, avis des utilisateurs et nouvelles versions d’iOS et d’Android sont suivis dans la durée, pour maintenir la compatibilité de l’application et planifier ses évolutions.

MyClermont, notre propre application

Nous développons et éditons MyClermont, une application iOS native en SwiftUI dédiée à Clermont-Ferrand : carte MapKit des lieux, stories dans l’onglet Explorer, rubrique Ma Ville et assistant IA local « Clermont IA ». Sa sortie sur iPhone est prévue le 15 novembre 2026, avant une version Android. Ce projet nous confronte aux mêmes exigences que vos applications : revue d’Apple, abonnement intégré avec My Clermont+, performance et respect de la vie privée.

Vos questions sur le développement mobile

Oui, si c’est prévu dès la conception. Les données utiles sont stockées sur le téléphone (SwiftData, Core Data ou Room), les saisies sont mises en file d’attente puis synchronisées au retour du réseau, avec des règles claires en cas de conflit entre deux modifications. C’est un choix d’architecture qui se décide au cadrage, pas une option ajoutée à la fin.
Vous. Nous recommandons d’ouvrir les comptes développeur Apple et Google au nom de votre organisation, puis de nous y inviter comme membres. Vous gardez ainsi la maîtrise de la fiche, des avis, des revenus et des clés de signature, quelle que soit la suite de notre collaboration.
Apple et Google publient chaque année une version majeure de leur système et relèvent régulièrement les versions minimales exigées pour publier. Dans le cadre de la maintenance, nous testons l’application sur les versions bêta, adaptons le code et préparons une mise à jour pour anticiper les incompatibilités.

Votre application mobile mérite un cadrage solide

Natif ou multiplateforme, hors connexion ou non : parlons de vos usages avant toute décision technique, à l’occasion d’un premier rendez-vous offert.