Java pour Android et Swift/Objective-C pour iOS : quelle plateforme permet de développer plus vite ?

Java pour Android et Swift/Objective-C pour iOS : quelle plateforme permet de développer plus vite ?
Infinum penche pour la plateforme d’Apple

Dans l’environnement mobile, Android et iOS se partagent plus de 90 % des parts de marché. Jusqu’en août dernier, IDC enregistrait pour Android 82,8 % de parts de marché contre 13,9 % pour iOS. Windows Phone en avait 2,3 %, BlackBerry OS possédait 0,3 % et le reste disposait de 0,4 %.

En termes d’applications, la même tendance est encore conservée. Statista notait en juillet dernier que Google Play disposait de 1 600 000 applications contre 1 500 000 pour l’Apple Store. Windows Phone Store en avait 340 000 et BlackBerry World 130 000.

C’est donc sans contredit que les développeurs ciblent en grande partie au moins un des systèmes d’exploitation favoris, c’est-à-dire Android ou iOS, sinon les deux plateformes.

Infinum, qui est une startup avec à son actif un grand nombre d’applications web et mobiles conçues pour les plateformes web et mobiles, a voulu savoir quelle plateforme (entre Android et iOS), offre des outils de développement beaucoup plus rentables. Entendez par rentabilité celle qui permet de concevoir une application plus vite et donc de gagner du temps et par-delà faire des économies.

Pour ne pas tirer de conclusions biaisées, Infinum s’est appuyé sur les chiffres issus de ses projets personnels. La première remarque que fait l’entreprise d’emblée est que le développement d’applications mobiles avec Java demande un temps de développement beaucoup plus long qu’une même application développée avec Objective-C ou Swift.

Bien évidemment, avancer de telles allégations sans début d’éléments matériels n’aurait aucun poids pour convaincre. Aussi, Infinum a-t-elle effectué des comparaisons sur la base de six projets qui ont porté sur la conception d’une même application pour ces deux plateformes avec une base de code et des techniques de développement peu contraignantes afin de ne pas fausser les résultats obtenus.

En parcourant ces six projets, Infinum a utilisé comme baromètre les lignes de code et le nombre d’heures de travail générées pour chaque plateforme. Pour obtenir les lignes de code dérivées des six projets servant de base d’évaluation, la startup a utilisé l’application Cloc. Ci-dessous le résultat obtenu.

Pièce jointe 191667

Dans l’ensemble des six projets analysés par Infinum, les codes Java pour les applications Android sont plus longs d’environ 40 % que les codes pour les applications iOS. En s’en tenant à ces données, il est manifeste qu’écrire une même application en Java pour Android semble plus long qu’écrire une application avec Swift ou Objective-C, toutes choses égales par ailleurs.

Pour ce qui concerne le second aspect de l’analyse comparative, Infinum a utilisé l’application Productive afin d’avoir le temps mis pour concevoir ces applications.

Pièce jointe 191668

Les résultats obtenus peuvent être interprétés comme un corolaire du premier point effectué. En effet, dans l’ensemble des six projets, le temps mis pour coder avec iOS est inférieur au temps mis pour coder avec Java. Cela donne une moyenne d’environ 30 % de temps supplémentaires que l’équipe d’Infinum a dû utiliser pour coder les applications Android avec Java par rapport au temps consacré à coder avec Swift ou Objective-C pour les applications iOS.

Infinum précise en outre que son équipe possède les mêmes compétences pour les deux plateformes afin que les résultats inférieurs de Java sur Android ne soient pas imputés aux compétences de son équipe.

Au vu de tous ces éléments, Infinum retient que si elle doit estimer le développement d’un même projet pour Android et iOS, alors que le temps de développement d’une application iOS sera fixé à 500 heures, celle d’Android sera fixée à 650 heures afin de respecter l’écart des 30 % supplémentaires.

Comme raisons avancées pour expliquer cette lenteur au niveau du développement Android, Infinum soutient que Java est un langage beaucoup plus verbeux que Swift ou Objective-C, ce qui pourrait expliquer la longueur des codes. En ce qui concerne le temps de développement qui est plus long, la startup met en avant certains facteurs tels que les émulateurs Android qui sont plus lents ou encore la fragmentation d’Android qui nécessite beaucoup plus de tests sur différents types d’appareils. Cela entraine nécessairement une rallonge temps pour le développement général d’une application Android.

