Interview : les nouveautés d'iPhone OS 4 expliquées par un développeur

L'iPhone OS 4 apporte plus de 1.500 nouvelles APIs pour les développeurs, et plus de 100 nouveautés pour l'utilisateur, et sera donc la mise à jour la plus importante depuis la création du système d'exploitation mobile d'Apple.

Stévan Le Meur, ingénieur d’étude et développement iPhone de Dsquare, agence intégrée de Niji, qui accompagne ses clients dans la création de services innovants cross-média reposant sur les technologies de la convergence (web, mobiles, IPTV, etc.), nous aide à décrypter quelques-unes des nouveautés de cette nouvelle mouture d'iPhone OS.

On a beaucoup parlé du multitâche, et Apple explique l'avoir fait différemment, et, selon elle, de la manière la plus adaptée possible à l'iPhone. Qu'en est-il ?
La manière dont Apple a pensé le multitâche est très intéressante : il va falloir un peu de temps pour le mettre en place, mais elle a réfléchi à une solution adaptée aux usages des conditions d'ultra-mobilité. Sa solution est élégante : elle a sélectionné un certain nombre de services auxquels le développeur a accès, ce qui est idéal pour limiter l'impact sur les ressources disponibles (processeur, mémoire, batterie).

Pour une application de VoIP, par exemple, le système va réveiller toutes les dix secondes certains processus de l'application pour qu'elle signale sa présence au réseau, et actualiser son état — ou vous prévenir si quelqu'un essaye de vous joindre. Ce n'est donc pas un portage du système du multitâche de la station de travail, mais une adaptation taillée sur mesure pour l'iPhone.

Quelle est la différence avec les systèmes de multitâche d'autres plateformes mobiles, par exemple Android ?
Google fournit, dans son système de multitâche, des solutions pour préserver la batterie et les ressources, mais leur implémentation reste à la charge et au bon vouloir du développeur et s’apparente plus à un système multitâche classique. Apple a souhaité être moins permissif et garde la main sur l'utilisation des ressources : c'est le système qui les maîtrise, et il va par exemple prévenir une application abonnée à un service (géolocalisation, VoIP…) d’un changement afin que celle-ci puisse exécuter une tâche en réponse, si besoin.

D’une manière générale, il faut développer de manière intelligente : Apple comme Google recommandent de limiter l'usage de la RAM et de mettre en place des tâches peu gourmandes. Apple contraint davantage les développeurs à mettre en place les bons mécanismes.

Quelles sont les contraintes, justement ?
La première contrainte est d'utiliser les APIs d'Apple pour gérer les différents états de l'application, et les transitions entre ces différents états. Le but est de mettre en place des mécanismes qui vont permettre de relancer le plus rapidement possible l'application, selon les conseils fournis par Apple — et ils sont nombreux. Ainsi, de nombreuses applications présentes sur l’App Store vont nécessiter des adaptations.

La seconde contrainte vient du système, qui peut à tout moment avoir besoin de plus de plus de ressources, et demander à une application d'en libérer. Il faut donc gérer tout cela, ce qui nécessite un certain équilibre entre le fait de libérer un maximum de ressources quand l'application est en arrière-plan, et le fait de relancer l'application le plus vite possible.

Qu'est-ce que cela représente en matière de difficulté de développement, d'habitudes à prendre pour respecter les canons d'Apple ?
La sauvegarde de l'état d'une application à sa fermeture pour que l'utilisateur la retrouve dans le même état à la réouverture est quelque chose que les développeurs mettaient en place assez peu jusque-là, cela deviendra une vraie nécessité.

C'est pourtant ce système de fast-app switching qui donne l'impression de rapidité et de multitâche réel. Pour prendre l'exemple de l'application MacG Mobile, il faudrait, dans l'OS 4, que si on la quitte alors qu'on lit les commentaires d'un article, on y retourne exactement au même endroit. Mieux, il faut sauvegarder toute la profondeur d'une application, c'est-à-dire qu'il faudra aussi sauvegarder le fait qu'on lisait les commentaires de tel article dans tel flux de news [NDLR : cette fonctionnalité a déjà été ajoutée dans une bêta interne].

Plus une application est complexe, et plus la profondeur de navigation est grande, et donc plus la difficulté de mise en place est grande. Ce n'est pas neutre sur le développement, et cela va donc demander du temps supplémentaire ; on ne va pas non plus doubler le temps de développement de l’application, même si on aura quand même des choses à ajouter et à modifier ici ou là.

Par certains aspects, la chose est facilitée maintenant : c'était un peu le casse-tête à développer, cela devient un peu plus facile — et est de toute manière incontournable si on veut proposer l'expérience la plus aboutie possible à l'utilisateur, qui est aussi, et souvent un client.

Le fast-app switching apparaît comme la fondation du multitâche selon Apple, mais les notifications push ne sont pas abandonnées, voire sont remises à l'avant-plan. Pourquoi l'apparition des notifications locales ?
L'apparition des notifications locales permet de faire de nombreuses choses simples, mais qui étaient coûteuses à mettre en œuvre (mise en place d’une plateforme de services par exemple). Elles sont destinées à utiliser les données locales de l’utilisateur afin d’interagir directement avec lui, et vont simplifier la mise en place de certaines applications ou services types comme des réveils, des gestionnaires de tâches…

Les notifications push classiques, elles, passent par un serveur, et utilisent des données du nuage, qui entrent de l'extérieur, que le développeur veut donner à son utilisateur, et que l'utilisateur veut voir — c'est le cas typique d'une application d'actualités.

La conjonction du fast-app switching et de ces deux types de notifications offre un mécanisme de multitâche totalement adapté aux usages mobiles, qui en plus d'être efficace est cohérent et élégant.

Quel est l'intérêt de donner l'accès à une API de géolocalisation en arrière-plan, au-delà de l'application de navigation ?
La géolocalisation, c'est la possibilité de savoir où est l'utilisateur, et avec très peu de données, de savoir ce qu'il veut en fonction de son contexte — dans la limite des garde-fous imposés par Apple.

Pour une application comme la Visite des jardins du château de Versailles, ou pour toute autre application de tourisme, pour un parc d'attractions, etc., la géolocalisation permet de « pousser » du contenu vers l'utilisateur : l'application tourne en arrière-plan, mais elle va continuer à enregistrer le circuit de visite, et par exemple proposer des notifications à l’approche de points d'intérêts.

La seule petite limitation est le double système de géolocalisation d'Apple, qui est aussi son avantage. Quand on est en voiture et qu'on veut utiliser une application de navigation, celle-ci peut utiliser le GPS même en arrière-plan, puisque l'iPhone est censé être branché. Pour un usage en mobilité, il sera préférable d’utiliser la géolocalisation par triangulation réseau, ce qui a un impact moindre sur l'autonomie. Il s’agit donc d’apporter la meilleure réponse adaptée au contexte d’utilisation.

Il y a néanmoins plein d’usages à imaginer, comme de fournir de la publicité géocontextualisée. Il est hors de question de transformer l'iPhone en guirlande publicitaire, mais on peut imaginer une application de tourisme comme Vivre à Rennes qui pourrait « pousser » des informations, des bons plans et des coupons de réduction à l'utilisateur en fonction de sa proximité à des points d'intérêt qu'il aurait prédéfini.