Prendre en charge des iPhone que nous n'avons pas

Notre équipe dispose de nouveaux iPhone. Ce n'est pas le cas de nos utilisateurs. Chaque jour, bon nombre de personnes qui ouvrent l'une de nos applications utilisent un appareil qui a trois, quatre, voire cinq ans. Si nous ne testions nos applications que sur les appareils que nous avons dans nos poches, nous les mettrions à disposition d'un public qui n'est pas le nôtre.

C'est facile à oublier dans un petit studio. Quand on développe toute la journée sur du matériel performant, la rapidité devient la norme, et tout ce qui fonctionne simplement « bien » sur un ancien téléphone ne nous semble plus être un problème. La seule solution fiable que nous ayons trouvée consiste à placer physiquement l'ancien téléphone devant nous à chaque fois.

Notre flotte de référence

Nous conservons un petit parc d’appareils physiques : un modèle iPhone de chacune des cinq dernières années, ainsi que le modèle iPad le moins cher actuellement commercialisé. Chaque version est testée sur ce parc avant de quitter le service d’assurance qualité, et pas seulement sur le matériel le plus récent qui se trouve sur les bureaux des ingénieurs. Le téléphone vieux de cinq ans permet de détecter des problèmes qu’aucun simulateur ne peut repérer.

La procédure n'a rien de très glamour. Installer la version, la démarrer à froid, faire défiler la liste la plus longue de l'application, ouvrir l'écran le plus lourd, faire pivoter l'appareil, mettre l'application en arrière-plan puis y revenir. Sur le iPad, nous vérifions également le mode Split View, car un iPad bon marché exécutant deux applications côte à côte est un appareil très différent d’un modèle neuf n’en exécutant qu’une seule. Tout cela ne prend pas beaucoup de temps, et c’est la partie de la semaine de lancement que nous sommes le moins enclins à sauter.

Ce raisonnement s'applique également au-delà du iPhone. Nos applications Android sont testées sur du matériel modeste, et pas seulement sur des téléphones haut de gamme, et nos applications iPhone et iPad fonctionnent également sur les Mac équipés d’Apple Silicon, où une mise en page qui semblait correcte sur un téléphone peut soudainement s’afficher dans une fenêtre redimensionnable.

Ce que nous avons appris

Les animations qui semblent fluides sur la toute dernière puce paraissent saccadées sur un modèle de deux générations plus ancien. Des options de décodage d’images invisibles sur un Pro Max peuvent bloquer le thread principal sur un SE de base. Les ressources mémoire, généreuses sur les appareils dotés de 8 Go, sont limitées sur ceux équipés de 4 Go. Aucun de ces problèmes ne se manifeste sous forme de bugs — ils se traduisent par le sentiment subtil que l’application est moins performante sur les téléphones moins chers, ce qui est exactement l’impression que nous ne voulons pas donner.

Au début, notre erreur a été de considérer l’ancien téléphone comme un simple test final plutôt que comme une source d’informations pour la conception. Nous créions un écran, nous le peaufinions sur du nouveau matériel, puis nous découvrions seulement après qu’il présentait des saccades sur l’ancien appareil — et à ce stade, la correction impliquait de retravailler quelque chose que nous avions déjà considéré comme terminé. Désormais, l’ancien téléphone est pris en compte dès le premier prototype. Si une animation ou une liste ne fonctionne pas correctement sur cet appareil, nous modifions la conception, et pas seulement le code.

Il y a des compromis à faire. Certains effets ne valent tout simplement pas la peine s’ils ne sont mis en valeur que sur le matériel le plus récent ; nous choisissons donc de ne pas les intégrer. Il arrive donc parfois qu’une application paraisse un peu plus sobre sur une capture d’écran que celle d’un concurrent. Cela ne nous pose aucun problème.

Notre minimum

Deux versions iOS en arrière pour toutes les applications Zydeno. Le rythme auquel Apple rend ses fonctionnalités obsolètes est suffisamment rapide pour que remonter plus loin complique la maintenance du code, mais remonter de deux versions fait la différence entre offrir un bon service à la plupart de nos utilisateurs et ne servir que ceux qui utilisent la dernière version du système d'exploitation.

Respecter cette ligne de conduite implique parfois d’attendre avant d’adopter une nouvelle fonctionnalité du système, ou de la concevoir de manière à ce que l’application continue de fonctionner sans elle. Cela représente un coût réel en termes de temps de développement. Nous préférons assumer ce coût plutôt que de dire à quelqu’un que son téléphone, qui fonctionne parfaitement bien, n’est plus assez performant à nos yeux.

Ce téléphone bon marché est un critique impartial. Ce n'est pas pour rien qu'on le garde sur le bureau.