C’est la question qui revient souvent : faut-il développer une application spécifique à une plateforme mobile, ou une WebApp disponible sur toutes les plateformes ? Dans le cadre de notre série de billets sur le thème de la mobilité, nous revenons sur les différences entre applications natives et WebApps.
WebApp VS Application native
Application native
L’application native est un logiciel développé spécifiquement pour le système d’exploitation de votre mobile. Une fois téléchargée, vous pouvez utiliser l’application avec des informations en ligne ou hors-ligne. Une application permet d’utiliser les éléments techniques et graphiques intégrés au périphérique (appareil photo, GPS, notifications push, etc…).
Les applications, suivant leur plateforme sont disponibles sur :
– l’AppStore chez Apple,
– l’Android Market chez Google,
– le BlackBerry App World chez RIM,
– le Windows Marketplace chez Microsoft.
WebApp (Application mobile Web)
La WebApp est, quant à elle, plutôt un site Web développé et mis en forme spécifiquement pour les mobiles. Ce mode de développement ne permet pas de tirer partie des fonctionnalités offertes par le système d’exploitation du mobile. Une WebApp se consulte directement depuis le navigateur Internet du mobile et nécessite donc une connexion internet pour pouvoir être chargée.
Tout comme les applications et leur store, on trouve en quelque sorte des annuaires de WebApps :
– Apple : http://www.apple.com/webapps/
– Microsoft : http://www.microsoft.com/web/gallery/
Quelques points de comparaison :
| | Application native | WebApp |
| Portabilité | Développement spécifique à chaque plateforme | Navigateur Web |
| Développement/coût | Nécessite un SDK + connaissance d’un langage spécifique | Langage Web (HTML / JS / CSS / PHP / …) |
| Mises à jour | Soumission à un magasin d’applications et éventuelle validation | Mise à jour rapide en mettant à jour tout simplement les fichiers sur le serveur Web |
| Disponibilité | Mode online et offline | Nécessite obligatoirement une connexion Internet. Mode offline presque possible si HTML5 |
| Fonctionnalités | Utilise toutes les fonctionnalités du mobile (GPS, voix, notifications, contacts…) | Limités aux possibilités du navigateur |
Autre solution : Application + WebApp
On peut donc voir que chaque solution a ses avantages et ses inconvénients. Il existe cependant une 3ème solution au développement mobile. En effet, il est possible de développer une WebApp encapsulée dans une application native.
Mise en place
Vous pouvez donc créer une application qui lance le navigateur du téléphone et qui charge une WebApp. Lors de la déclaration du « conteneur Web », vous pouvez cacher la barre d’adresse et la barre de navigation du navigateur pour que celui-ci soit en plein écran.
Bien évidemment, une connexion Internet sera nécessaire pour utiliser votre application. Il faudra donc faire quelques vérifications pour tester si la connexion Internet est active (quelques lignes de code). Ceci est nécessaire car Apple, par exemple, ne valide pas les applications qui ont besoin d’une connexion et qui ne font pas ce genre de test !
L’avantage de cette solution est le peu de code à mettre en place pour développer une application native à chaque plateforme. Il faut mettre en place :
– un splash screen visible au lancement de l’application pendant le chargement de la WebApp
– le code de vérification de la connexion Internet
– le « conteneur Web » qui va charger la WebApp
Fonctionnalités
Pour chaque plateforme, vous pouvez avoir un design différent en passant un paramètre à la WebApp pour que celle-ci charge une feuille de style spécifique. Ce paramètre peut être une varible, un header spécifique, etc… Grâce à celui-ci, vous pouvez également charger des contenus différents, voire même des fonctionnalités différentes.
La gestion des différentes résolutions est possible en faisant quelques tests. Ceci vous permet de charger ou non des images hautes résolution pour des smartphones comme l’iPhone 4, le HTC Désire ou le Samsung Galaxy S.
Avec Javascript, vous pouvez lancer des fonctions lors de la mise en veille ou le réveil de votre application. Par exemple, une fonction est déclenchée pour rafraichir la page en cours lorsque vous revennez dans votre application. Sur Android, la gestion du fameux bouton retour présent sur chaque téléphone de cette plateforme est possible.
Protection
Si vous le souhaitez, vous pouvez protéger votre WebApp pour que celle-ci ne soit visible qu’à travers votre application. Ceci peut-être nécessaire si vous souhaitez rendre payante votre application.
Voici quelques solutions :
– un paramètre peut être passé à la WebApp pour que celle-ci charge les contenus mais ce paramètre est facilement détectable par les utilisateurs avancés.
– à partir de votre application native, vous pouvez charger un fichier Javascript dans la WebApp puis lancer une fonction Javascript qui permet le chargement complet de votre WebApp.
Mises à jour
Les mises à jour mineures et/ou corrections de bug peuvent être faites directement en mettant à jour les fichiers sur le serveur.
Pour les grosses mises à jour et/ou ajouts de fonctionnalités, il est préférable de faire une nouvelle version de la WebApp et de l’application et de la soumettre au magasin d’applications.
Conclusion
Le marché des smartphones est en augmentation permanente en France. Alors, WebApp or not WebApp, que retenir ?
– WebApp : mise en place rapide et disponibilité pour tous les utilisateurs (iPhone, Android, Windows Mobile…)
– Application native : rapidité d’exécution, mode online et offline, possibilité de générer des revenus
– Application native + WebApp : mise en place assez rapide, disponible dans les Stores, gestion des mises à jour, version payante
Quelques liens utiles
– interview de Xavier Rivoire sur l’usage de la Web’app et de la mobile’app
– points clés pour la réalisation d’une application mobile
Francescu
3 décembre 2010
Je pense que le modèle hybrides fait partie des solutions qui seront de plus en plus utilisées.
Je pense cependant que le choix d’une webApp complètement encapsulée dans une application native n’est pas forcément le plus judicieux.
Une des solutions plus efficace (en terme de ratio travail/résultat), est d’effectivement générer les pages en HTML5 côté serveur mais d’y ajouter un système de cache. Chaque écran a donc une URL associé et un status (besoin de connexion ? maximum cache time etc.). L’arborescence est donc côté client. De plus, il faut toujours qu’un ou deux écrans (les écrans clés) soit réalisés nativement afin d’augmenter grandement l’expérience utilisateur.
François Charlot
3 décembre 2010
L’encapsulation sert essentiellement à être présent dans les différents stores.
Le HTML5 et sont mode offline est effectivement une solution efficace pour ce type d’application.
François Tricot
4 décembre 2010
De mon point de vue, il y a la cible d’une part et ce qu’on sait faire maintenant.
Si on exclue la monétisation, HTML5 est clairement la cible. Ca marche même sur l’OS6 de Blackberry maintenant ! DOnc un seul développpement, un design qui s’adapte à la taille des écrans, et on a une application qui marche sur les smartphones et qui permet de faire un portlet / gadget.
Cependant
1) les compléments nécessaires (genre Sencha / jQTouch / jQuery mobile) ne sont pas encore très stables et
2) le mode offline demande un effort conséquent et une stratégie de développment que les développeurs HTML/Javascript ne connaissent pas
Ceci devrait être résolu par les versions ultérieures de ces frameworks de développement, ce qui en fera une plate-forme de choix pour l’avenir et pour les applicaitons destinées à l’entreprise.
En attendant, le plus rapide pour avoir quelque chose de propre est l’application native.
En ce qui concerne les hybrides, citons Microstrategy, éditeur de Business Intelligence, qui a décidé de mettre côté natif tous les écrans de navigation et les invites de formulaires et de réutiliser le web pour les rapports de BI, les graphiques. Ainsi l’applicaiton (au sens de l’enchaînement des menus), dédiée mobilité, est en natif, et le contenu (rapports, …) n’est que de la réutilisation de l’existant.
william el kaim
4 décembre 2010
Une autre approche serait de construire des app … avec une partie graphique utilisant les technologies web. Tous les smartphones, ou presque, utilisent webkit dorénavant…
Sur Android, il n’est pas impossible de créer des app natives qui ont une interface basée sur XML/HTML/Javascript/CSS …
Si on peut éviter de coder avec les API natives les interfaces graphiques des apps cela faciliteraient le travail du développeur, … au détriment de l’unification ergonomique voulue par Apple.
Pour moi une bonne application mobile passe d’abord par des API « serveurs » performantes et une interface adaptée.
Soit on rentre dans le moule proposé par les vendeurs de solutions OS mobiles et leur SDK, soit on prend le minimum du SDK et on ré-intègre le meilleur du web.
Aujourd’hui, il est vrai que cela n’est pas la solution la plus simple à mettre en œuvre!
jimi
11 décembre 2010
Bonjour à tous,
J’aimerais développer une application payante utilisant le html5/javascript/css… j’ai vu que c’est potentiellement possible, cependant j’aimerais savoir il est possible d’avoir des modules payant à l’interieur d’une appli déjà acheté. Je m’explique:
J’ai une appli nommé toto qui a été rendu native pour iphone par exemple. Cette application toto comporte des chapitres (sous forme de diaporama photo et audio) titi . Quand l’utilisateur achète toto pour 2 euros par exemples il a accés à toto donc et à 5 chapitres titi offerts. Si l’utilisateur souhaite ajouté à l’application des chapitres titi il doit payer 1 euros par chapitre supplémentaire.
Comment faire ? La gestion du payement doit se faire via la plateforme du téléphone, où doit on passer par un système de payement en ligne en lien avec l’application ?
Merci pour vos réponses …
Ascencio PAUL
27 décembre 2011
Je travaille sur un système de gestion des processus éducatifs utilisant la technologie mobiquitaire. Si je choisis d’utiliser une solution cloud comme Zoho comme application Web parallèlement à une application de smartphone genre eSurvey, faudrait-il aussi en contre-bas je paie les services d’un serveur dédié pour gérer mes données?