Pour beaucoup de développeurs, iOS 8 était peut-être la mise à jour la plus importante depuis la sortie du premier iPhone en 2007. Certes, iOS 7 avait demandé beaucoup de travail pour refaire les interfaces de chaque application, mais sur le plan fonctionnel, cette version n’ajoutait rien. Le système mobile sorti cette année n’a pas touché à l’interface, mais il a considérablement enrichi les possibilités des développeurs : extensions pour s’intégrer aux menus de partage, widgets dans le Centre de notifications, claviers personnalisés…

Apple a ouvert iOS et pour la première fois, les développeurs pouvaient intégrer leurs applications et leurs fonctions au cœur du système. On les retrouve dès qu’on partage un élément, quand on affiche le Centre de notifications et même, pour les claviers, partout où l’on saisit du texte. Depuis la présentation d’iOS 8 et de ses nouveautés lors de la WWDC de juin dernier, une sorte d’euphorie s’est emparée des développeurs. Pendant tout l’été, ils ont travaillé sur les nouveautés présentées par Apple, les ont souvent intégrées à leurs applications et ils étaient nombreux à répondre présents dès le jour de la sortie d’iOS 8.

L’euphorie est toutefois vite retombée. Alors qu’Apple avait validé la majorité des applications exploitant les nouveautés, l’entreprise a apparemment eu quelques remords par la suite. Depuis la sortie d’iOS 8, les polémiques autour de l’App Store se multiplient : des applications validées dans un premier temps ont été retirées et les nouveautés du système posent de plus en plus de problème.

L’App Store a toujours été critiqué pour sa validation et surtout ses incohérences, mais le sentiment général n’a semble-t-il jamais été aussi exacerbé contre la boutique. Il faut dire que les développeurs ont de quoi être énervés, tant les équipes en charge de la validation font preuve d’une inconstance… constante.

À quoi servent les nouveautés d’iOS 8 ?

Pour les développeurs, iOS 8 est la mise à jour qu’ils n’attendaient plus vraiment. Pendant des années, les applications de l’App Store étaient largement restreintes et elles n’avaient que très peu de prise sur le système mobile. Tout au plus pouvaient-elles envoyer des notifications et se lancer pour ouvrir certains types de fichiers, mais c’est à peu près tout. Au contraire, iOS 8 s’est ouvert à tous les niveaux et les développeurs ont eu de quoi faire, entre le Centre de notifications et le partage, entre iCloud Drive et l’accès à Touch ID.

Comme à son habitude, Apple a incité tous les développeurs à adapter leurs applications pour ajouter ces nouveautés, voire à créer de nouvelles applications pour les exploiter. Comme tous les ans, ce plan a parfaitement fonctionné, puisque l’App Store était plein d’applications adaptées à iOS 8 dès sa sortie, en septembre dernier. Ce qui nous a permis de publier des articles assez complets sur les widgets à installer dans le Centre de notifications, ou sur les claviers tiers pour remplacer celui par défaut et ce, quelques jours seulement après le lancement d’iOS 8.

Jusque-là, tout allait pour le mieux, mais les équipes en charge de la validation sur l’App Store ont commencé à bloquer des applications. C’est le Centre de notifications qui a été le plus touché : alors qu’Apple avait accepté à peu près toutes les applications avant la sortie d’iOS 8, l’entreprise s’est depuis ravisée. Dès la fin du mois de septembre, tous les widgets qui permettaient de lancer d’autres applications ont été rejetés. Un mois plus tard, ce sont les widgets calculatrices qui ont failli ne plus être bienvenus, mais Apple a rapidement corrigé le tir.

Ce n’était pas fini toutefois, puisqu’en novembre, Apple a décidé que les widgets ne devaient pas avoir de clavier. Et en décembre, l’entreprise s’en prenait aux boutons, en particulier à ceux qui permettent de terminer une tâche. Mais alors, à quoi servent les widgets du Centre de notifications ? Si l’on en croit les dernières règles, uniquement à afficher des informations, sans plus. Apple décide des règles sur l’App Store et le constructeur peut très bien décider que les widgets ne servent qu’à cela.

Mais alors, pourquoi avoir montré pendant le keynote de la WWDC un widget eBay qui permet d’ajouter une enchère sans ouvrir l’application correspondante ? Si ce widget était soumis aujourd'hui à l’App Store, il serait probablement refusé, puisqu’il ne correspond pas aux dernières règles en vigueur. Au-delà de l’absurdité qui consiste à montrer une fonction en juin pour l’interdire en décembre, au-delà même de l’avis que l’on peut avoir sur l’utilité de ces widgets, cette validation a posteriori pose un problème. Si l’App Store valide constamment des applications avant de changer d’avis, comment les développeurs peuvent savoir ce qu’ils doivent faire ?

