Discussion :

[Michael Guilloux]

Développement mobile : préférez-vous le développement natif ou multiplateforme ?
Quelles ont été vos expériences dans les deux cas ?

Pour le développement mobile, faut-il utiliser des outils de développement natifs ou multiplateformes ? Du point de vue de la performance et de l'expérience utilisateur, ce sujet ne doit pas faire débat, parce que les applications natives offrent de nombreux avantages. Une application native est en effet développée spécifiquement pour une plateforme et avec un langage qui permet de tirer parti des avantages de la plateforme (par exemple Java pour Android, Objective-C et Swift pour iOS, C# pour Windows Phone).

Une application native peut être un meilleur choix si elle doit avoir accès à l’ensemble des fonctionnalités de l’appareil et du système d’exploitation, étant donné qu’elle peut mieux tirer parti des fonctionnalités du système mobile ciblé et de l’appareil de l’utilisateur. En termes de performance et de vitesse, il ne devrait y avoir aucune limitation particulière avec une application native. Si vous voulez une interface utilisateur fluide et très réactive, une application native fera également l’affaire. L’un des véritables problèmes, c’est le coût de développement, car il va falloir réécrire l’application plusieurs fois si vous devez cibler plusieurs plateformes. Un inconvénient que le développement multiplateforme permet de résoudre.

Les technologies de développement multiplateforme permettent d'écrire le code de base (par exemple en HTML, CSS, JavaScript ou autre langage) et ensuite de l’adapter pour cibler différentes plateformes mobiles. La plus grande partie du code de base pourra être partagée entre les différentes versions de l’application. Mais les contraintes relatives au développement multiplateforme, selon les technologies utilisées, peuvent être nombreuses.

Si vous voulez développer un prototype et lancer une application relativement simple sur plusieurs plateformes rapidement, alors une application multiplateforme serait une bonne option. Surtout si votre application dispose d'une interface utilisateur simple et limite les interactions avec l'utilisateur. Il faut donc avoir à l’esprit que l’application risque de ne pas être en mesure d’interagir avec tous les composants matériels du dispositif, comme la caméra et le microphone. Le développement multiplateforme peut également ne pas être un choix à faire si votre application doit traiter des données complexes ou utiliser l'audio ou la vidéo.

Le développement natif est idéal pour des applications qui doivent tirer parti de certaines fonctionnalités de la plateforme ciblée. Il faut toutefois noter que tous les projets n’ont pas les mêmes contraintes et avec des technologies comme Xamarin (qui permet aux développeurs d’utiliser C# pour créer des applications natives pour Android, iOS et Windows), un nombre croissant de développeurs s’adonne au développement multiplateforme. Encore faut-il choisir les bons outils et savoir comment les utiliser.

Et vous ?

Pour le développement mobile, préférez-vous le développement natif ou multiplateforme ? Pourquoi ?
Quelles ont été vos expériences dans les deux cas ? Quelles technologies avez-vous utilisées ?

[Cryde]

J'utilise Appcelerator (permet de dev des app en JS) depuis 2 ans et c'est vraiment intéressant.
Ils sont un peu à la bourre niveau ES6 mais ils essaient d'aller de l'avant !

Sinon ils ont sorti Hyperloop qui permet d’accéder au API native via le JS.

[estacado]

C'est dommage de ne pas parler de Cordova, en évoquant le crossplateform natif / non natif.
D'autant plus que les personnes habituées à faire du dev web sur des technos comme AngularJS, il est très simple de faire des application avec Cordova qui vont couvrir 80% des besoins et très maintenable dans le temps.

Pour les 20% restant, il sera nécessaire de passer sur du natif pour des questions de performances principalement.

[youtpout978]

Oui c'est dommage de ne pas faire la différenciation entre app multiplateforme générant du code natif et les autres qui sont simplement des apps web s'exécutant dans le navigateur du mobile.
Sachant qu'on peut coder en JS et générer du natif (Telerik) ...

[seeme]

Toujours fait 99% du développement en C++.
Il y a des avantages et des inconvénients et c'est très lié au produit.

[Gugelhupf]

J'ai un peu fait des deux, Android pour le natif et Ionic pour le multiplateforme (JS/Typescript).

Ce qui m'a marqué est que j'ai eu plus de facilités avec le natif, ça a été beaucoup plus rapide à prendre en main, en gros je lis la doc, je code, je vois mes erreurs avant la phase de compilation, et j'ai un résultat correct assez rapidement. Avec le multiplateforme, je lis la doc, je code, j’inclue certaines libs et je ne comprends pas forcément pourquoi Cordova ne fonctionne pas, aussi je ne vois pas tous mes erreurs avant la compilation (ou en mode watch), l'IDE ne détecte pas certaines syntaxes et le compilateur non plus, on se rend compte assez vite que ces outils, en plus d'être limités (du au fait qu'ils sont adaptés pour plusieurs systèmes), ne sont pas suffisamment matures.

