Google va intégrer plus profondément les web apps dans Android

Stéphane Moussie |

La prochaine version de Chrome pour Android va marquer une étape importante dans l’intégration des web apps. Les Progressive Web Apps (des web apps répondant à plusieurs critères définis par Google, des exemples ici) qui seront ajoutées au système via la fonction dédiée de Chrome 57 figureront dans le lanceur d’applications et les réglages d’Android, comme des applications natives.

Les web apps pourront aussi tirer parti des notifications d’Android plutôt que de celles de Chrome et communiquer directement avec les autres apps grâce aux liens profonds. En somme, on aura l’impression d’utiliser une application native.

iOS permet aussi d’ajouter des sites web sur l’écran d’accueil, mais l’intégration est bien moins poussée. Tout au plus les web apps peuvent masquer l’interface de Safari (c’est le cas des Progressive Web Apps). Autant il est logique de voir Google pousser le web (et ses pubs) dans Android, autant Apple n’a pas forcément intérêt à faire cela pour ses affaires.

Ajout de la Progressive Web App du Financial Times sur iOS. L'intégration est beaucoup plus limitée que sur Android. Cliquer pour agrandir

Pour rappel, pour ajouter un site web à votre écran d’accueil, ouvrez-le avec Safari, tapotez sur le menu de partage puis sélectionnez l’option « Sur l’écran d’accueil ».

avatar PomBreizh | 

Parle-t-on de la même chose dans l'article, entre une web apps développée et déployée comme tel côté Android, et une page web posée sur le springboard "comme une app", par l'utilisateur, côté iOS?

avatar cedric1997 | 

On parle bien de la même chose. Dans les deux cas ce ne sont que des sites web, qui souvent ne sont même pas présentés comme tel. On réalise que ce sont des web apps uniquement au moment de les ajouter à la page d'accueil. À ce moment, lorsqu'on appuie sur leur icône, l'interface du navigateur est cachée.

avatar jackhal | 

Vu comme Chrome pour Android est truffé de bugs, je souhaite bien du courage à ceux qui vont se lancer dans la réalisation de web apps un peu complexes.
J"ai passé la semaine à m'arracher les cheveux à cause de ce navigateur de m... : tout ce que je voulais utiliser était buggué : transitions CSS, requestAnimationFrame, event pageshow... Il n'y a pas un seul truc "récent" qui fonctionnait de manière correcte, c'est désespérant.

Sous iOS, Safari est tout simplement exemplaire. Je dis bien : Safari.
Dans l'article il est écrit : "Tout au plus les web apps peuvent masquer l’interface de Safari" mais c'est inexact. Ça n'est pas la seule différence... on n'a plus le même moteur de rendu !
Celui qui s'active pour les web apps est moins avancé que celui de Safari : plus lent, rafraichissement non voulus, fonctionnalités absentes, et plus possible de compter sur le swipe depuis un bord de l'écran pour naviguer dans l'historique (ce que l'utilisateur attend non seulement du navigateur, mais aussi des applis).

Bref, c'est quasiment inutilisable pour faire quelque chose de correct.

Franchement, en ce moment j'ai l'impression d'avoir fait un bond de 15 ans dans le passé. Les navigateurs permettent énormément plus de choses en théorie, mais rien n'est vraiment fiable pour toutes les plate-formes dans les nouveautés de, mettons, moins de 5 ans.
Et plus ça va, plus les navigateurs s'éloignent les uns des autres : le comportement de Blink s'éloigne de plus en plus de celui de Webkit, Chrome Android et Chrome desktop ne se comportent pas de la même manière, Safari iOS et une page convertie en web app ne fonctionnent pas non plus de la même manière... c'est vraiment une sale période.

J'en suis arrivé à ne souhaiter qu'une chose : la fin de la course aux nouvelles possibilités, et une période de stabilisation et d'harmonisation. Un genre de Snow Leopard des tous les navigateurs.

Du coup, j'accueille assez mal ce genre de news.
Stoooooop !

avatar kitetrip | 

C'est vrai que la compatibilité entre les navigateurs mobiles devient un véritable casse-tête, qui rappelle l'époque d'IE6 VS Mozilla...
Le vrai soucis est effectivement Android qui fait la course aux nouveautés, mais aujourd'hui on a encore des smartphones neufs qui sont vendus avec Android 4.4 (et qui souvent ne sont jamais mis à jour)...
C'est vraiment dommage car les Progressive Web App sont utiles pour proposer une expérience smartphone à partir d'un site web. Les coûts de développements sont moins élevés et on évite de proposer une application mobile qui n'apporte finalement pas grand chose par rapport à un site mobile.

avatar DG33 | 

Qu'est-ce que Google entend intégrer plus profondément ?
Ca me fait un peu peur... Je vais essayer de me détendre un peu et tousser, ça passera mieux, non ?

avatar Bigdidou | 

@DG33

'Qu'est-ce que Google entend intégrer plus profondément ?
Ca me fait un peu peur... Je vais essayer de me détendre un peu et tousser'

Eh bien, si en toussant tu craches des web apps, tu sauras à quelle point elles ont été profondément intégrées.
Mais a priori, d'après l'article, ça ne concernerait que monsieur Android.

avatar Pato49 | 

L'intérêt de la progressive web app est de pouvoir tourner sur différents navigateurs, proposant l'interface la plus enrichie possible selon la compatibilité du navigateur. Dans safari on ne peut pas dire qu'on a une expérience enrichie, il ne supporte pas la mise en cache via service worker ("En cours d'étude" dans le moteur Webkit). Donc oui on peut afficher l'application dans safari, mais on a le droit à la version la plus dégradée...

Peut être qu'un jour Safari rattrapera son retard sur Chrome et Firefox qui le supporte depuis bientôt un an, alors que les équipes webkit sont toujours en train de se poser la question de savoir s'ils doivent l'implémenter...

avatar jackhal | 

"il ne supporte pas la mise en cache via service worker"
Non mais c'est pas pour autant qu'il n'a pas de cache (via localStorage ou IndexedDB, ou même le bon vieux et infernal manifest).
Si tu ne veux utiliser QUE le cache via les service worker, tant pis pour tes utilisateurs.

Quant à ce qui est du refrain "Safari a du retard", je pense l'inverse : dès que je veux utiliser les choses de manière un minimum poussée, je tombe sans arrêt sur des bugs dans Chrome mobile, bugs qui n'existent ni dans Chrome desktop ni Safari iOS. D'habitude je remplis des rapports de bugs mais je ne le fais pas avec Chrome mobile, ça me prendrait trop de temps. Sérieusement, c'est à ce point là.

Et sinon, Safari aussi a de l'avance sur certaines choses que je trouve très utiles. Genre position:sticky tout juste arrivé sous Chrome (4 ans après Safari), ou encore scroll-snap, filter/backdrop filter toujours pas supportés par Chrome. Ou encore les CSS regions, abandonnées par Chrome "pour des raisons de complexité et de performance"... qui n'ont pas l'air de poser problème ni à WebKit, ni à Edge et ce depuis plusieurs années.

avatar pat3 | 

Le vrai souci c'est que Google reprend de plus en plus explicitement la stratégie de M$ à l'époque d'IE: profiter de sa position dominante pour imposer SES standards propriétaires au Web en faisant croire à une expérience dégradée des autres navigateurs. Et tous les outils produits par Google à l'intention des développeurs tendent à accélérer ce processus.

CONNEXION UTILISATEUR