L’indécision d’Apple vis-à-vis des nouvelles fonctions d’iOS 8 ne concerne pas seulement le Centre de notifications, malheureusement. Peu à peu, ce sont toutes les nouveautés qui sont remises en cause. Ce ne sont pas les exemples qui manquent, mais prenons-en un qui est assez représentatif  : le cas de Transmit et d’iCloud Drive. Rappelons qu’Apple a entièrement revu la fonction de synchronisation de fichiers avec iCloud pour iOS 8. Nommée désormais iCloud Drive, elle est beaucoup plus souple qu’avant, puisque toutes les applications peuvent accéder à tous vos documents.

Sur le papier, c’est idéal pour passer d’une application à l’autre : par exemple, on peut modifier une image dans une application, puis la mettre en ligne avec une autre application, sans dupliquer le fichier. Mieux, iOS 8 ne se limite pas à iCloud Drive et l’utilisateur peut accéder à ses documents en ligne même s’il utilise Dropbox ou OneDrive. Ça, c’est la théorie, car les équipes en charge de la validation de l’App Store ont empêché Panic d’en tirer partie ainsi.

Le gestionnaire de FTP Transmit a été forcé de retirer son accès à iCloud Drive avec sa dernière mise à jour. Le motif ? Le service d’Apple ne doit servir qu’à synchroniser des fichiers créés par une application, il ne peut pas être utilisé pour transférer des documents d’un endroit à un autre. Dans ce cas, l’application pouvait télécharger un fichier depuis un serveur et le stocker sur iCloud Drive. Cette nouvelle règle n’a aucun sens. Déjà, parce que si on a un Mac, iCloud Drive est accessible depuis le Finder et on peut alors y stocker n’importe quel fichier, d’où qu’il vienne. Si on a installé Transmit sur son Mac, on peut faire exactement ce qu’a reproché la validation de l’App Store : glisser un fichier depuis un serveur vers iCloud Drive, et vice-versa. Et sur Mac, Apple ne peut rien faire contre ce comportement, puisque son service de synchronisation est disponible comme n’importe quel autre dossier.

Ensuite, l’éditeur qui a essayé d’argumenter avec l’App Store pour ne pas perdre la fonction, a bien obtenu une explication, mais qui n’a rien à voir avec iCloud Drive. Reste à espérer que les équipes en charge de la validation se sont trompées et que Transmit puisse restaurer cette fonction, sinon il va falloir retirer un grand nombre d’autres applications de l’App Store. Aux dernières nouvelles, Transmit devrait pouvoir récupérer sa fonction, mais ce n’est pas le cas pour le moment.

[MàJ 11/12/2014 18h42] : l'éditeur confirme sur Twitter qu'il pourra restaurer cette fonction.

Quoi qu’il en soit, cette demande absurde illustre bien le problème de l’App Store depuis la sortie d’iOS 8. Pourquoi est-ce qu’Apple empêcherait les développeurs d’utiliser ces nouveautés ? Quel serait son intérêt si aucune application n’utilisait ces fonctionnalités ? L’entreprise devrait au contraire mettre en avant ces apps qui exploitent ce qu’elle met au point et ce qu’elle vend, plutôt que d’approuver quelque chose, avant de se rétracter.

iOS 8 n’est que la partie immergée de l’iceberg : le problème, au fond, est ancien et beaucoup plus gênant pour Apple et l’App Store.

Une validation toujours plus stricte et aléatoire

Depuis les premiers jours de l’App Store, à l’été 2008, des critiques se sont faites entendre sur la boutique d’applications. Le point qui a cristallisé les rancœurs concerne la validation a priori de toutes les nouvelles applications, mais aussi de toutes les mises à jour. Depuis le début, des développeurs ont eu des problèmes avec cette validation qui est loin d’être systématique, contrairement à ce que l’on pourrait croire.

Certes, chaque fichier envoyé sur l’App Store est préalablement vérifié par une équipe. Mais cette équipe se contente en fait de tests automatisés dans la majorité des cas, notamment pour savoir si l’application n’utilise que du code autorisé, ou pour vérifier qu’elle se lance bien. Une intervention humaine est réservée à une infime minorité des applications, sélectionnée au hasard. C’est le même principe que les contrôles de la douane, ou ceux du fisc et c’est assez logique. Si Apple testait manuellement chaque mise à jour, il lui faudrait une équipe de plusieurs dizaines de milliers de personnes.

