Développer une application parallèlement sur iPhone et Android

Depuis sa sortie, l'iPhone fait une percée remarquable dans le marché du smartphone proposant toujours plus d'application sur son AppStore. Plus récemment, Android se répand à grande allure et les envies d'avoir son application sur l'Android Market se fait sentir. Mais alors comment développer la même application pour ces deux OS ? Comment profiter de leurs spécificités tout en sortant les applications en même temps ?

Développement multi-plateforme ?

Des solutions d'éditeurs (GrappleMobile, Wokup, Kony, etc.) existent pour créer une application pour plusieurs types de mobiles avec un seul code. Vous développez alors dans un langage propriétaire qui est ensuite traduit par une moulinette en Objective-C pour iPhone ou en Java pour Android.

La première barrière est donc l'apprentissage d'un nouveau langage avec de nouvelles API totalement propres à l'éditeur. Cet investissement de formation ne pourra pas être bénéfique pour de nouvelles applications qui n'utiliseraient pas les solutions de l'éditeur. Comme tout code généré, il devient difficile de maitriser le rendu final puisqu'on est totalement tributaire du bon fonctionnement de la moulinette de l'éditeur.

Autre souci, le nivellement par le bas. Tous les mobiles ne sont pas identiques :

• l'iPhone ne possède qu'un bouton mais les Android en possèdent quatre
• un "SplashScreen" est affiché au lancement d'applications iPhone mais pas sur Android
• l'iPhone offre plus de possibilités d'animation de transition entre les écrans
• etc.

Si vous développez dans un langage unique, vous ne profiterez pas de ces spécificités dont les utilisateurs ont l'habitude.

Pour offrir à ces utilisateurs la meilleure expérience possible, il convient de profiter des spécificités de chaque OS mobile. On obtiendra ce résultat en développant dans chaque langage de prédilection.

Comment développer la même application en parallèle sur les deux OS ?

Le développement d'applications iPhone et Android ne repose pas sur les mêmes langages ni les mêmes outils. Et pourtant l'application GeneraliAuto a été publiée quasiment en même temps sur l'AppStore et sur l'Android Market grâce à un développement des deux applications en parallèle.

Deux équipes différentes

Les deux applications ont été développées par deux équipes différentes : une équipe Generali accompagnée d'un consultant OCTO pour iPhone et une équipe interne chez OCTO pour Android.

Le premier développement a été réalisé pour iPhone. Son équipe a défini l'application : son ergonomie, ses fonctionnalités, ses graphiques, etc. Elle a également réalisé le service REST de déclaration des sinistres permettant aux deux applications de consommer le même JSON.

L'équipe Android s'est ensuite appuyée sur l'application iPhone pour réaliser son portage vers l'OS mobile de Google. L'application iPhone était donc l'unique modèle de création pour la réalisation de son portage sur Android.

Merci les méthodes agiles

SCRUM a été utilisé pour la réalisation des deux applications mobiles. Outre le fait de voir nos produit se construire petit à petit, cette méthode agile a permis à l'équipe Android de profiter de l'avancement des développements effectués par l'équipe iPhone au fil des itérations. Du fait de la distance entre les deux équipes techniques et du métier, le développement n'était pas facilité.

Dans un premier temps, l'équipe Android s'est appuyée sur des captures d'écrans de l'iPhone mais rapidement ce modèle de développement a atteint ses limites. Le comportement dynamique de l'application n'était en effet pas perceptible. Le meilleur descriptif trouvé et utilisé pour la suite fut une version de démonstration de l'application iPhone de l'itération en cours.

Profitez des spécificités

Au départ, le métier s'attendait à ce que l'application soit identique sur les deux OS. Nous leur avons expliqué qu'il existe des spécificités auxquelles sont habitués les utilisateurs d'Android et qu'il serait intéressant de ne pas faire un portage strict. Les deux applications comportent ainsi les différences suivantes :

• Remplacement du bouton retour de l'entête sur iPhone par le bouton physique "flèche de retour" des téléphones Android
• Même chose pour le bouton recherche de l'entête sur iPhone de certains écrans par le bouton physique "loupe"
• Absence sur Android de "SplashScreen", écran de démarrage des applis iPhone leur permettant de charger les composants
• Ajout d'un menu sur les Android grâce au bouton physique "menu" permettant d'accéder directement à la page d'accueil ou à la recherche selon les écrans

Améliorations possibles

Le besoin de portage de l'application sur la plateforme Android étant survenu durant le développement iPhone, le développement des deux applications n'a pas toujours été optimal. Des améliorations sont possibles tant sur le point technique que sur la méthodologie.

Des similitudes techniques

Si les langages de programmation sont différents, la base de données utilisée par ces deux OS mobiles est la même : SQLite. Il est ainsi possible de mutualiser la génération de la base et de son contenu. Le fichier .db peut ainsi être importé dans les deux applications. Dans cette application, la longue liste des garages agréés issue d'un fichier CSV peut être mise dans une base SQLite pouvant être lue par les deux applications.

Un partage de ressources telles que des fichiers XML, HTML, etc. est souhaitable dès que c'est possible. Dans le cas de cette application, les mentions légales est un fichier HTML réutilisé par les deux applications.

Les images sont également au même format mais il faut bien retenir que les différents mobiles n'ont pas tous les mêmes résolutions. Il faut donc prendre garde à avoir des images adaptées aux plus hautes résolutions comme celle du Nexus One pour Android ou du prochain iPhone 4 sous peine d'avoir des images floues sur ces mobiles. C'est d'ailleurs le souci que nous avons eu sur quelques images de cette application qui paraisse moins nette sur le Nexus One.

Partage du backlog produit

Si les deux équipes techniques sont distinctes, il serait intéressant qu'elles aient accès au même backlog produit. Elles seraient ainsi au courant des changements de fonctionnalités et pourraient également choisir les User Stories pour leurs sprints en fonction de leur vélocité.

L'autre point important serait d'avoir une recette à la fin de chaque sprint des deux applications par la même MOA. De cette façon, les deux équipes auraient des retours de manière continue. L'idéal serait de créer une seule équipe avec des développeurs aux compétences différentes (Android et/ou iPhone) mais avec le même métier, le même Product Owner et le même SCRUM Master.

Ce qu'il faut retenir

• La meilleure description d'un produit est la démonstration du produit en cours de développement. L'observation du produit apporte allègrement plus de valeur qu'une quelconque spécification.
• Profiter des spécificités des OS mobiles pour offrir la meilleure expérience possible à ses utilisateurs.
• Mutualiser du code technique dès que vous pouvez : images, ressources statiques, base de données, etc.
• Deux équipes techniques distinctes mais un même backlog produit avec la même MOA pour faire des recettes à chaque itération.