Dla przypomnienia – Astoria (dokładny opis technologii znajdziecie w tym wpisie) nazywa się obecnie „mostem do przenoszenia aplikacji z Androida na uniwersalną platformę Windowsa (UWP)”. Islandwood, to analogiczny „most”, tylko dla aplikacji iOS.
Mogłoby się wydawać, że oba projekty mają podobne założenia i konsekwencje. Jednak po głębszym przyjrzeniu się mechanizmom, różnice stają się bardzo znaczące.
- Zacznijmy od łatwości przenoszenia aplikacji. Astoria to minimalne zmiany w kodzie, a w skrajnych przypadkach nawet ich brak. Użytkownikom udało się sideloadować nie tylko androidowe paczki .apk, ale też usługi Google, dzięki czemu wszystkie aplikacje instalowane z .apk chodziły poprawnie, bez konieczności zmian w kodzie. Dlaczego? Bo zmiany w kodzie dotyczą właśnie miejsc, gdzie aplikacja odwołuje się do usług Google, które w założeniach projektu Astoria miały być zastąpione usługami Microsoftu. W przypadku Islandwood i iOS, deweloper musi poświęcić znacznie więcej czasu, modyfikując aplikację tak, żeby korzystała z API uniwersalnej platformy Windowsa (UWP).
- Dodatkowo, oba podejścia zakładają różne narzędzia programistyczne. Astoria to programowanie w Javie albo C++ używając Android Studio, Eclipse czy innego zewnętrznego IDE. Islandwood to używanie natywnego narzędzia od Microsoftu, czyli Visual Studio i edytowanie kodu pisanego w Objective C. Astoria niejako odciąga programistów od microsoftowych narzędzi i platformy UWP. Islandwood przeciwnie – robi pierwszy krok w celu migracji do rozwiązań firmy z Redmond.
- Trzeci problem dotyczy środowisk uruchomieniowych. Aplikacje przekonwertowane zgodnie z założeniami Islandwood działają natywnie (kod maszynowy bez maszyny wirtualnej) i są kompilowane do kodu zgodnego z runtimem WinRT i platformą UWP. Astoria to odrębne środowisko uruchomieniowe – (wolniejsza) maszyna wirtualna Javy i kompilator Just in Time.
- Ostatnią różnicą jest jądro systemu. Tak jak pisałem kilka miesięcy temu, Projekt Astoria zakłada nie tylko istnienie maszyny wirtualnej Javy, ale jak wiele wskazuje (pisałem o tym tutaj) również elementów jądra Linuksa, co generuje problemy z licencjami GPL i otwartością części kodu. Islandwood nie potrzebuje natomiast żadnej dodatkowej warstwy systemu. Aplikacje portowane zgodnie z założeniami tego „mostu” są kompilowane i traktowane przez system dokładnie tak jak dedykowane windowsowe aplikacje UWP pisane w C#/XAML.
Moje źródło podaje, że Astoria została zawieszona (ale nie całkowicie anulowana) z po pierwsze powodu chęci chronienia uniwersalnej platformy Windowsa (UWP). Początkowe portowania aplikacji przez użytkowników na XDA wprost z androidowych paczek .apk bez edycji kodu, pokazały Microsoftowi, że to droga na skróty, która nie spowoduje przejścia na usługi Microsoftu, a będzie wiązała się z dużym ryzykiem zmniejszenia bezpieczeństwa aplikacji (malware związane z instalowaniem aplikacji z niezweryfikowanych źródeł). MS mocno zainwestował w UWP i W10 Mobile, a Astoria zdecydowanie nie pomagała rozwojowi tej platformy.
Druga kwestia to wydajność – z nieznanych przyczyn, smartfony z buildami programu Windows Insider, w których istniało środowisko uruchomieniowe Androida, z czasem zaczęły zwalniać i mieć problemy z płynnością działania. Ten argument najmniej mnie przekonuje, ale podobno jest on realnym problemem, a nie tylko PR-ową zasłoną dymną.
Po trzecie – Microsoft chcąc postawić na wydajność i wsparcie UWP, mocno promuje most Islandwood, który wymaga więcej ingerencji programistów w kod, ale przeportowana aplikacja jest natywną appką UWP, korzystającą z uniwersalnego API Windowsa 10 – rozwijaną w Visual Studio za pomocą microsoftowych narzędzi.
Po czwarte – rozwijanie osobnego androidowego runtime’u oraz API i uaktualnianie go do kolejnych wersji Androida to masa pracy całej rzeszy programistów. Według moich informacji firma uznała, że na obecnym etapie praca tych osób jest potrzeba bardziej przy innych, bardziej newralgicznych projektów – w tym projektu Islandwood.
Po piąte – firma zdecydowała się czasowo zrezygnować z wyścigu o udział w rynku mobilnym. Jak to określają wewnętrznie: „czas na nowo się okopać i znaleźć dobrą pozycję do ataku”. Aplikacje do W10 Mobile mają trafiać dzięki UWP i popularności pełnego Windowsa 10 – w ciągu kilku najbliższych lat. MS przestał się pod tym względem spieszyć, więc chwytanie się brzytwy w postaci Astorii, nie ma w tym momencie sensu.
Podsumowując – Microsoft chcąc chronić uniwersalną platformę Windowsa (UWP), płynność działania systemu, bezpieczeństwo appek oraz właściwie zarządzać swoimi wewnętrznymi zasobami – zdecydował się zawiesić projekt Astoria. Robi to stawiając na płynny i powolny rozwój Sklepu Windows dzięki UWP i rosnącej popularności W10. Otwartym pozostaje pytanie – czy Astorię zawieszono na zawsze? Tego nie byłbym taki pewien.