Le problème, ce n’est pas la sélection aléatoire, mais la validation aléatoire. Deux applications avec les mêmes fonctions peuvent avoir deux réponses différentes, sans aucune logique pour expliquer cette différence. Sans compter que les rejets ne sont pas toujours justifiés : une application d’actualité parle de jailbreak ? Une autre nécessite de créer un compte pour être utilisée ? Ce sont des motifs suffisants pour être bloqué à la validation.

Pour un développeur toutefois, le plus frustrant est de se trouver face à une oreille sourde au sujet d’un problème qui n’en est pas un. Prenons un exemple parmi des milliers : Creaceed a travaillé l’été dernier pour intégrer les nouveautés d’iOS 8 à Prizmo, son application qui fait d’un appareil mobile un scanner de poche. L’éditeur ne fait pas les choses à moitié, puisque la version sortie en même temps que le nouveau système mobile intègre toutes les fonctions attendues, des extensions à Handoff en passant par iCloud Drive.

Cette mise à jour majeure est validée par Apple à temps pour le lancement d’iOS 8 et l’entreprise choisit même l’application pour mettre en avant les nouveautés du système mobile. Malheureusement, un bug spécifique aux nouveaux iPhone est détecté rapidement par l’éditeur après le lancement et une mise à jour est envoyée en urgence. On aurait pu penser que la validation de l’App Store laisserait passer cette version, puisque l’application toujours mise en avant donne de mauvais résultats avec les iPhone 6 et iPhone 6 Plus. Sauf que cette mise à jour mineure n’a pas eu de chance, elle a été validée à la main par un employé qui a fait du zèle.

L’éditeur a été bloqué pour une raison des plus stupides : au lancement, Prizmo génère quelques fichiers en guise d’exemples, à la fois pour montrer les fonctions de l’application et pour éviter d’avoir une interface vide au premier lancement. Ces fichiers pèsent environ 4 Mo et, iCloud Drive oblige, ils sont transférés automatiquement sur les serveurs d’Apple. Et c’est précisément ce qui bloque : l’application ne peut pas ajouter des fichiers au lancement.

L’éditeur n’a pas eu d’autres choix que de discuter et il a fallu 27 jours pour que la mise à jour soit disponible… sans les exemples. Près d’un mois durant lequel les utilisateurs des nouveaux iPhone n’ont pas pu utiliser totalement l’application. Un mois de critiques négatives qui ont fait baisser la note de Prizmo : quand on sait l’importance de celle-ci sur les ventes sur la boutique, on comprend l'angoisse chez Creaceed. Et au total, c’est la validation de l’App Store qui a gagné : l’application est désormais totalement vierge quand on la lance.

Ce n’est qu’un exemple parmi d’autres, mais il est significatif. Les développeurs peuvent être de bonne foi, il suffit de mal tomber une fois pour qu’une mise à jour banale et parfois essentielle ne soit pas acceptée, ou soit bloquée pour une raison ou une autre. Votre application utilise Touch ID pour sécuriser l’accès à une fonction, mais les validateurs de l’App Store ne peuvent pas la tester ? On vous demandera de réaliser une vidéo de promotion pour montrer la fonction et l’application ne passera pas tant que ce n’est pas fait.

De l’avis de beaucoup de développeurs, la validation App Store est devenue beaucoup plus stricte après la sortie d’iOS 8 et c’est une tendance lourde. Apple a peut-être augmenté les effectifs de l'équipe qui s’en charge, mais le nombre d’applications bloquées est, apparemment, en augmentation. Cela s’est vu dans le temps nécessaire pour passer la validation, mais au-delà de ce facteur temps, les développeurs sont de plus en plus nombreux à être exaspérés par cette étape.

En général, ils ne veulent pas totalement bannir le contrôle a priori sur l’App Store, même si certains aimeraient bien un contrôle allégé pour les mises à jour mineures. Il existe des moyens techniques pour vérifier qu’une nouvelle version se contente de corriger des bugs et n’ajoute pas des fonctions et on pourrait imaginer un système où ces mises à jour passent sans contrôle approfondi. Mais au fond, le problème n’est pas qu’une mise à jour, même mineure, soit validée manuellement.

Le problème, c’est que les règles qui déterminent ce que l’on peut et ce que l’on ne peut pas faire sur l’App Store ne sont pas aussi claires qu’Apple aime le faire croire. En théorie, elles sont toutes rassemblées sur cette page ; en pratique, ces règles évoluent au gré des vérifications et en fonction des cas rencontrés. C’est logique — personne ne voudrait de règles immuables qui n’auraient pas changé depuis 2008 —, mais la méthode employée n’est pas la bonne.