Source : Infinum

Et vous ?

:fleche: Que pensez-vous de ces résultats ? Partagez-vous les mêmes conclusions ?

:fleche: Entre Java et les langages d'Apple, lequel trouvez-vous plus rapide pour développer des applications mobiles ?

Voir aussi

:fleche: Forum Programmation système

c'est surtout avec les émulateurs hyper lents et le fait que si l'on lance directement depuis le PC l'appli sur un terminal Android on à aucun contrôle dessus,
du coup lancer les test sous iOS sont un vrai bonheur mais pour les informations de débogage c'est nettement moins bien

Citation:

---

Envoyé par TiranusKBX

c'est surtout avec les émulateurs hyper lents et le fait que si l'on lance directement depuis le PC l'appli sur un terminal Android on à aucun contrôle dessus

---

Emulateur x86 ou genymotion :)
Les emulateurs arm sont une catastrophe. Qu'est ce que tu appel avoir du controle sur l'application ?

Sinon je pense que pour l'UI l'environnement apple est plus performant , notamment grace à storyboard. Pour le reste j'ai pas vraiment d'avis.

J'ai une chose à dire, Cordova.
En gros, tu divise le temps de développement par le nombre de plateforme que tu vise. Le code et le langage est le même. Tu n'a pas besoin de plusieurs développeurs et simple dev front-end peut faire l'affaire.

Dans la majorité des cas, les applications affiche de simples données et permettent de les éditées. Dolnc c'est dans les cordes de Cordova.

Ps: et avec un peu de chance, si vous faite du node côté serveur, vous n'avez plus qu'un seul langage de A à Z (c'est mon cas =).

Il y a une très mauvaise formulation dans cet article : sur la "rapidité" de développement Android ou iOS, ce n'est pas Java, Objective C ou Swift qui ont une influence mais la plate-forme en elle même. Remplacez Java sur Android par du Swift et Swift ou Objective C par Java sur iOS, je doute d'une grande différence.

Sans avoir fait de pseudo-étude où je met un joli tableau comparant des chiffres avec un en-tête Android et iOS pour appuyer mon propos, sur Android, on a d'abord une grosse perte de temps du fait des outils (même si Android Studio est enfin stabilisé). Ensuite, c'est coté architecture et la perte de temps sur le LOLcycle des fragment. Enfin, tout ce qui est IHM est juste... Affreux...

Bref, oui ceux qui mettent la main sur les deux plate-formes arrivent à la même observation, mais ce n'est pas du fait du langage en lui même.

Je trouve dommage que l'étude ne prenne pas en compte le développement natif..

De mon expérience (développement de moteur de jeu industriel sur IOS et Android entre autres), le développement avec une grosse base de code natif est extrêmement lent et compliqué sur Android. Pas/peu d'outil (visual GDB déconne plein tubes, VS2015 amène un pas en avant), le profiling est une plaie, je ne parle même pas de l'état du debug GPU qui est au mieux aléatoire, la build chain est naze et lente...
Les émulateurs sont lents, ne permettent pas de faire tourner les applications avancées, divergent du comportement sur téléphone...
Pour la partie outil, l'avantage va clairement à IOS (frame capture, instruments, lldb...)

Pour la partie langage, on a observé de gros gros problèmes de performances dus à objC. En particulier les coûts d'accès au structure partagées avec le GPU (développement Metal) qui coûtent juste un bras. On a fini par miror les structures objC en C++ et à utiliser un système de hash pour limiter au maximum les accès ObjC.

Je ne donnerais quand même pas l'avantage à Java pour le coup, vu qu'il ne nous permet pas de faire ce que nous avons besoin (et de toute façon, on fait du multi platforme, du coup c'est C ou C++ au maximum).

Voilà pour my two cents :)

Bonjour,
Ce qui me choque surtout dans cette étude est le projet B. Il détonne complètement par rapport à la moyenne. Alors où il est atypique et devrait écarté, ou au contraire il révèle une approche ou un type de problème que les deux environnement résolvent avec la même efficacité. Java permettant facilement de faire du laid lourd lent, il s'agit peut-être d'une question de méthodologie ou d'approche.
À part ça, plus je vois C++ (11++) et plus je me demande si on a toujours besoin des autres languages...