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 ?
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 :
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.
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.
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.
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.
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 :
 |  |
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.
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.
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.
 |  |