Le multiplateforme c'est un peu le rêve absolu, mais je trouve la phase de développement assez frustrante.

[landry161]

l'IDE ne détecte pas certaines syntaxes et le compilateur non plus

Ouais sauf le navigateur qui t affichera rien à moins que tu fasses une inspection.

[landry161]

L article l a si bien dit le multiplatforme c est un code écrit pour plusieurs plateformes. Apres pour ce qui est du choix, je pense que cela dépendra du la nature du projet et des différentes fonctionnalités à implémenter.

[Invité]

Le dev natif, sans hésiter.
Je suis dev Android, donc habitué au Java et le sdk Android.
J'ai pu tester 2 technos ces derniers mois, robovm (un jeu dev avec libgdx, pour gwt, android, ios, desktop), et React native (android, ios).

libGDX (robovm)
Le premier constat que je fais, c'est que le code "générique" et rapide à mettre en oeuvre. La partie "core" a été relativement facile à coder. Nous souhaitions intégrer AdMob et Google Game Services pour IOS et Android. Finalement, seul Android a un leaderboard, mais les deux plateformes disposent d'une intégration AdMob.

Ce qui nous a posé problème, c'est le code spécifique IOS. Là, ça ne sert plus à grand chose de connaitre java... On fait bien du java, mais dans un contexte IOS, donc si vous ne connaissez pas vous allez perdre un temps fou (et de l'argent...) pour essayer d'intégrer des librairies pour lesquelles il existe plusieurs versions de binding, certaines ne link pas le projet, d'autre link mais plante l'executable à cause de référence inconnue (hello GADRequest et NSObject). Du coup, pour être productif, je pense qu'il est malgré tout indispensable de bien connaitre le fonctionnement des plateformes, être sûre que la communauté derrière est là pour vous aider (chez vous, vous avez peut être toute la vie pour attendre des réponses, pas toujours en entreprise). Finalement, seule la version Android va finir sur le store pour le moment. En plus, j'ai eu un problème bizarre, genre le garbage collector qui mange TOUT sur IOS. Surtout les pauvres petits callbacks que je passe au core du projet pour afficher les ads et que je ne veux pas passer en "static" comme un cochon.

Et là il s'agit d'un jeu, donc tout ca passe principalement par libGDX. Mais quand est-il du développement d'applications "classique" sans libgdx, avec des ListView, des boutons etc ? J'aimerais bien avoir le retour de quelqu'un qui a pu s'y essayer. Gain de temps, ou perte d'argent?


