Faut-il mettre à jour votre app à chaque nouvel iOS ?

Vous la connaissez, cette petite gêne. La keynote fait les titres, votre téléphone se met à jour tout seul pendant la nuit, et au réveil, une pensée : et mon app, dans tout ça ? Est-ce qu'elle marche encore ? Est-ce que j'aurais dû préparer quelque chose ?

L'instinct n'est pas mauvais. Quelque chose change bel et bien : votre app repose sur des centaines de fonctions fournies par le système — afficher une carte, envoyer une notification, demander une permission — et c'est ce socle, précisément, qui vient de bouger. La question n'est donc pas « est-ce qu'il se passe quelque chose ? » — il se passe quelque chose. La question est : qui doit s'en occuper ?

Deux mouvements, presque toujours.

Des fonctions s'arrêtent. Pas avec fracas : une fonction que votre app utilisait cesse simplement d'être disponible, et ce qui s'appuyait dessus ne répond plus. Rien ne « plante » à l'écran ; quelque chose ne se produit plus, voilà tout. C'est la panne la plus sournoise qui soit, parce qu'elle ne laisse aucune trace visible.

D'autres deviennent obligatoires. Le système introduit une nouvelle façon de faire — plus sûre, plus respectueuse de la vie privée — et la rend progressivement incontournable. Pas du jour au lendemain : une échéance est posée, parfois à plusieurs mois, et elle finit toujours par tomber.

Le point qui rassure et inquiète à la fois : ces mouvements sont, pour la plupart, annoncés à l'avance. Apple et Google publient ce qui va s'arrêter et ce qui va devenir obligatoire bien avant que ce soit effectif. Tout est donc lisible — à condition que quelqu'un lise. Et le rythme ne s'arrête jamais : deux systèmes, une version majeure chacun par an, des ajustements entre les deux.

C'est ici que le fait d'être sur une plateforme change la nature du problème.

Ces annonces, quelqu'un les lit — avant qu'elles prennent effet, parce que c'est son métier. Quand une fonction est en sursis, le composant qui l'utilise est réécrit une fois, dans le moteur qui construit les apps. Quand une exigence devient obligatoire, elle est intégrée au même endroit, une fois. Et chaque app de la plateforme hérite de ces adaptations à sa construction suivante — la vôtre comme toutes les autres.

Ce que vous n'avez pas fait mérite d'être énuméré, parce que c'est ça, le produit : vous n'avez pas lu les notes de version. Vous n'avez pas cherché lesquelles des fonctions concernées votre app utilisait. Vous n'avez pas arbitré entre l'ancienne et la nouvelle façon de faire. Vous n'avez même pas su qu'il y avait un arbitrage.

Une précision honnête, parce qu'elle compte : cette veille n'a rien d'une assurance tous risques. Elle n'attrape que ce qui a été annoncé ou repéré — c'est un travail continu, exercé par des gens, pas une garantie magique. Mais c'est exactement pour cela qu'elle a de la valeur : elle existe, elle ne s'interrompt pas, et elle n'est pas à votre charge.

Posons le contrepoint, parce qu'il donne la mesure. Si c'est vous qui maintenez le code source de votre app — écrit par un prestataire, ou généré à partir d'un prompt —, septembre a un tout autre visage. Il faut lire ce qui change, identifier ce qui vous concerne parmi des centaines d'annonces, modifier le code, reconstruire, re-soumettre. Puis recommencer pour Android. Puis l'année suivante. Que vous ayez quelque chose de neuf à publier ou non : le rendez-vous est fixé par les systèmes, pas par votre calendrier.

Ce rendez-vous annuel existe aussi sur une plateforme — simplement, il est chez nous. C'est toute la différence entre posséder un problème et bénéficier de sa solution.

Les articles de cette série se terminent d'habitude par la liste de ce que personne ne peut faire à votre place — la carte complète est dans le premier article. Pour les évolutions d'iOS et d'Android, cette liste a une particularité : elle est vide.

Aucune décision à prendre, aucune échéance à suivre, aucun réglage à modifier. C'est la seule des grandes forces qui pèsent sur une app dans la durée pour laquelle votre part du travail est nulle — et c'est précisément pour cela que cet article existe : pour que vous sachiez que cette question-là, vous avez le droit de ne plus vous la poser.

Le seul geste qui reste vôtre est celui qui l'a toujours été : décider quand publier une mise à jour. Les adaptations, elles, sont prêtes et attendent — votre app les embarque à sa prochaine construction, que vous publiiez pour cette raison ou pour n'importe quelle autre.

Le bénéfice tient en une image : la keynote redevient un spectacle. Vous pouvez la regarder par curiosité, vous réjouir d'une nouveauté, ou l'ignorer complètement — aucun des trois choix n'a de conséquence pour votre app. Le mois où tout l'écosystème mobile retient son souffle est, pour vous, un mois comme les autres.

Pour ceux que la mécanique intéresse, j'ai raconté côté ingénierie ce que trois ans d'évolutions des systèmes font réellement à une app — et le travail, peu spectaculaire, qui permet de l'absorber.

Et si vous n'avez pas encore d'app, autant la construire à un endroit où septembre ne sera jamais votre problème : créer mon app avec GoodBarber.

Une fonction utilisée par mon app peut-elle s'arrêter du jour au lendemain ?

C'est rare. La plupart des retraits sont annoncés à l'avance par Apple et Google, avec une échéance — c'est ce qui rend la veille possible : lire ces annonces avant qu'elles prennent effet, et remplacer le composant concerné en amont, pour toutes les apps de la plateforme. Le scénario du « tout s'arrête un matin sans prévenir » est précisément celui que ce travail existe pour empêcher.

Que se passe-t-il pour mon app le jour où un nouvel iOS ou Android sort ?

De votre côté, rien à faire. Un nouveau système ne supprime pas votre app et n'efface rien. Les adaptations qu'il rend nécessaires sont préparées dans le moteur qui construit les apps, et la vôtre les embarque à sa prochaine construction — qu'elle soit motivée par cette raison ou par une simple mise à jour de routine.

Mon app peut-elle être « en retard » de plusieurs versions d'iOS ?

Elle peut, si elle n'a pas été reconstruite depuis longtemps — et ce n'est pas une impasse. Le moteur, lui, est resté au niveau : à la reconstruction suivante, votre app ressort adaptée au système actuel, quel que soit le nombre de versions écoulées entre-temps. Le rattrapage ne se paie pas au prorata du retard.

Une nouvelle version d'Android peut-elle rendre quelque chose obligatoire pour mon app ?

Oui, c'est même le mouvement le plus courant : une nouvelle exigence — souvent liée à la sécurité ou à la vie privée — devient progressivement incontournable, avec une échéance. Sur une plateforme, cette exigence est intégrée une fois, en amont, pour toutes les apps ; la vôtre s'y conforme à sa construction suivante, sans que vous ayez eu à en connaître l'existence.