Les développeurs d’applications iOS ont toujours du mal à se débarrasser de leurs préjugés à l’encontre d’Android et du Play Store. Pourtant, Google a réalisé un travail considérable pour améliorer son système d’exploitation et sa boutique d’applications.

Les nouveaux outils de développement de la firme de Mountain View sont-ils à la hauteur de Xcode ? Les problèmes de performances se sont-ils envolés à la faveur de l’optimisation de la machine virtuelle Dalvik et de l’augmentation de la puissance ? Le ralentissement du cycle de développement d’Android a-t-il eu l’effet escompté sur la fragmentation ? La boutique du chantre du tout gratuit qu’est Google assure-t-elle aux développeurs les moyens de leur subsistance ?

Ce sont quelques-unes des questions que nous avons posées à Raphael Sebbe, Thomas Castel, Thomas Ricouard, Andy Damevin et Pierre Abi-aad, cinq développeurs d’applications iOS qui se sont récemment mis à Android.

Une adaptation forcément difficile

Les bons développeurs n’ont jamais de grosses difficultés à passer d’un langage à un autre — c’est d’autant moins le cas que celui utilisé par Android, Java, est un classique des écoles d’informatique et l’un des plus utilisés en entreprise. « J’ai déjà eu l’occasion de faire du Java dans une carrière précédente », dit ainsi Raphael Sebbe, co-fondateur et CEO de Creaceed. « La réflexion et la mécanique restent les mêmes », complète Pierre Abi-aad, développeur chez Supergazol : « mais certaines subtilités peuvent freiner. »

Java « un langage plus moderne que l’Objective-C sur certains aspects (generics, namespace, absence de headers) », explique Raphael Sebbe, « mais assez archaïque sur d’autres (pas de blocs/GCD, multithreading laborieux, accès au code natif compliqué) ». Thomas Castel, co-fondateur de 1Button, est moins mesuré :

Je ne suis pas trop fan de ce langage, qui est un peu trop haut niveau pour des logiciels censés tourner sur des appareils mobiles [NdR : Notre propre développeur cite l’exemple de la gestion de la mémoire : le « ramasse-miettes » de Java pose de très clairs problèmes de performances à Android.] […] Pour moi, le Java c’est les applets moches sur les sites web des années 90 et les logiciels des banques. Les choix faits par Google sont très discutables et la quantité de code nécessaire pour faire « la même chose » que sur iOS est plus importante.

Il touche là à un autre aspect, celui de l’apprentissage des pratiques et API spécifiques à chaque plateforme, qui demande un investissement conséquent. « Il existe tout autant de conventions que pour le développement sous iOS », explique le co-fondateur de Creaceed — mais des conventions différentes, qui impliquent un travail particulier pour répondre aux attentes des utilisateurs habitués aux idiosyncrasies d’Android.

On sent très vite que Google a mis l’accent sur le dialogue entre les applications, un aspect qui manque cruellement à iOS. Par exemple, n’importe quelle application qui le souhaite peut devenir le navigateur par défaut. Il y a moins de contraintes, et donc plus de responsabilités pour le développeur, comme la gestion de l’exécution en arrière-plan ou de l’accès aux données de l’utilisateur. […] Mais par rapport à l’iPhone, il y a un gros manque du côté des APIs liées à l’ergonomie, aux animations, aux interactions et au multimédia. Android compense partiellement en offrant un accès plus direct aux couches les plus basses du système… mais cela fait encore du travail pour le développeur, qui doit réimplémenter ce qui manque.

Pierre Abi-aad confirme : « c’est une vraie galère de faire de simples animations. » Les API sont aussi très différentes, dans l’esprit comme dans la forme. Thomas Ricouard, qui travaille désormais sur MySeeen après un passage chez Sage et Google, donne un exemple :

La manière de construire une liste d’éléments (UITableView sur iOS et ListView sur Android) n’a rien à voir. Dans les deux cas, on crée des cellules que l’on peut réutiliser, mais les similitudes s’arrêtent là. Et ce n’est qu’un exemple parmi d’autres. Il faut oublier toutes ses habitudes de développement iOS pour en apprendre de nouvelles lorsqu’on débarque sur Android.

Ces éléments structurants d’Android sont à la fois un problème et une chance :

C’est un cauchemar de trouver de bonnes librairies open source pour nous simplifier la vie sous Android. À de maintes reprises, j’ai dû faire moi-même des modifications dans certaines librairies pour fixer des bogues ou ajouter des fonctions. Beaucoup de développeurs ont publié de bonnes librairies pour ne plus les maintenir par la suite. Ou encore, j’ai trouvé pas mal de code sans documentation. Un beau cauchemar quand on vient du monde iOS. 

