Universal Windows Bridges : Windows 10 drague les développeurs Android et iOS
La philosophie « universelle » de Windows 10 s’étend au-delà des devices. Avec ses UWP Bridges, Microsoft compte rallier à son nouvel OS tous les développeurs iOS, Android et .NET jusqu’ici réfractaires au Windows Store.
Microsoft pourrait bien jouer son dernier atout avec Windows 10. L’éditeur n’a pas vraiment droit à l’erreur s’il veut accorder un futur à Windows dans la mobilité et rester pertinent dans l’univers de l’informatique personnelle.
Si en matière d’ergonomie, le nouveau Windows fait marche arrière et cherche ouvertement à séduire tous les utilisateurs de la version 7, il affiche aussi des prétentions bien supérieures à celles de se succéder à lui-même : il cherche avant tout à s’imposer sur tous les appareils. C’est grosso-modo le même Windows 10 qui s’exécutera sur les smartphones, sur les tablettes, sur les PC, sur les écrans géants (Surface Hub et Xbox One), sur les casques HoloLens et sur les « IoT » (objets connectés de toute nature).
Le Un pour Tous
Cette stratégie n’a de sens que si les utilisateurs peuvent exploiter les mêmes applis, sur tous les appareils, à partir d’un seul et unique Store unifié (de sorte à n’acheter l’app qu’une seule fois et en profiter partout) ; et que si la plateforme sous-jacente réalise l’essentiel du travail d’adaptation des interfaces utilisateurs aux différentes tailles d’écran et méthode d’interaction.
C’est pourquoi Microsoft propose enfin avec Windows 10 un « Windows Store » unifié pour les utilisateurs, et pour les développeurs, une plateforme d’exécution unique.
Cette plateforme, dénommée UWP (pour Universal Windows Platform), permet de développer une seule version d’une application et la voir s’adapter et s’exécuter sur tous les écrans et tous les dispositifs
Briser le cercle vicieux
Reste à concrétiser le plus dur. Convaincre les utilisateurs de migrer et convaincre les développeurs de s’intéresser à la plateforme.
Le problème, c’est que ces deux impératifs sont liés : les développeurs ne s’intéressent qu’aux plateformes qui leur apportent des centaines de millions d’utilisateurs sur un plateau, et les utilisateurs optent majoritairement pour les appareils qui hébergent les applications à la mode.
Une boucle que Microsoft doit nécessairement briser pour imposer à la fois son Windows Store sur PC (un Windows gratuit impliquant de trouver des revenus ailleurs) et son système sur les appareils mobiles. C’est bien là le grand échec de Windows 8.1 et son pendant Windows Phone 8.1.
Pour convaincre les utilisateurs, Microsoft met en place une redoutable et probablement efficace politique de mise à jour gratuite qui amène l’éditeur à pousser « presque en force » la mise à jour sur tous les PC Windows 7 et Windows 8 (même les versions pirates).
Mais convaincre les développeurs est une opération bien plus délicate. Leur adhésion à la stratégie Microsoft dépend de problématiques politiques, stratégiques et techniques. Les aspects stratégiques se résoudront d’eux-mêmes, si les utilisateurs migrent en masse rapidement.
Honnêtement, Microsoft n’a pas grand poids pour influer sur les décisions politiques (voire idéologiques) des éditeurs. Il ne lui reste donc qu’un seul levier sur lequel agir : la difficulté technique. D’où l’idée des Universal Windows Platform Bridges (UWP Bridges). Ces derniers poursuivent tous le même objectif : simplifier le travail des développeurs Win32, Web, Android et iOS dans leur effort de portage et de publication de leurs Apps sur le Windows Store.
Plusieurs projets de Brdiges viennent concrétiser cet effort stratégique.
Projet Centennial pour les développeurs Win32/ .NET
En lançant Windows 8, Microsoft introduisait une nouvelle plateforme d’exécution dénommée WinRT, présentée comme le successeur des runtimes Win32 et .NET.
Celle-ci cherchait à résoudre les problèmes d’invasion du système (qui fait que chaque nouveau logiciel installé semble ralentir un peu plus Windows) et éradiquer la multiplication des malwares et adwares.
Aujourd’hui, seules les applications « WinRT » peuvent être publiées et distribuées via Windows Store. Un choix qui a décontenancé bien des développeurs traditionnels de l’univers Windows. Le projet Centennial cherche à corriger le tir.
Son objectif est de permettre de packager et publier les logiciels Windows classiques (Win32, .NET) sur le Windows Store. Et faire en sorte de les transformer en Apps sans aucun impact sur le système
Fonctionnement : Centennial est une version modifiée de Microsoft App-V. Cet outil permet de récupérer un fichier d’installation MSI, de capturer les changements que son installation occasionne sur le système, puis de lancer l’exécution du logiciel dans une bulle de virtualisation applicative (autrement dit un container).
Centennial transforme ainsi le MSI en un conteneur APPX déployable sous Windows Store.
Le kit de développement comporte également les librairies nécessaires pour permettre à des applications « Bureau » d’accéder aux services propres à Windows 10 comme Cortana, les notifications et les vignettes dynamiques.
Ses limites : Centennial ne peut pas être appliqué à n’importe quel logiciel Windows. Pour que cela fonctionne, il faut que celui-ci n’ai pas à déployer de pilotes et ne traficote pas avec les couches les plus basses du système.
En outre, les applications ainsi packagées sont intimement liées au bureau et aux processeurs x86. Elles ne s’exécuteront donc que sur la version normale du système (PC et machines hybrides) et non sur sa déclinaison mobile (smartphones et tablettes de moins de 8 pouces).
Impact pour le Store : Pour peu que tous les éditeurs classiques de l’univers Windows et les développeurs du monde Open Source jouent le jeu, Centennial a la capacité d’apporter au Windows Store des millions de logiciels et utilitaires. C’est sans doute le Bridge qui aura le plus d’impact à court terme sur le Store.
D’autant que grâce à lui, les utilisateurs prendront vite l’habitude de récupérer leurs logiciels via le Windows Store pour échapper aux malwares et autres adwares que les recherches et téléchargements via Internet leur réservent.
Risque pour le Store : La prolifération d’applications non « universelles » au cœur du Windows Store peut, à moyen terme, mettre à mal la stratégie « un pour tous » de Microsoft.
Projet Westminster pour les développeurs Web
Le Web n’est plus simplement peuplé de sites mais aussi de véritables applications interactives. Celles-ci évitent aux développeurs de se préoccuper de la variété des plateformes et des contraintes de publication dans les Stores.
Pour Microsoft, les développeurs d’applis Web sont désormais une cible privilégiée d’autant que bien des projets « métiers » s’appuient désormais sur des apps HTML5 plutôt que des développements natifs.
L'objectif de Westminster est de permettre aux développeurs Web de packager leurs applis pour les publier sur le Windows Store et leur permettre d’exploiter les notifications, vignettes Dynamiques et autres APIs de Windows 10.
Fonctionnement : Sur le principe, il suffit au développeur de saisir l’URL de l’application sur le portail du Windows Store Dev Center.
Le système génère alors automatiquement un exécutable APPX publié sur le Store. Cet exécutable n’est en réalité qu’une app minimaliste embarquant un « Web Viewer » s’appuyant sur le moteur de rendu et d’exécution de Microsoft Edge (le nouveau navigateur, ex projet Spartan).
Toutefois, l’App ainsi générée s’exécute sur un contexte de sécurité différent du navigateur. Les développeurs ont ainsi accès en JavaScript aux APIs Windows (il suffit simplement d’ajouter un test « if (window.Windows) ») pour enrichir l’expérience utilisateur avec des notifications, vignettes dynamiques, Cortana et des accès aux capteurs embarqués.
L’App peut s’exécuter sur toutes les déclinaisons de Windows 10. En outre, le développeur n’a pas à re-générer l’APPX chaque fois qu’il enrichit et modifie son application Web.
Limites : L’application fonctionne exclusivement en mode connecté puisque le conteneur accède directement à l’application Web.
Impact pour le Store : En général, les développeurs Web n’ont guère envie de se confronter aux processus de certification des Stores. Il n’est donc pas certain que le projet Westminster apporte de nombreuses Apps à court terme. Cela reste toutefois une solution rapide pour les entreprises qui veulent apparaître sur le Store sans avoir à développer une application Windows.
Risque pour le Store : Les utilisateurs préfèrent les Apps natives. Mais avec les principes de Responsive Design, les applications Web sont finalement très proches des applications universelles et pourront se fondre aisément au paysage du Windows Store si - et seulement si - les développeurs enrichissent l’expérience par les APIs clés de Windows : Cortana, notifications, etc.
Projet Astoria pour les développeurs Android
Permettre l’exécution des applications Android sous Windows est un projet de longue date chez Microsoft qui a connu différentes variantes expérimentales (via Azure ou les Pico Kernels notamment). Finalement, Microsoft opte pour une approche qui rappelle celle de BlackBerry et BB10.
L'objectif du projet Astoria est de permettre aux développeurs de déployer leurs APK Android sur le Windows Store avec un minimum de modification et sans avoir à « forker » leur code source pour Windows.
Fonctionnement : Le projet Astoria est sans doute le plus ambitieux de tous les Bridges car ce n’est pas uniquement un SDK.
Windows 10 Mobile intègre un sous-système (qui est plus qu’un émulateur et n’est pas non plus une VM) qui permet l’exécution directe des APK natifs ou en Java. Ce sous-système, qui repose sur la version Open Source d’Android Kit Kat, convertit à la volée tous les appels au noyau Android en appels Windows.
Outre le sous-système, Astoria fournit aux développeurs tout un SDK pour exploiter simplement les services Microsoft en remplacement de ceux de Google ainsi que pour exploiter les fonctionnalités avancées de Windows (Cortana, Vignettes, etc.).
Le développeur se connecte au portail du Windows Store et soumet son APK. Ce dernier passe par une moulinette qui évalue la compatibilité directe et signale les lignes de codes à modifier pour exploiter les services Microsoft/Bing en lieu et place des services propres à Google. A priori, le portail proposera automatiquement une ligne de code de remplacement qu’il suffira de copier/coller en lieu et place de la ligne incompatible.
Limites : Outre la compatibilité limitée à Android 4.4, on notera que le sous-système n’existe que sur la déclinaison « Mobile » de Windows 10. Autrement dit, les applications ainsi portées ne s’exécuteront pas sur les PC et les hybrides, mais uniquement sur les smartphones et tablettes de moins de 8 pouces sous ARM.
Impact pour le Store : Microsoft attend beaucoup d’Astoria d’autant que les développeurs n’auront pas à « forker » leur code source pour s’affranchir des services Google sous les appareils Windows et pour tirer parti des fonctionnalités de Windows 10. Reste que l’effort est assez similaire à celui nécessaire pour publier l’application sous Amazon Store (pour les Fire) ou sous BlackBerry World. Or ces plateformes n’ont jusqu’à présent rencontré qu’une adhésion très limitée de la part des développeurs Android.
Risque pour le Store : Là encore, Astoria sacrifie la philosophie « Universal App » sur l’autel de l’impératif à remplir le Windows Store le plus rapidement possible.
L’effort est louable mais il ne vise qu’à pousser les Windows Phones. C’est un objectif à court terme qui peut finalement se retourner contre Microsoft si le Store finit envahi d’APKs transformés. À long terme, l’éditeur préférerait voir les développeurs créer leurs Apps Android directement sous Visual Studio 2015 à partir de leur code Windows.
Projet Islandwood pour les développeurs iOS
C’est sans doute le Bridge actuellement le moins avancé et le moins mature. C’est aussi celui le plus complexe mais peut-être le plus prometteur. Il se destine à tous les développeurs iOS qui souhaitent toucher l’audience Windows.
Son objectif est de simplifier le portage des codes sources XCode vers Visual Studio 2015 afin de minimiser l’effort nécessaire pour adapter une application iOS à Windows 10... et éviter aux développeurs d’Apple d’apprivoiser C#.
Fonctionnement : Le projet Islandwood est essentiellement un add-In Visual Studio qui convertit à la volée un projet XCode en projet Visual Studio.
Il s’accompagne d’un compilateur Objective-C pour Windows. Dès lors, les développeurs peuvent directement transformer leur application iOS en application Windows en conservant l’essentiel de leur code et leurs ressources UI. Ils n’ont pas à apprendre un nouveau langage comme C# et peuvent directement accéder aux APIs Windows 10 en Objective-C.
Limites : Deux limites caractérisent cet UWP Bridge.
D’abord, les développeurs devront nécessairement « forker » leur projet iOS. Impossible de maintenir un projet vraiment commun aux deux plateformes.
Ensuite, l’effort nécessaire pour modifier le code afin qu’il s’exécute sous Windows est important : il faut réécrire tout ce qui est gestion des notifications, des capteurs, etc.
Enfin, Islandwood ne prend en charge que les projets Objective-C et non ceux en Swift (mais Microsoft travaillerait aussi sur le portage Windows de ce compilateur désormais en Open Source).
Impact pour le Store : Parce que ces développeurs Apple sont déjà formés aux concepts d’universalité imposés par iPhone et iPad et parce que les apps iOS sont généralement plus réussies que les versions Android, Islandwood est sans doute le meilleur atout de Microsoft. Mais l’effort de portage nécessaire implique du temps et des ressources que les éditeurs iOS ne trouveront que si le marché le justifie.
À court terme, le Store ne devrait donc pas être envahi par les portages iOS.
Risque pour le Store : C’est sans doute le bridge qui comporte le moindre risque pour le Windows Store, les Apps générées étant potentiellement déjà universelles. En outre, les performances et la consommation énergétique de ces Apps devraient être bien meilleures que celles des Apps Android portées via le bridge Astoria.
Disponibilité dans le courant de l’été
Les UWP Bridges ont été annoncés début Mai lors de la conférence Microsoft Build 2015.
Ces derniers ne sont pas encore officiellement disponibles. Les développeurs peuvent cependant soumettre leur candidature pour y accéder en avant-première depuis le site officiel. Tous les Bridges devraient toutefois être disponibles dans le courant de l’été.
