Développement d'applications mobiles, de la fiche store à la sixième version
iOS et Android depuis une seule base de code, validation des stores comprise, et maintenues après le lancement.
Nous avons publié des applications grand public qui fonctionnent hors ligne, ne stockent rien sur un serveur sans nécessité, et passent la validation sans bataille. Ce dernier point est un savoir-faire : la plupart des premiers refus sont évitables, et chaque aller-retour coûte une semaine.
Comment nous choisissons la technologie
- React Native par défaut. Une base de code pour les deux stores, des modules natifs là où une fonctionnalité l'exige vraiment, et une équipe capable de maintenir l'ensemble sans deux recrutements séparés.
- Du natif complet quand l'application repose sur quelque chose de propre à la plateforme : graphismes lourds, traitement en arrière-plan, intégration matérielle sans passerelle.
- Une application web quand rien n'impose de passer par un store, ce qui arrive plus souvent que le brief ne l'admet. Nous vous dirons quand la PWA est la réponse honnête.
Ce que nous intégrons dès le départ
- Des données locales d'abord, pour que l'application fonctionne dans un train et se synchronise ensuite, au lieu d'afficher une roue qui tourne sur un réseau mort.
- Un compte utilisateur seulement si le produit en a besoin. Chaque écran d'inscription entre une personne et la valeur vous en fait perdre la majorité.
- Le travail de fiche store : captures, description, mots-clés, réponses sur la confidentialité. La fiche est l'étape de conversion que tout le monde oublie après douze semaines de construction.
- La tuyauterie de publication dès le début : signature, mises à jour à distance quand elles sont permises, remontée de plantages qui nomme la ligne et pas l'écran.
Ce que cela coûte
- 8-14 semaines jusqu'à une première version sur les deux stores
- 2 cycles de validation à prévoir, réalistement
- 15-20% du coût de construction par an pour rester compatible
Ce qui coûte cher dans une application, ce n'est pas de la publier. C'est qu'elle soit encore installée un an plus tard.
Questions fréquentes
Faut-il iOS et Android dès le lancement ?
Seulement si votre audience est réellement partagée. Publier sur un seul store d'abord réduit de moitié la surface de la première version et fait remonter de vrais retours des semaines plus tôt ; avec une base de code partagée, le second store représente ensuite une fraction du travail et non un second projet. Regardez où sont déjà vos clients avant de trancher.
Qui possède les comptes développeur ?
Vous, toujours, au nom de votre société. Une application publiée sous le compte d'une agence est une application que vous ne pouvez ni déplacer, ni mettre à jour, ni transférer sans sa coopération. Nous sommes invités sur vos comptes, pas l'inverse, et c'est inscrit au contrat.
Et les refus des stores ?
Nous concevons autour des règles qui en causent la majorité : suppression de compte, information sur les abonnements, justification des permissions, et tout ce qui ressemble à un site web dans une coquille. Des refus arrivent quand même ; la différence est qu'ils se règlent en une journée au lieu d'imposer une refonte.