Mais dans le même temps, un grand nombre d’APIs sont proposées aux développeurs. On a accès à vraiment beaucoup de choses. Il y a matière à faire des applications exclusives à Android, qui ne pourraient pas voir le jour sur iOS parce qu’il est plus fermé.

La transition n’est donc pas évidente, mais elle n’est pas hors de la portée d’un développeur compétent : Thomas Ricouard estime qu’« en 2 ou 3 semaines, on peut déjà se sentir à l’aise ». Reste qu’il faut aussi changer d’outils de développement, ce qui ne facilite pas la tâche.

Des outils de développement améliorés

« C’est assez compliqué de changer des habitudes que l’on a développées pendant des années », admet Raphael Sebbe : « la première chose que j’ai faite a été de reproduire tous les raccourcis clavier de Xcode dans Android Studio ». Android Studio est le nouvel environnement de développement intégré de Google, mais jusqu’à l’été dernier, les développeurs devaient passer par Eclipse et un plug-in spécifique à Android.

« Avant ce changement, développer pour Android était une vraie corvée », explique Thomas Ricouard : « Eclipse est lent, moche, très mal optimisé… et pas du tout “intégré” en fait. […] Xcode a pas mal de défauts, mais comparé à Eclipse c’est un vrai bonheur. » Le co-fondateur de Creaceed confirme : « Eclipse est un outil généraliste très peu adapté au développement pour Android […]. Il est très loin de l’approche de Xcode ou de Visual Studio. » Thomas Castel est la seule voix discordante : « J’ai téléchargé Android Studio. Je l’ai effacé et j’ai repris Eclipse qui est moins pire. »

Ses collègues s’accordent pourtant à dire qu’Android Studio est, de manière générale, une IDE de bonne facture. « Android Studio est une version modifiée […] du très bon IntelliJ Idea de JetBrains », explique le développeur de MySeeen ; « JetBrains est une société spécialisée dans les IDE et cela se voit », ajoute celui de Creaceed : « Android Studio est encore en bêta et instable, mais les outils de refactoring et d’analyse du code sont plutôt en avance par rapport à ceux de Xcode. » Il poursuit :

Le renommage d’une classe ou d’une variable, l’importation automatique de packages Java lors de la première utilisation d’une classe, la complétion, tout cela marche du premier coup et semble robuste. Des fonctions dont on rêve et qu’on demande à Apple depuis des années sont là, dans la bêta, et fonctionnent très bien. On retrouve d’ailleurs certaines de ces fonctions dans AppCode (un concurrent de Xcode), ce qui prouve la très grande maîtrise de JetBrains dans les IDEs.

Android Studio est très personnalisable, peut-être trop, son interface n’est pas toujours très logique, et il souffre de problèmes d’ergonomie et d’affichage. Il y a aussi des lenteurs, lors de la compilation d’un projet par exemple.

Thomas Ricouard est sur la même longueur d’onde :

Android Studio est vraiment génial, j’ai pas mal de plaisir à développer pour Android maintenant, l’IDE est très très performant, et les fonctionnalités sont au rendez-vous. Cet outil est dédié à Android, conçu par Google. L’éditeur de layout est très puissant, et si dans Eclipse éditer ses vues depuis l’éditeur graphique était laborieux, Android Studio a rendu la chose simple et efficace.

Même s’il est encore en version bêta, je l’utilise déjà pour faire des applications en production. Je recommande à tous les développeurs encore sous Eclipse de vite passer à Android Studio !

Android Studio est-il pour autant à la hauteur de Xcode ? « Je dirais qu’ils sont maintenant très proches en matière de performances et de fonctions », répond le développeur de MySeeen. Raphael Sebbe va plus loin :

Je pense que Google tient le bon bout, et pourrait assez rapidement proposer un environnement de développement plus productif que celui d’Apple. C’est dans tous les cas bon pour la concurrence, et cela poussera Apple à avancer. Xcode reste un très bon IDE cependant (depuis la version 5), mais Apple ne doit pas oublier la productivité/flexibilité dans les versions futures. C’est tellement invraisemblable de ne pas pouvoir faire de frameworks (même statiques) sous iOS en 2014, alors que la majorité des applications sont construites en assemblant des librairies tierces. C’est parfois extrêmement frustrant de constater, version après version, qu’Apple refuse d’ajouter des fonctions tellement évidentes pour tous les développeurs. Je commence à voir sur Twitter des développeurs qui ouvrent leur projet Xcode avec AppCode pour réaliser des opérations que Xcode ne fait pas bien.

