Microsoft dispose de deux projets, Astoria et Islandwood, pour importer respectivement les applications Android et iOS. Comme nous l’avions signalé la semaine dernière, il manquait certaines informations sur les limitations de ces méthodes. On en sait désormais un peu plus sur les problèmes que ces applications pourront rencontrer, surtout du côté Android.

Un sous-système Android avec des limites claires

Comme annoncé durant la conférence BUILD et détaillé dans notre article sur la nouvelle stratégie de Microsoft, Windows 10 pourra exécuter des applications initialement développées pour Android et iOS. La méthode choisie diffère cependant dans chaque cas, ce qui a des répercussions dans l’import de ces applications, mais également dans leurs possibilités à l’exécution.

Le projet Astoria est ainsi conçu pour autoriser les applications Android à s’exécuter presque telles quelles sur Windows 10. Un sous-système AOSP (Android Open Source Project) sera présent, avec une machine virtuelle Dalvik. Comme nous l’avions déjà indiqué, les fonctionnalités liées à Android 5.0 ne seront donc pas prises en charge, tandis que le support des Google Play Services sera minimal. Un grand nombre d’applications risque donc de ne pas fonctionner.

Pour celles qui se lanceront sans problème, il faudra également compter sur des limitations. C’est ce qu’a indiqué le responsable Kevin Gallo à Techradar. Dans la plupart des cas, des équivalents seront trouvés pour les services qui sont normalement appelés. Par exemple, Google Ads et Google Analytics seront renvoyés vers Microsoft Ads et App Insights. Globalement, une application Android fonctionnera dans un conteneur et une couche spécifique s’occupera de traduire les appels pour les convertir. Le développeur pourra prendre les devants en changeant « quelques lignes de code ».

Tout ce qui touche au système de fichiers, à la gestion des photos, des contacts ou encore des captures sera automatique. Les mécanismes plus spécifiques auront un destin plus aléatoire. Gallo a ainsi indiqué que les messageries et les applications qui ont besoin important des services en tâches de fond pourraient ainsi rencontrer des problèmes. Du fait du fonctionnement en conteneur et d’un modèle de sécurité particulier, les applications converties ne fonctionneront pas en arrière-plan. La compatibilité est cependant considérée comme « correcte » puisqu’il s’agit bien des spécifications d’AOSP.

Pour iOS, il faudra importer les projets dans Visual Studio Code

Du côté d’iOS, traduire une application ne sera pas aussi simple mais déverrouillera en contrepartie certains avantages. Le projet du développeur devra être importé depuis Xcode vers Visual Studio Code et des modifications devront être faites (seul l’Objective-C est actuellement pris en charge, mais Swift sera ajouté plus tard). Même si elles seront plus nombreuses que pour Android, le processus de conversion devrait simplifier l’ensemble et, contrairement à la plateforme de Google, toutes les API de Windows 10 seront accessibles.

Le gros avantage pour les applications iOS est qu’elles seront intégralement converties en applications universelles, ce qui leur ouvre les portes de tous les appareils Windows 10, y compris donc les tablettes plus grandes et les PC. Le sous-système Android installé dans Windows 10 ne sera présent en effet que dans les smartphones et les petites tablettes, ce qui limitera d’autant leur utilisation. Dans tous les cas, les développeurs auront le choix des terminaux sur lesquels leurs applications pourront être installées.

Des passerelles pour mettre un premier pied dans le monde Windows

Mais pourquoi finalement ne pas avoir abordé l’ensemble des traductions d’applications sous le même angle ? Selon Kevin Gallo, les importations de projets Android causaient des problèmes. En outre, même si ces solutions sont mises en place, elles ne constituent pas une finalité. Le responsable explique en effet que ces portes ont été mises en place pour permettre à des développeurs et des éditeurs plus importants de passer rapidement sur la plateforme Windows 10. Ce sont des solutions pour « aller au plus rapide », mais en aucun cas les plus abouties, ne serait-ce que parce que les interfaces ne seront pas pensées pour la plateforme et apparaîtront ainsi comme décalées. 

Microsoft a donc prévu ces solutions pour drainer l’attention et permettre à ceux qui ne sont pas familiarisés avec le développement sous Windows d’y mettre un premier pied. Sur le long terme, il est évident que la société ne souhaite pas que les projets Astoria et Islandwood restent aussi utilisés et fera probablement tout pour amener les éditeurs concernés à se tourner vers le SDK complet de Windows 10. La grande question qui reste cependant en suspens se devine facilement : les développeurs feront-ils l’effort ou se contenteront-ils de ces passerelles simplifiées ?