Pourquoi j’ai dépublié mon application Android : une décision difficile mais nécessaire
“Créer librement ? Oui, mais parfois ça demande des choix radicaux. Voici pourquoi Android, c’est fini pour ContactHive (pour l’instant).”
##
Une décision difficile mais nécessaire 📱
La semaine passée, j’ai pris une décision qui me pesait mais que j’ai dû considérer comme nécessaire : j’ai dépublié mon application ContactHive du Google Play Store. Elle reste accessible pour ceux qui l’ont déjà installée, mais ne sera plus visible pour les nouveaux utilisateurs. Cette décision n’a pas été facile à prendre, mais après avoir lutté pendant des mois contre le parcours du combattant de l’approbation de chaque nouvelle version sur Google Play (et avec une version chaque semaine en moyenne) et face à un nombre croissant de bugs spécifiques à Android, j’ai dû me rendre à l’évidence. Un dilemme que beaucoup de développeurs solo ou en transition connaissent bien (peut-être toi, qui me lis ?) : quand le multiplateforme devient un frein plutôt qu’un accélérateur. C’est un moment dans les coulisses que je voulais partager avec vous, en toute transparence.
##
Le combat permanent avec Android 🤺
En tant que développeur indépendant, mon quotidien était devenu un véritable parcours du combattant :
- Des délais plus longs à chaque nouvelle version : Google Play met plus de temps à valider les nouvelles versions. Avec une nouvelle release chaque semaine, j’avais deux grands problèmes : les bugs corrigés dans une version tardaient à être disponibles pour les utilisateurs et, lorsque de nouveaux apparaissaient, j’étais déjà passé à la version suivante. De plus, à chaque validation, si un petit détail changeait (par exemple, le passage de mon application de payante à gratuite avec options premium), j’ai accumulé jusqu’à 3 semaines de retard sans que l’application ne soit publiée sur le store. Certes, il y a sans doute une part de responsabilité, n’étant pas parfaitement au fait de toutes les politiques que les développeurs doivent maîtriser pour publier sur un store.
- Une dette technique grandissante : Chaque correction sur iOS nécessitait un travail spécifique sur Android, souvent plus complexe et chronophage. En faisant appel à des fonctionnalités très intégrées aux deux systèmes, l’intégration et l’adaptation à deux environnements différents se complexifiaient de plus en plus.
- Des performances inégales : Malgré tous mes efforts, la version Android souffrait de problèmes de performance que je n’arrivais pas à résoudre complètement. Et oui, j’ai été fan d’Android pendant des années et je trouve qu’ils ont fait un excellent travail au fil des ans, mais gérer un écosystème de plusieurs milliers de périphériques différents (17 815 compatibles avec ContactHive plus exactement à ce jour) ne rend pas le travail d’optimisation facile.
- Un temps de développement doublé : Maintenir deux plateformes en parallèle demande non pas le double de travail, mais souvent bien plus, car certains bugs n’apparaissent que sur une plateforme spécifique. Les identifier en étant au four et au moulin est une tâche bien plus conséquente qu’on ne le pense.
##
L’enfer des changements à chaque version 🔄
Le cauchemar d’un développeur indépendant se matérialise souvent lors des mises à jour. À chaque nouvelle version de mon application, c’était le même scénario frustrant :
- Dépendances divergentes : Une bibliothèque mise à jour pour iOS créait systématiquement des incompatibilités sur Android, nécessitant parfois des solutions totalement différentes pour chaque plateforme.
- Nouveaux bugs spécifiques : Chaque mise à jour apportait son lot de surprises désagréables - une fonctionnalité parfaitement stable sur iOS se mettait soudain à dysfonctionner sur certains appareils Android.
- Tests exponentiels : Là où iOS nécessitait des tests sur 5-6 configurations, Android m’obligeait à vérifier des dizaines de combinaisons différentes (versions d’OS, tailles d’écran, fabricants). Il existe bien une solution sur Firebase pour faire des tests de masse, c’est efficace mais cela ajoute un coût si l’on veut tester une gamme complète.
- Retards en cascade : Un problème détecté tardivement sur Android retardait l’ensemble du déploiement, même si la version iOS était prête et fonctionnelle.
Pour illustrer cette difficulté, voici comment s’est déroulée ma dernière mise à jour :
- Version 0.9.13 sur iOS : développement en 1 semaine, 2 jours de tests, quelques heures de corrections et approbation sans accroc.
- Version 0.9.13 sur Android : Ajoutez 3 jours pour vérifier que tout fonctionne sur mon appareil, 2 jours supplémentaires de corrections car celui-ci ne représente pas la majorité des appareils, puis plusieurs refus par Google Play (1 fois pour un problème de permissions, 2 fois car les règles décrivant l’abonnement n’étaient soudainement plus claires, alors que rien n’avait changé depuis la première validation – je pense même les avoir simplifiées…).
Ce cycle infernal s’intensifiait à chaque itération, transformant chaque mise à jour en source d’anxiété plutôt qu’en moment d’accomplissement. C’est frustrant, et au fil des problèmes en cascade, on est obligé de trouver des solutions. Pourtant ces solutions ne sont-elles pas censées nous aider à réduire le temps et non à nous ajouter une charge ?
##
Le syndrome du développeur solo 🧑💻
Je dois l’admettre, j’ai sous-estimé la charge de travail nécessaire pour maintenir deux plateformes en tant que développeur indépendant. Cette réalisation a été douloureuse, mais salutaire. Et c’est normal : je me suis jeté corps et âme dans un projet ambitieux sans en avoir les acquis nécessaires. Je pense que c’est une expérience à vivre. On a beaucoup à apprendre des erreurs des autres, mais les plus grands apprentissages viennent de nos propres erreurs.
“Parfois, la meilleure façon d’avancer est de reconnaître qu’on ne peut pas être partout à la fois.”
Mon erreur a été de vouloir satisfaire tout le monde dès le départ. Avoir une ambition est louable, mais il faut savoir dimensionner ses projets en fonction de ses capacités réelles, surtout lorsqu’on travaille seul.
##
Identifier ses limites pour mieux avancer 🚀
Cette expérience m’a appris une leçon importante : il est crucial d’identifier ses lacunes et de savoir pivoter avant qu’il ne soit trop tard. En continuant à m’obstiner sur deux plateformes, je risquais :
- De livrer deux applications médiocres plutôt qu’une excellente.
- De m’épuiser mentalement et créativement.
- De retarder d’autres projets potentiellement plus prometteurs.
##
Concentration sur iOS : un choix stratégique 🍏
À partir de maintenant, je me concentre exclusivement sur la version iOS de mon application. Ce n’est pas une décision idéologique mais purement pragmatique :
- Les performances sont nettement meilleures.
- L’écosystème est plus uniforme, facilitant les tests.
- Le processus de validation, bien que strict, est plus cohérent dans le temps.
C’est un constat qui me surprend moi-même, ayant été pendant des années un fervent défenseur d’Android. Mais les faits sont là : pour mon application spécifique, iOS offre actuellement une meilleure expérience et un développement plus fluide.
##
Une note pour mes utilisateurs Android 📝
Si vous êtes l’un des rares utilisateurs ayant acheté mon application sur Android, je tiens sincèrement à m’excuser. Je comprends votre déception et je suis prêt à vous rembourser intégralement - n’hésitez pas à me contacter directement. Votre soutien a été précieux et cette décision ne reflète en rien un manque de considération pour la communauté Android.
##
Et maintenant ? 🌱
Cette décision libère du temps et de l’énergie que je vais pouvoir consacrer à :
- Perfectionner l’application iOS : corriger les bugs existants et développer de nouvelles fonctionnalités.
- Partager mon expérience : pour aider d’autres développeurs indépendants à éviter les mêmes écueils.
- Lancer de nouveaux projets.
##
Leçons apprises 📊
Cette expérience m’a enseigné plusieurs leçons précieuses :
- Le focus est une vertu : Mieux vaut exceller sur une plateforme que d’être médiocre sur plusieurs (même si j’aurai toujours tendance à vouloir tout faire en même temps).
- L’échec n’est pas une fin en soi : C’est une redirection vers une voie plus adaptée.
- L’humilité est nécessaire : Reconnaître ses limites n’est pas un aveu de faiblesse en entrepreneuriat.
- La flexibilité est cruciale : Savoir pivoter rapidement peut sauver un projet, voire une entreprise.
- La compatibilité a un coût : Assurer une expérience uniforme sur des écosystèmes différents est un défi bien plus considérable qu’il n’y paraît. Ceux qui maîtrisent ce point ont un avantage sur un marché du mobile qui est en plein essor depuis des années.
##
Le mythe du développement multiplateforme “facile” 🔍
J’avais initialement choisi un framework promettant le développement “write once, run anywhere” (écrire une fois, exécuter partout). La réalité s’est avérée bien différente selon le type d’application que l’on développe. Même avec les meilleurs outils cross-platform actuels :
- 80% du code était effectivement partagé entre les plateformes.
- Mais les 20% restants représentaient plus de 50% du temps de développement.
Ces 20% concernaient principalement :
- Les interactions avec les API natives spécifiques à chaque plateforme.
- Les ajustements d’interface pour respecter les directives de design propres à iOS et Android.
- La gestion des permissions, qui fonctionne très différemment entre les deux écosystèmes.
- Les optimisations de performance, nécessitant des approches distinctes.
En fin de compte, ce qui semblait être un gain de temps s’est transformé en gouffre chronophage. Une leçon que je garde précieusement pour mes futures décisions technologiques.
##
Un nouveau départ 🚀
Bien que cette décision m’attriste, je la vois comme un nouveau départ pour ContactHive plutôt qu’une fin. Elle me permet de recentrer mes efforts et de me consacrer pleinement à ce que je sais faire de mieux et de pouvoir recommencer un nouveau projet avec de meilleurs acquis.
À bientôt,
Alessandro
📬 Vous souhaitez suivre mon parcours d’entrepreneur et développeur indépendant ? Inscrivez-vous à ma newsletter via le formulaire ici en bas de page.