Thomas Ricouard admet toutefois qu’il est « toujours plus confortable de travailler avec Xcode » : « l’émulateur fourni [par Google] n’est pas du tout performant » « Le plus gros problème, c’est l’émulateur », confirme Thomas Castel : « il rame. Il est inutilisable sur un Macbook Pro Retina avec 16 Go de RAM, c’est un comble. » Pierre Abi-aad en ajoute une couche : « l’émulateur de base est tellllleeeemmmeeennnt lent. » Il faut parfois attendre plusieurs minutes qu’il se lance, et il peut mettre plusieurs secondes à réagir à une interaction. Lorsque l’on connaît la fluidité du simulateur iOS, cela fait un choc.

Mais rien n’empêche d’installer un autre émulateur — celui de la start-up lyonnaise GenyMotion fait l’unanimité : « je me suis tourné vers GenyMotion », « heureusement qu’il existe des émulateurs alternatifs comme ceux de Genymotion », « il faut absolument utiliser GennyMotion » disent les développeurs. Si les outils de développement de Google ont bien progressé, ils ont encore du retard à rattraper et l’offre d’Apple reste pour le moment plus cohérente et plus intégrée. « Là où Apple fournit un package comprenant tous les outils nécessaires au développement iOS, côté Android c’est la pêche , résume le développeur de Supergazol.

Une fragmentation toujours présente

Mais le principal problème d’Android, du moins celui qui résonne le plus auprès du grand public, c’est celui de sa fragmentation supposée ou réelle. Thomas Ricouard se plaint de devoir passer « bien plus de temps à déboguer et tester sur Android que sur iOS » : « sur Android, il y a beaucoup trop de tailles d’écran à tester, beaucoup trop de versions du système et de configurations. » Peut-être parce qu’il travaille sur des applications différentes, Raphael Sebbe récuse l’argument selon lequel les différentes tailles d’écran seraient aujourd’hui un problème :

Google est très vite parti sur une approche “layout”, qui fait qu’une interface se redimensionne en fonction de l’appareil. C’est d’ailleurs ce qui permet de faire tourner des applications smartphone sur tablette, ce qu’Apple ne manque pas de rappeler dans sa communication autour de l’iPad.

Apple se base sur une taille fixe d’écran, mais a développé en parallèle des techniques similaires de mise à l’échelle du contenu (autolayout), que l’on retrouve sur Mac et qui sont sans doute encore plus puissantes que celles de Google.

Cette différence quasi philosophique d’approche oppose les développeurs : alors que Thomas Castel n’a pas de mots assez durs pour exprimer son rejet des outils fournis par Google sur ce plan, Pierre Abi-aad trouve au contraire que le système de « layouts » est « efficace et très simple ».

Tous s’accordent cependant pour dire que la véritable fragmentation est plutôt à chercher dans la multiplicité des versions d’Android. Le développeur de MySeeen pointe du doigt la possibilité qu’un même appareil soit proposé avec deux versions différentes du système, qui auront deux comportements différents :

L’application peut avoir un comportement différent sur un Galaxy S4 avec la version d’Android personnalisée par Samsung et sur un Galaxy S4 avec la version d’Android “de base”. [Le processus de test] est très long et très laborieux, vous pouvez être sûr que les premières versions publiques de votre application comporteront des bogues sur certains terminaux si vous n’avez pas assez de modèles de test. 

Même si Google a ralenti le cycle de développement d’Android et introduit moins de ruptures, beaucoup d’appareils sont toujours vendus avec des versions anciennes qui ne prennent pas en charge certaines APIs très utiles. Raphael Sebbe est confronté à ce problème avec les applications de Creaceed :

Nous sommes plus dans les applications multimédia, et on remarque qu’il est très difficile de supporter les anciens appareils, car Google n’a introduit des fonctions multimédia que relativement récemment dans son SDK. Pire, des anciens appareils qui normalement ne prennent pas en charge Android 4.4 KitKat peuvent tout de même y avoir droit par le biais de builds non officielles (comme Cyanogen Mod 11), avec de gros problèmes à la clef. Par exemple, le module d’encodage vidéo ne fonctionne pas sur certains appareils. Pour un développeur, c’est un peu une catastrophe, puisqu’il ne peut pas garantir que son application fonctionne dans tous les cas, même en imposant une version minimale.

