Avec iOS 9, Apple a nettement amélioré le multitâche sur iPad grâce à Split View. Deux apps peuvent se partager l'écran, soit à égalité, soit avec l’une des deux sous la forme d’un bandeau à droite. C’était un premier pas perfectible, mais un premier pas quand même vers une interface adaptable.
Le multitâche n’a pas évolué depuis ce premier ajout et peut-être qu’iOS 11 sera (enfin) l’occasion de faire bouger les lignes. Verra-t-on un jour sur l’iPad un système de fenêtres similaire à celui de macOS ou Windows ? C’est peu probable, en tout cas Apple a toujours été convaincu que ce n’était pas la bonne réponse pour ses tablettes, tout comme le tactile n’était pas la solution pour ses ordinateurs.
Cette position n’est pas réservée aux développeurs qui travaillent en interne sur iOS, l’équipe en charge de la validation sur l’App Store l’applique aussi. Le développeur Steven Stroughton-Smith conçoit depuis quelques jours une app pour iPad qui repose sur un système de fenêtres. En guise d’exemple, il a reproduit grossièrement le Finder de macOS, mais l’objectif est plutôt de recréer le fonctionnement des fenêtres pour l’appliquer à un appareil tactile.
Son interface comprend une méthode de tiling où les différentes fenêtres sont réparties sur l’écran sans se superposer. L’utilisateur peut, selon ses envies, déplacer librement une fenêtre en touchant la barre du haut ou bien la caler sur la moitié ou un quart de l’écran en la collant sur les bords de l’écran. Il a même prévu des raccourcis clavier pour réaliser ces opérations, reproduisant assez fidèlement ce que l’on peut avoir sur un ordinateur.
Voici, par exemple, comment on pourrait organiser quatre fenêtres différentes à l’écran : soit une fenêtre sur chaque moitié de l’écran, soit quatre visibles sur un quart de la surface. Ici, la méthode utilisée est l’écran tactile, mais on pourrait également utiliser un clavier pour obtenir le même résultat.
Ce projet n’est pas qu’un design statique ou même un prototype, c’est une véritable application fonctionnelle que Steven Troughton-Smith a soumise pour validation, non pas directement sur l’App Store, mais sur TestFlight. Ce service d’Apple permet aux développeurs de fournir des apps en bêta-test et il est soumis à une validation de principe, essentiellement pour s’assurer qu’une bêta n’est pas un malware déguisé.
L’accès à TestFlight s’est fait sans problème, mais l’équipe de validation de l’App Store a alors appelé le développeur pour l’informer qu’une telle application ne serait jamais validée si elle était soumise. En particulier, c’est la possibilité de superposer deux fenêtres qui pose problème : une app peut afficher deux fenêtres côte à côte, elle peut même permettre à l’utilisateur de les dimensionner différemment, mais ces fenêtres ne doivent jamais se superposer.
Ce n’est pas une politique nouvelle, improvisée pour l’occasion. Apple ne veut pas qu’une app reproduise l’interface de macOS ou de n’importe quel autre système d’exploitation pour ordinateur de bureau. Un développeur avait tenté une copie presque parfaite du système d’Apple en 2012 et il avait été bloqué lors de la validation.
Ce cas est un petit peu extrême et on peut comprendre sans peine pourquoi Apple n’en voudrait pas. Mais ce n’est pas qu’une question de copie de système : fondamentalement, le constructeur refuse le concept de fenêtres sur l’iPad. La preuve avec Status Board, l’ancienne app de Panic qui permettait de créer un tableau de bord avec un iPad. Finalement retirée à l’automne faute de rentabilité, elle aurait pu être abandonnée beaucoup plus tôt, comme l’explique Cabel Sasser, le cofondateur de l’entreprise.
L’équipe de validation a refusé l’application pour un motif étrange : une app a le droit d'afficher des widgets, mais un seul à la fois. Ce qui, dans le cas de Status Board, n’avait absolument aucun sens, comme Panic a argumenté auprès d’Apple à cette occasion. Après plusieurs allers et retours, les deux parties ont trouvé un compromis : l’app peut afficher plusieurs widgets et l’utilisateur peut les déplacer, mais à condition qu’ils n’affichent aucun contenu.
De fait, pour modifier son tableau dans Status Board, il fallait passer par un mode spécifique qui n’affichait plus que les intitulés de chaque widget. On pensait jusque-là que Panic avait fait ce choix, il s’avère finalement que c’est Apple qui l’a imposé, alors que l’idée originale était beaucoup plus proche d’un système de fenêtres, où l’on aurait pu modifier le tableau sans changer d’affichage.
Ces quelques exemples le montrent bien : Apple ne veut pas de fenêtres sur son iPad ou une interface qui s’en approche. C’est une politique ancienne et maintenue jusque-là, non seulement en interne pour le développement d’iOS, mais aussi pour bloquer les développeurs tiers.
Apple bloque-t-elle l’innovation sur l’iPad ?
Pour Steven Troughton-Smith, cela ne fait aucun doute : cette politique où seule Apple peut innover bloque l’iPad et empêche des idées novatrices d’émerger. Sa série de tweets a lancé un débat au sein de la rédaction et les avis sont tranchés. Pour ma part, je me range du côté de ce développeur et considère que la validation sur l’App Store devrait se limiter à repousser les abus de développeurs malveillants.
Apple utilise cette étape de validation comme un outil politique. Ce qui peut entrer et rester sur l’App Store découle d’un choix conscient effectué en interne et le cas des fenêtres sur l’iPad est loin d’être le premier. Vous vous souvenez peut-être des polémiques qui ont suivi le lancement des widgets avec iOS 8. Les développeurs ont passé l’été à imaginer des usages et le constructeur a passé son automne à les bloquer : il était interdit d’en faire un lanceur d’apps, interdit aussi d’en faire une calculatrice (avant de changer d’avis), interdit d’afficher un clavier dans le centre de notifications, etc.
On pourrait multiplier les exemples, mais revenons-en aux fenêtres sur l’iPad. Qu’Apple n’en veuille pas dans iOS, c’est naturellement son droit et c’est peut-être la meilleure réponse pour la tablette. La simplicité est un élément clé pour comprendre le succès de cette plateforme et les avis sont manifestement partagés sur la question. On imagine bien que l’entreprise de Cupertino a essayé de nombreux concepts et qu'elle considère qu’ils ne sont pas aussi bons que ce que l’on a aujourd'hui, un modèle centré essentiellement sur une app en plein écran.
Je suis convaincu néanmoins qu’Apple ne devrait pas empêcher les développeurs d'expérimenter autour des fenêtres s’ils le souhaitent. Bloquer systématiquement toute tentative de créer un système de fenêtres est, à mon sens, un aveu de faiblesse de la part d’Apple. Si le constructeur est aussi certain que sa vision est la bonne et que les fenêtres sont nocives pour la plateforme, alors pourquoi empêcher un tiers d’essayer ?
Assurément, les apps qui s’y risqueront connaîtront un échec commercial ou un manque d’intérêt et leurs créateurs reconnaîtront leur erreur, abandonneront le projet et passeront à autre chose. On en parlera sans doute un petit peu à leur sortie, mais si l’idée est aussi mauvaise qu’Apple semble le dire, tout le monde l’aura oubliée en quelques mois.
La politique actuelle donne au contraire le sentiment qu’Apple n’est pas sûre que son approche est la bonne et qu'elle essaie à tout prix de la protéger et de l’imposer contre l’envie des développeurs. Et des clients ? C’est toute la question en effet, mais comment savoir ce qu’il en est, si personne ne peut essayer ? Le constructeur devrait laisser le marché décider — on sait que l’App Store est un marché redoutable, avec beaucoup plus d’échecs que de réussites à son compte.
En agissant ainsi, Apple se prive de l’innovation qu’un développeur tiers pourrait apporter. Vous vous souvenez peut-être de Tweetie, un client Twitter qui a apporté une idée toute bête, mais désormais omniprésente : on pouvait tirer la liste de tweets pour la recharger. De nombreuses apps l’ont adopté et Apple a fini par l’ajouter à iOS après quelques années, tant ce geste était devenu populaire.
Et si Apple passait à côté d’une idée aussi géniale en bloquant systématiquement les développeurs ? Ça ne serait peut-être pas un système avec des fenêtres identiques à celles que l’on connaît dans macOS ou Windows. Mais peut-être que quelque part, un développeur a une excellente idée et elle ne verra jamais le jour à cause de cette politique. Et au fond, c’est ça le cœur du problème pour moi et peut-être ce qui empêche l’iPad de remplacer davantage les ordinateurs traditionnels.
La fenêtre comme on la connaît aujourd'hui n’est peut-être pas la solution et on pourrait imaginer un système plus accessible au grand public, masqué quand il n’est pas nécessaire. Il me semble indéniable en revanche que la possibilité d’afficher plusieurs contenus, voire plusieurs apps, sur un même écran est un élément essentiel pour améliorer la productivité. En tout cas, j’ai essayé plusieurs fois de travailler avec un iPad, et c’est l’un des plus gros problèmes que j’ai rencontrés.
L’écran partagé d’iOS est loin de me permettre d’avoir une configuration optimale comme sur un ordinateur traditionnel, où j'utilise plusieurs écrans physiques, plusieurs bureaux virtuels et un grand nombre de fenêtres ouvertes en permanence, parfois sur un même écran. Je passe constamment d’un bureau virtuel à l’autre et d’une fenêtre à l’autre et c’est ainsi que je travaille depuis… depuis que j’utilise un ordinateur.
Certes, on pourrait arguer que c’est une méthode ancienne et dépassée et que je ferais mieux d’essayer la nouvelle voie tracée par l’iPad. C’est aussi ce que dit Apple, notamment à travers sa dernière campagne de publicités qui met en avant la tablette contre les PC. Certes, mais j’ai essayé les deux solutions et je suis incroyablement plus efficace avec des fenêtres. Et puis je ne vois pas en quoi je devrais m’adapter à un outil, surtout quand j’en utilise déjà un qui me donne entièrement satisfaction.
Au-delà de mon cas personnel et du débat sur les fenêtres et l’iPad, la validation de l’App Store ne devrait pas brider les développeurs. Tant qu’ils restent dans les clous (pas d’apps malfaisantes ou destinées à tromper, respect du sandbox et des règles de sécurité de base), les développeurs devraient pouvoir innover dans tous les sens. Et au bout du compte, les utilisateurs décideront si ces expérimentations sont intéressantes, utiles ou des échecs complets. Quel mal y aurait-il à suivre cette stratégie ?