Sauf cas exceptionnels, Apple ne devrait pas valider des applications une première fois pour les rejeter ensuite. C’est exactement ce qui s’est passé pour les widgets du Centre de notifications d’iOS 8 qui ont été tous acceptés dans un premier temps, avant d’être triés a posteriori par les validateurs. Pour les développeurs, ce comportement est une catastrophe : passer du temps sur une application pour qu’elle soit retirée peu après son arrivée sur l’App Store représente une perte importante.

L’exemple de Launcher est peut-être le plus significatif. Cette application ajoutait un widget au Centre de notifications d’iOS 8 avec des raccourcis, soit vers des contacts, soit vers d’autres applications. L’application est présente sur la boutique pour le lancement de l’App Store et elle a même été sélectionnée par Apple pour mettre en avant les nouveautés d’iOS 8. Six jours plus tard, le développeur reçoit un appel d’un responsable de l’App Store : le widget doit être retiré immédiatement, ou l’application sera supprimée de l’App Store. Trois jours après, Launcher avait effectivement disparu de la boutique.

Le fait que le retrait se fasse après la mise en ligne de l’application et après la publicité faite par l’App Store est déjà scandaleux. Mais il y a pire encore : Launcher a été retiré parce qu’Apple a décidé qu’on ne pouvait pas avoir de lanceurs d’applications en widget; soit, mais cette politique n’a pas été appliquée pour les autres applications qui faisaient la même chose. Depuis, d’autres développeurs ont repris la même idée et l’App Store a validé leurs applications.

Vous voulez un exemple ? Quick-Tap propose exactement les mêmes fonctions que Launcher, elle est sortie début octobre et elle est toujours disponible dans l’App Store. Comment expliquer que deux applications identiques soient traitées de manière aussi différente ? Cette injustice a de quoi énerver les développeurs, et on les comprend.

Même si on en est encore loin, ce genre de comportements pourrait nuire à Apple. Les développeurs vont-ils continuer à investir leur temps précieux pour créer des applications iOS s’ils n’ont pas confiance en la viabilité de la boutique ? La part de marché des appareils iOS fait qu’Apple est probablement tranquille, mais il n’empêche qu’à force d’empêcher les développeurs de faire leur travail, l’entreprise pourrait se les mettre à dos.

Les publicités sur l’iPad Air le montrent bien pourtant : un appareil iOS n’est rien sans les applications qui l’accompagnent. En agissant ainsi, Apple va à l’encontre de son intérêt et même si le constructeur n’a rien à faire des développeurs, il devrait se soucier de ses clients. Or, cette politique nuit aussi à la satisfaction des utilisateurs…

Cette validation hésitante nuit à la satisfaction des utilisateurs

En matière de politique de validation de l’App Store, les développeurs sont en première ligne, naturellement. Ce sont eux qui doivent gérer les incohérences de la validation, les rejets abusifs et qui doivent ensuite tenter de négocier avec Apple. Mais il ne faudrait pas oublier une victime collatérale de cette politique : vous et moi, les utilisateurs de ces applications.

Reprenons le cas de Launcher, ce lanceur multitâches placé dans le Centre de notifications d’iOS 8 qui a été retiré quelques jours après son arrivée sur l’App Store. Si l’idée vous plaisait, vous l’avez peut-être acheté et installé sur votre iPhone. Pour le moment, on peut encore la récupérer, mais il faut passer par la liste des achats, ce qui est loin d'être évident ou facile.

Apple se vante régulièrement d’avoir le meilleur taux de satisfaction clientèle, mais sa gestion aléatoire des applications sur l’App Store pourrait faire du mal sur ce point. Le retrait d’une application est un exemple extrême, mais ce n’est pas le seul. En bloquant certaines fonctions pourtant populaires, l’entreprise bloque artificiellement ses produits. iCloud Drive doit simplifier les travaux les plus complexes sur les documents et cette fonction doit aussi permettre de passer plus facilement d’un service à l’autre. Les widgets du Centre de notifications doivent apporter de la souplesse et permettre aux utilisateurs les plus avancés d’enrichir leur iOS.