React native
Là, c'est différent. On ne fait plus du tout de java, mais du React (enfin, je crois). Un mélange de Javascript et de JSX si j'ai bien compris. Cela peut paraître bizarre les premières heures, mais c'est plutôt sympa par la suite. Un gros problème que j'ai eu, c'est de trouver un bon IDE pour coder. Je m'en sors plutôt pas mal avec vscode, mais atom (avec plugin nuclide) est pas mal aussi, si vous visez IOS. Pour Android, il faut repasser un autre jour pour pouvoir débugger correctement. Cela ne fonctionne que partiellement (c'est écrit dans la doc), et pourtant j'y ai passé plusieurs heures (même à la maison, mais l'OS et la config sont différentes dont bon...).

Donc là c'est du Javascript (ECMAscript 6), plutôt facile à prendre en main. Le code générique, une fois le fonctionnement de React assimilé est plutôt rapide à écrire. Pour le code spécifique à chaque plateforme, c'est plus ou moins le même problème que libgdx et robovm (je cite libgdx mais il s'agit juste d'un framework...). Si vous devez utiliser du code natif "à vous" ou celui d'un autre et que le binding n'existe pas, vous allez devoir le faire vous même, et donc connaître ObjectiveC et Java pour vous interfacer avec le JS.

Un autre problème, c'est qu'en utilisant du code "all-in-one", on perd souvent certaines "spécificités" des systèmes. Par exemple, sur android, la TabBar, le CoordinatorLayout ? Avec React, il n'y a pas ces composants natif. Je ne suis pas adepte des applications Android qui sont semblables aux versions IOS comme deux gouttes d'eau. Pour les clients, c'est souvent quelque chose d'important, mais je pense aussi que ce n'est pas bon pour l'écosystème des applications et les habitués de chaque système, mais je sort un peu du sujet là.

Cependant il faut y penser. Vous utilisez "Navigator", et "NavigatorIOS", bien, maintenant, vous risquez de finir avec des if android /else ios, ou bien vous allez une fois de plus écrire ou chercher des binding en fonction de ce que vous voulez (et l'heure tourne). J'imagine que cela doit être pris en compte avant de lancer le projet, mais combien ce sont fais piéger, ou n'ont pas eu le choix ?

Pour conclure, le dev cross plateforme semble intéressant à priori, mais il faut faire attention. Sans experience dans les outils utilisés c'est un parie risqué. Pour faire des applications simple cela ne doit pas poser trop de problèmes, même sans connaitre en details le fonctionnement des plateformes pour lesquels le projet sera réalisé, mais pour des applications plus poussées, il faut faire attention. Vous pouvez me dire que l'appli Facebook EST poussée et que c'est un bon exemple, oui mais Facebook est aussi derrière React native, donc ca ne compte pas Et puis je n'ai pas d'autres exemple, là, comme ca.

[Moltroon]

Personnellement j'utilise Xamarin.Forms car il est le seul à réellement faire du natif sur Windows ET IOS en même temps. Le soucis c'est que les applications sont complexe et qu'il arrive souvent qu'il y ai des problème de compatibilité entre les OS et Xamarin (merci iOS et xCode 8). De plus, le réel problème et que Xamarin nous montre chaque jour que nous sommes dépendant de lui et des bibliothèques des autres utilisateurs. Un outil complexe et puissant mais qui va encore demander du temps avant de devenir réellement mature.

[kilroyFR]

Natif definitivement (C++ principalement). L'avantage en connaissant un seul langage de ne devoir s'adapter qu'au framework associé mais en conservant les habitudes de programmation habituelle.

Les dev "multiplateformes" (type Xamarin) je m'en suis rapidement eloigné apres avoir pratiqué.
Pour des trucs super simples ca peut passer par contre pour des applis pro ca devient d'une complexité sans nom (voir xamarin - une appli qui ne fait pas grand chose pese tout de suite 50 Mo - la quantité de libs java embarquées est surrealiste). Tu passes plus de temps a essayer de comprendre pourquoi ca marche pas que de coder ce que tu as a faire (bref trop de temps passé dans la mecanique inutile).

[sjordi]

Le cross-platform natif...
Avec Delphi ou C++Builder. Du vrai code, compilé au niveau du processeurs, donc même Android passe outre les horribles couches java et autres consommateurs de ressources.

[gbegreg]

Bonjour,

Comme sjordi, j'utilise Delphi. Certes, les binaires sont plus gros mais c'est la simplicité. Dans une solution, j'ai un module pour tablettes et smartphones. Le client est passé de tablettes à la pomme à des tablettes Android : j'ai juste recompilé le module (aucune modification nécessaire). Je n'utilise pas de fonctionnalités trop liées à l'OS mais le capteur photo, le module GPS et Wifi. J'apprécie également la fonctionnalité FireUI du concepteur d'interface graphique qui est pratique et qui permet d'adapter et prévisualiser en direct ce que ça va rendre (que la cible soit une application bureau, une tablette 10", un smartphone 5" ou encore une montre connectée par exemple).

[Carmichael]

Bonjour,

Personnellement, j'utilise Embarcadero C++ Builder qui me permet de générer un seul code et 4 cibles principales (Windows, Mac-OS, Android et IOS). L'an prochaine, on passera à 5 avec l'ajout de Linux (en mode texte seulement).

Les avantages :
- Un seul code.
- Le langage C++
- Des outils simples permettant de ne pas avoir à tenir compte des résolutions d'écran des différents devices.
- Un vrai binaire ou package par OS.

Les inconvénients :
- Pour des opérations spécifique à un OS, il faut créer une condition "Si OS = Android alors..."
Exemple : la fonction Close() n'est pas autorisée d'emploi sous IOS, alors qu'elle l'est sous les autres OS.

Cordialement

Carmichael

[Kikuts]

J'utilise Xamarin Forms pour le multi platforme natif depuis 2 ans.

C'était très laborieux au début. Maintenant que j'ai mon framework perso que je connais mieux ce qui fonctionne ou pas, je dois dire que j'aime énormément.
Mais il faut beaucoup investir en temps, recréer des composants / comportement soit même.

J'ai travaillé avec de nombreux dév iOS et Android (purement natif).
Et bien je peux facilement dire que de façon général, le code XForms était bien plus cohérant, lisible et compréhensible.

Une fois qu'on maitrise le proces de publication d'apk/ipa, qu'on a fait plusieurs appli XForms, je vous assure qu'on est à l'aise.
Et on ne le dit pas assez mais XForms supporte aussi les Universal App dans la quasi intégralité (il n'y a que le composant Map que je n'ai pas réussi à faire fonctionner de XForms à Universal App) et pas seulement Android et iOS.

Pour terminer, Xamarin est maintenant un produit Microsoft, un produit Open Source. Du coup je pense qu'il va encore s'améliorer énormément.

[Battant]

Bonjour,

Selon une information que j'ai trouvé sur le site de Ubuntu touch, seuls les applications multiplates formes HTML 5 ou Qml Fonctionne avec cette plate-forme . Le développement d'applications multiplates formes me semble privilégier mais je reconnais que dans certains cas cela n'est techniquement pas possible .
Donc il faut faire une analyse bien poussé avons le développement d'une application station que pour l'instant Des systèmes d'exploitation peu connu ne pourront certainement pas faire tourner votre application. Cela peut également posé un problème le jour où l'utilisateur veux changer de système Un développement non multiplates formes n'est aussi pas bon pour la visibilité du système plus connus .

Que pensez-vous ?

Meilleures salutations

[qdaemon_fr]

Bonjour

Personne n'a d'expérience avec Qt ?
Je vais devoir choisir une techno et j'ai besoin d'accéder aux données bluetooth 4.
Aujourd'hui, j'ai une app android à 90 % terminée et et je dois faire une version iOS.

D'un coté, je suis très intéressé pour apprendre le dev iOS natif, un bouquin sur swift m'a
fait penser que ça pourrait être un langage sympa à l'usage mais partant de 0 en macOS,
en swift et en cocoa, le ticket d'entrée n'est pas nul et l'ide me semble un peu, comment dire ?,
disons cabalistique.... surtout vs la tuerie qu'est android studio.
L'autre inconvénient, c'est évidemment que toute fonction nouvelle devra être implémentée
deux fois.

D'un autre coté, j'ai déjà une expérience Qt pour du dev desktop. (en 4.8). J'avais mis de
coté cette possibilité à ce moment là pour deux raisons : il n'y avait pas de classes pour l'accès à
BT4 et à ce moment là, il ne suffisait pas de faire "clic" et tout marche, il y avait du travail
en configuration et en déploiement.
J'ai, il y a qq semaines installé la version de Qt courante et beaucoup de choses ont bien changées.
Cela semble bien plus abouti mais je n'ai pas creusé plus d'une journée.

Le pb, c'est que c'est bien sûr un choix très engageant donc si qqun a une expérience significative
et dev, déploiement, maintenance vs les nouvelles versions de os et idéalement utilisation de BT4,
j'en suis preneur.

Merci
Henri

[jdddeschamps]

Je rejoins un peu kilroyFR et moltroon : xamarin est laborieux :
- problèmes de compilation
- problèmes d'émulation
- problèmes avec VS
Cependant, je continue à m'investir sur xamarin.forms en espérant coder une seule fois pour 3 OS voir plus à l'avenir.

[maritime]

Bonjour,
j'ai découvert XOJO pour ne pas aller au VB.net, seule issue imposée par microsoft aux nombreux utilisateurs du défunt VB6 !
XOJO est entièrement POO , la syntaxe très proche de Vb tout étant multi plate forme (Win,Mac,Linux) 32 et 64 bits,console, développement web, iOS, raspberry Pi2.
Le seule inconvénient, il est avare en controls comparé a Vb6, d'où l'achat de plug in !

[youtpout978]

J'utilise Xamarin Forms pour le multi platforme natif depuis 2 ans.

C'était très laborieux au début. Maintenant que j'ai mon framework perso que je connais mieux ce qui fonctionne ou pas, je dois dire que j'aime énormément.
Mais il faut beaucoup investir en temps, recréer des composants / comportement soit même.

ton framework tu l'as mis à disposition sur un github par hasard ?