Ce problème est moins prégnant sur iOS, puisqu’un appareil comme l’iPhone 4, lancé il y a bientôt quatre ans, peut toujours bénéficier de la dernière version du système et donc des dernières APIs. Mais rien ne garantit que les utilisateurs tiennent leurs appareils à jour : « dans ma vie de développeur iOS, je suis parfois frustré de ne pas pouvoir utiliser telle ou telle API » explique Pierre Abi-aad, «  parce que l’application doit rester compatible avec une version antérieure. De iOS 6 à iOS 7, c’est déjà contraignant, alors pour Android… »

Le premier système, mais pas le premier marché

Ce défi de la fragmentation pose problème dans la commercialisation des applications : « dans ce contexte, il est difficile de proposer des applications payantes », s’exclame Raphael Sebbe : « achetez, et dites-moi si ça marche ! ». « La fragmentation rend (très) difficile la mise en place d’un business model payant : le freemium, qui permet de tester avant de véritablement acheter et l’adware risque de rester la norme pendant longtemps », poursuit-il. Et comme Google a tout intérêt à placer ses publicités dans des applications…

La médaille de l’ouverture d’Android a aussi son revers, celui du piratage, qui sévit de manière endémique. Les applications les plus en vue sont souvent clonées, repackagées, placardées de publicités, parfois bourrées de malwares, puis distribuées dans une boutique sur laquelle Google n’exerce qu’un contrôle très relatif. Même si les outils de recherche de la firme de Mountain View sont de bien meilleure qualité que ceux d’Apple, même les utilisateurs les plus aguerris peuvent se faire piéger. Et les développeurs ont donc parfois des réticences à mettre le pied dans cette véritable jungle.

Tout n’est cependant pas noir : Thomas Ricouard insiste particulièrement sur la politique proactive de Google à l’encontre des développeurs, là où Apple est plus en dedans. « Franchement, la différence vient surtout du fait qu’on peut publier presque instantanément son application », explique-t-il : et « il n’y a pas besoin de payer une licence annuelle à 79 €. » « Les outils de suivi statistique de Google sont aussi bien meilleurs, il n’y a pas photo par rapport à iTunes Connect. Sur ce point, Apple est très en retard. »

Andy Damevin, co-fondateur de Wazam, confirme et complète :

La soumission et la mise à jour sont simplifiées par le fait que l’on ait le choix entre trois stades de livraison d’une application : alpha, bêta et production. Les testeurs sont directement avertis par Google Play de la disponibilité d’une mise à jour, à tous les stades de livraison et selon les droits de chacun. Chez Apple, la gestion des versions de test est un vrai casse-tête : il n’est pas possible de passer par l’App Store et d’autoriser certains utilisateurs à tester l’application. Il faut créer un exécutable à envoyer par mail ou à déposer sur un serveur, et les testeurs doivent au préalable communiquer l’UDID de leur appareil pour être autorisés lors de la signature de l’exécutable.

Sur Android, les notes persistent d’une version à l’autre, ce qui encourage les mises à jour et les nouvelles fonctions. Sur iOS, chaque version remet les compteurs à zéro, il vaut donc mieux espacer les mises à jour […]. Il est possible de répondre aux commentaires sur le Play Store et ainsi d’expliquer un bogue ou de justifier un comportement qui n’a pas plu à l’utilisateur et provoqué une mauvaise note.

Les statistiques sont très poussées et peuvent même être connectées à Google Analytics, alors qu’elles sont très basiques sur l’App Store (courbes de téléchargements et de mises à jour). Mais dans un cas comme dans l’autre, on n’a aucune information sur la provenance des utilisateurs : il serait très pratique pour les développeurs de connaître les mots-clefs qui fonctionnent ou le site qui a envoyé des gens télécharger l’application.

Apple est un peu moins accueillante mais l’App Store est plus rentable, le piratage est un vrai phénomène sur le Play Store mais les algorithmes de recherche d’Apple sont déplorables : là encore, les avantages et les inconvénients de chaque plateforme semblent s’annuler. Le fait est que développer pour Android en venant du monde iOS n’est plus un casse-tête. Mais ce n’est pas facile non plus, comme le résume le co-fondateur de Creaceed, qui aura le mot de la fin : « il est difficile de maîtriser ces deux plateformes à la fois. Il est probablement mieux de disposer de deux équipes spécialisées. Ce qui a un coût. »