Pourquoi priver ces utilisateurs de ces fonctions ? Pour ajouter un widget dans le Centre de notifications, il ne suffit pas d’installer l’application associée, il faut aussi plusieurs manipulations. Si un utilisateur en passe par ce processus d'installation, c’est déjà qu’il est suffisamment au courant du fonctionnement d’iOS pour connaître la méthode à suivre ; c’est aussi qu’il a réellement envie de posséder et d'utiliser le widget; sinon, il saura également comment le retirer. Apple ne devrait-elle pas accepter tous les widgets et laisser ses clients trier entre ceux qui sont utiles et les autres ?

Certes, un jeu n’y a pas vraiment sa place, mais après tout, si quelqu’un veut installer un Tetris dans le Centre de notifications de son iPhone ou de son iPad, pourquoi l’en empêcher ? Chacun devrait être libre de faire ce qu’il veut de son téléphone, surtout pour une fonction avancée comme celle-ci. Apple aurait raison de filtrer soigneusement les widgets s’ils s’installaient automatiquement, mais puisque ce n’est pas le cas, pourquoi ne pas faire confiance à l’intelligence des utilisateurs ?

Apple et l’App Store : entre arrogance et incohérence

Le problème, c’est qu’Apple est très arrogante en la matière, peut-être un peu trop arrogante pour son propre bien. Dans un long article qui revient sur la disparition de son application, Cromulent Labs l’éditeur de Launcher apporte un éclairage intéressant. Le constructeur de l’iPhone a toujours eu la certitude qu’il faisait les meilleurs produits. Cette posture est accompagnée d’une certaine morgue : pour concevoir ses meilleurs produits, Apple a une idée en tête et c’est forcément la meilleure idée.

Selon l'éditeur, c’est cette philosophie qui a contaminé la validation de l’App Store. Les personnes qui s’en occupent savent mieux que les développeurs (ou même que les utilisateurs) ce qu’il faut faire et elles ont le pouvoir d’imposer leur point de vue. Ainsi, une application ne doit être lancée que depuis l’écran d’accueil, ou avec Spotlight ou Siri et c’est pourquoi Launcher a été retiré de l’App Store. Certes, le widget respectait les règles mises en place par Apple, mais qu’importe : l’entreprise n’en veut pas.

Le pire, c’est sans doute la réponse que Cromulent Labs a fini par obtenir à force d’insister : un représentant d’Apple a reconnu que Launcher avait été retiré pour l’exemple. On lui a expliqué que l’entreprise n’avait pas envisagé que les widgets puissent servir à cela et qu’après réflexion, la décision avait été prise de refuser cet usage. Apple a même ajouté que Launcher servait d’exemple pour faire comprendre aux autres développeurs que cette utilisation n’était pas souhaitée. Mais le constructeur n’a jamais mis ses règles à jour pour officialiser cette décision, ce qui permet à d’autres développeurs de reprendre l’idée et de vendre encore aujourd'hui des widgets similaires, comme on l’a vu.

Arrogance, et incohérence : Cabel Sasser, co-fondateur de Panic (l’éditeur qui a conçu Transmit) explique que l’équipe qui valide les applications iOS n’est pas à Cupertino. Ce n’est probablement pas ce qui explique les problèmes évoqués dans cet article, mais la distance n’est pas que géographique. L’App Store est une entité spécifique au sein de l’entreprise et il y a manifestement un manque de communication entre ceux qui développent et ajoutent des fonctions, et ceux qui valident ou non les applications.

Le développement des systèmes d’exploitation est chapeauté par Craig Federighi. La mise en avant des applications sur l’App Store est sous l’égide d’Eddy Cue, SVP en charge des services en ligne et notamment des boutiques. La validation de l’App Store en revanche est gérée par le marketing, contrôlé par Phil Schiller. C’est cette division qui explique la majorité des incohérences actuelles sur l’App Store : les applications sont mises en avant par une équipe, mais le contrôle et la validation sont le fait d’une autre équipe. Et ce sont encore d’autres personnes encore qui développent les fonctions et qui sont les plus à même de savoir quoi mettre en avant, et comment le mettre en avant.

Il est grand temps qu’Apple simplifie cette structure qui devient contre-productive. Qu’il y ait des luttes de pouvoir en interne ou non (il se murmure que Phil Schiller n’en fait qu’à sa tête en matière de validation), le problème reste entier. Le constructeur devrait sans doute rationaliser la gestion de l’App Store en éliminant au moins un des trois volets. Cette stratégie a déjà été employée côté développement, puisque iOS et OS X ont été regroupés sous l’égide de Craig Federighi après le départ de Scott Forstall.

En l’état, on ne voit pas comment la situation pourrait s’améliorer. Et cette situation n’est pas bonne pour les développeurs, ni pour les utilisateurs ; et in fine, c’est Apple qui en souffrira aussi.