Programowanie mobilne w .NET - barwna historia i niewiadoma przyszłość

Aplikacje mobilne pisane w .NET nigdy nie miały łatwo, podobnie jak ich deweloperzy. Jednakże w ostatnich latach Microsoft mocno stara się, aby ekosystem do tworzenia aplikacji w technologii .NET był jak najbardziej przyjazny twórcom (apka mobile jest must have niemalże każdej firmy). Pomimo tego obecnie jesteśmy w technologicznym rozkroku w .NET mobile (uśmiercenie Xamarin.Forms jeszcze przed narodzinami MAUI). Skłoniło mnie to do pewnych refleksji związanych z programowaniem w technologiach Microsoft mobile. Z racji tego, że "klepię" ;)  w .NET już prawie 14 lat to przewinąłem się przez wiele projektów mobilnych (komercyjnych i nie tylko) tworzonych właśnie przy pomocy narzędzi Microsoft. W tym wpisie postaram się przedstawić w miarę zwięzłej formie historię programowania mobilnego w .NET, która jest ze mną niemalże od zawsze. 

Windows Mobile i .NET Compact Framework

Moja przygoda z technologiami mobilnym od Microsoftu zaczęła się właśnie od .NET Compact Framework. Jego historia sięga roku 2002, ale ja dopiero miałem z nim styczność pod koniec jego żywota w okolicach 2010 roku, tworząc aplikację pod Windows Mobile 6.x.

.NET Compact Framework 3.5 (bo z tą wersją finalnie pracowaliśmy) był mniejszym bratem .NET Frameworka. Działał na urządzeniach z rodziny Windows CE. Tworzenie pod Windows Mobile 6.x zbliżone było trochę do pracy z WinFormsami. Narzędzia oferowały wparcie dla emulatora i nie działało to aż tak źle (chociaż pamięć może mi płatać figle). Tworzone aplikacje czysto biznesowe nie grzeszyły urodą, ale trzeba oddać to, że faktycznie dało się dość sprawnie tworzyć tego typu oprogramowanie w .NET. Nie było oczywiście idealnie i przypominam sobie, że w projekcie obok plików z C# znajdował się także kod z C++. Ten ostatni pozwalał na zarzadzanie elementami WM6.x, niedostępnymi z poziomu C# (customizowane elementy UI, Bluetooth). Warto dodać, że framework XNA (do tworzenia gier) bazował właśnie na .NET Compact Framework w wersji pod Xboxa 360.

Mimo swojej siermięgi (jak wszystko co było w tamtych latach z obecnej perspektywy), tworzenie aplikacji mobilnych w .NET (Compact Framework) było ciekawym wyzwaniem. Mobilna technologia dopiero wkraczała do życia codziennego i wszyscy uczyli się jak powinny wyglądać aplikacje na urządzenia przenośne. Sam Windows Mobile był również dość ciekawym tworem. Silnie związany z desktopowym Windowsem (zarówno UI, jak i oferowane możliwości) pozwalał programistom na tworzenie różnorodnych aplikacji z niemalże nieograniczonymi uprawnieniami. Taka dowolność była też dość niebezpieczna (na prawdę dosłowny brak ograniczeń), a sam UI bardzo nieergonomiczny i nieprzystosowany do dotyku (nieprzypadkowo rysik był wówczas nieodłącznym kompanem każdego Windows Mobile). To było też jednym z głównych powodów klęski systemu.

Choć Microsoft miał dobre chęci, to Windows Mobile został pogrzebany błyskawicznie po premierze pierwszego iPhone. Apple pokazało jak powinien wyglądać mobilny system i aplikacje przenośne. .NET Compact Framework i Windows Mobile były nieprzystosowane do wymogów szybko rosnącego rynku mobile. W ciągu 3 lat od premiery iPhone, udziały Windows Mobile (rynek US) skurczyły się z ponad 40% (2007) do niecałych 7% (2010).

Ostatnia wersja Windows Mobile 6.5.x pochodzi z roku 2009 i uznana była za koszmar, który nigdy nie powinien ujrzeć światła dziennego. Windows Mobile nie mógł być tak dalej tworzony. Microsoft postanowił stworzyć nowy system mobilny od zera, zakopując wszystko co do tej pory stworzył i wyszedł z tego...

Windows Phone 7.x i Silverlight

Windows Phone 7.0 miał premierę pod koniec roku 2010. Nowy system był od strony użytkownika zupełnie innym rozwiązaniem (kafelki zaczerpnięte z odtwarzacza mp3 Zune, styl Metro). Windows Phone 7.0 można jednakże określić jako mobilny system w wersji alfa. Od strony użytkownika praca z Windows Phone przed aktualizacją 7.5 była sporym wyzwaniem - brak przełączania się pomiędzy aplikacjami, bardzo ograniczone funkcje, prosty (żeby nie powiedzieć prostacki) system w porównaniu do konkurencji, a szczególnie do Windows Mobile (polecam mój wpis na blogu z 2011 roku - Windows Phone 7.5 Mango - (R)EWOLUCJA?). Szczególnym zaskoczeniem był brak aktualizacji z Windows Mobile 6.x do Windows Phone 7.x, pomimo zapewnień, że tak się stanie, a wiemy że sprzętowo nie było przeciwskazań (historia HTC HD2).

Deweloperzy .NET również mogli poczuć się zaskoczeni. Windows Phone 7.x był tak naprawdę starym Windows CE z runtime w Silverlight. Programiści byli zamknięci w piaskownicy Silverlight (v4) z dużymi ograniczeniami. Tak jak już wspomniałem - Microsoft odpuścił sobie temat aktualizacji starszego sprzętu do Windows Phone 7. Spowodowało to, iż użytkownicy nie mogli nie tylko uruchomić starszej apki na nowym systemie, ale też nie dostali możliwości uruchomienia nowej (jeśli taka by powstała) na starym urządzeniu.

Taki stan rzeczy nie był komfortową opcją dla programistów .NET. Tak naprawdę Windows Phone od strony tworzenia aplikacji był całkowitym zerwaniem z tym co oferował dewelopment Windows Mobile i .NET Compact Framework. Silverlight był dość specyficzny, a co więcej, rok po premierze Windows Phone Silverlight był uznany już za martwy produkt (w 2011 roku!).

Microsoft przygotował mimo tego bardzo dobre środowisko programistyczne w Visual Studio. Dodatkowo zaradni deweloperzy mogli zdobyć kilka fantów tworząc aplikacje na mobilne okienka. Za przygotowanie mobilnych apek można było zdobyć kody na Steam, a nawet telefony z Windows Phone. W ten sposób sklep szybko zapełniał się , mimo że jakość aplikacji była na dość średnim poziomie. W międzyczasie kupiono Nokię, którą pogrzebano żywcem razem z innym "dobrymi" pomysłami.

Zerowa baza użytkowników na start, duże ograniczenia, zła prasa (nieprzychylne recenzje wytykające krok w stercz w stosunku do Windows Mobile) nie pomagały młodemu systemowi. Pomimo tego użytkownicy byli spragnieni nowości. W Europie Windows Phone miał ponad 10% rynku. We Francji było to ponad 14%, zaś w Polsce ponad 16%. Wydawało się, że Microsoft ma wreszcie pomysł na mobilny system i sukces jest już kwestią czasu. Sam w od roku 2011 byłem olbrzymim fanboyem Windows Phone i z perspektywy czasu widzę, że problemy w klarownej wizji pogrzebały ten młody system z dużymi ambicjami. 

Cóż, gigant z Redmond ponownie zrobił olbrzymi błąd, z którego finalnie już się nie podniesie...

Windows Phone 8 i Windows NT

Końcówka 2012 to premiera Windows Phone 8. Wersja 8.0, a w szczególności 8.1 była dużą rewolucją. Wyrzucono sandbox Silverlighta (został XAML) i starego Windows CE. Nowy WP8.1 bazował już na WinRT (wersja 8.0 jeszcze na hybrydzie zwanej WinPRT). Wówczas powstał pomysł tworzenie jednej aplikacji na systemy mobilne i desktopowe - Universal Windows Apps. Była to rewolucja w świecie mobilnym, ale i także poza nim. "Kafelki" nie były już tylko domeną mobilnego Windowsa, ale także pojawiły się w wersji desktop. Przy okazji wydano Windows RT, który już odszedł w zapomnienie lata temu. 

Niestety rewolucja była okupiona ogromnymi kosztami. Dwa lata po premierze Windows Phone 7.0 wydano Windows Phone 8.0, który miał niewiele wspólnego ze starą wersją (tym razem stare aplikacje działały z nowym systemem). W tak krótkim czasie wszystkiego nie da się zrobić. Ponownie okazało się, że stare urządzenia (z Windows Phone 7.x) nie dostaną aktualizacji do nowego systemu (Windows Phone 8), ze względu na nieprzygotowanie sterowników pod starsze modele mobilnych procesorów. Taki stan rzecz odbił się bardzo negatywnie na popularności mobilnych okienek. Nawet świeża Lumia 900 mimo mocnych podzespołów nie otrzymała aktualizacji. Wizerunkowo był to strzał w kolano. Szczególnie, gdy jakiś czas później "magicy" z XDA Developers pokazali, że taki update był do zrobienia.

Deweloperzy dostali Universal Windows Apps na kilka platform. To była już nie ewolucja, a rewolucja w świecie .NET. Programiści byli w stanie pisać kod jednocześnie na urządzenia mobilne, a także desktopowe. To mogło się sprawdzić, ale mam wrażenie, że użytkownicy nie bardzo byli przekonani do aplikacji UWA. Od strony użytkownika desktopowego miały one spore ograniczenia nie tylko od strony funkcjonalnej. UWA na komputerach osobistych miały podobne bariery związane z bycia w "sandboxie" jak w wersji mobilnej, ale dodatkowo dość irytujące problemy dla użytkownika desktop, jak chociażby wymuszona maksymalizacja okna.

WP8 był dobrym krokiem na przód, z genialnymi zmianami od strony deweloperskiej, ale i  błędnymi decyzjami (brak update z WP7). Kolejna wersja mobilnego Windowsa miał być jeszcze lepsza, a była finalnie ostatnia...

Windows 10 Mobile i Universal Windows Platform

Kolejna mobilna wersja systemu z Redmond była doszlifowaniem zmian, jakie wnosił Windows Phone 8.1. Warto zaznaczyć, że zmiana nazwy nie była przypadkowa. Podkreślono jeszcze bardziej integralność pomiędzy mobilnym, a desktpowym Windowsem. Tak zaczął się rok 2016 dla fanów mobilnych okienek.

W połączeniu obu platform swój największy udział miał Uniwersal Windows Platform - rozwinięcie idei UWA. Programiści mogli jeszcze łatwiej pisać aplikacje na kilka platform. Widać było, że cała para poszła w UWP, tak aby nowa uniwersalna platforma była nie tylko ciekawostką, ale także nowym sposobem do pisania aplikacji na systemy z rodziny Windows (a zatem także i na Xboxy). Jak wiemy UWP umocniło się na tyle, że pomimo uśmiercenia Windows 10 Mobile, nadal było ciekawym rozwiązaniem w tworzeniu aplikacji. Co więcej, wersja preview Windows 10 Mobile miała możliwość uruchamiania aplikacji Androidowych, szkoda jednak, że ten ficzer został usunięty w wydaniu finalnym (ależ to mógłby być game changer w roku 206!).

Niestety i tutaj nie wszystko wypaliło, a można powiedzieć, że zakończyło się totalną klapą. Mobilny Windows umarł w roku 2017 (ostatnia aktualizacja bezpieczeństwa miała miejsce na początku roku 2020). Powodów było wiele. System był mało stabilny i posiadał ciągle spora listę uporczywych błędów. Microsoft nie był konsekwentny i już po roku było czuć, że Redmond odpuścił sobie temat mobilnych okienek. Kolejne wydania nie oferowały nowych rzeczy, a tylko podnosiły irytację użytkowników. Programowanie w UWP było przyjemne, ale nadal problemem były ograniczenia od strony desktopowej oraz brak pomysłu na tego typu aplikacje (nawet Microsoft zrezygnował z mobilnego Office na UWP!). Dodajmy do tego udział Windows 10 Mobile w rynku mobilnym na poziomie 0.1% w największym szczycie, a okażę się że programowanie mobile w UWP pod .NET nie miało już większego sensu.

Wndows 10 Mobile był ostatnim systemem mobilnym z Redmond. Pomimo świeżego i przyjemnego programowania w UWP, a także ciekawego pomysłu na program Insider (pozwalający nie tylko na uzyskanie wcześniejszych buildów systemu, ale także instalowanie systemu na oficjalnie niewspieranych urządzeniach)- niestety niewiele już to zmieniło. Nawet całkiem popularne UWP powoli jest obecnie wygaszane i najprawdopodobniej skończy jako kolejny dobry pomysł, z którego nic nie wyszło (polecam wątek na GitHube o braku wsparcia dla UWP w .NET 5/6).

Xamarin - dobry, bo spoza Redmond

Xamarin powstał w 2011 (pierwsze wydanie 2013) rękami twórców Mono. Miał na celu umożliwienie pisania aplikacji mobilnych w .NET pod iOS, Androida i Windows. W początkowej fazie był płatnym frameworkiem, aż do 2016 roku, kiedy został przejęty przez Microsoft (w tym samym roku wydano Windows 10 Mobile!).

Xamarin (Native, premiera w roku 2013) pozwal na tworzenie aplikacji w .NET, które będą działały m.in. na iOS i Android. Możliwości są na prawdę olbrzymie. Biblioteka odwzorowuje natywne SDK poszczególnych platform 1:1 (co ułatwia wyszukiwanie i pozyskanie wiedzy), ale także pozwala na tworzenie widoków identycznie jak jest to robione na iOS i Android (UI pozwala na projektowanie interfejsu pixel perfect). Wydajność również zbliżona jest do natywnych aplikacji (szczególnie w przypadku iOS).

Prócz ogromu zalet jest kilka wad. Niestety pisanie aplikacji wymaga znajomości obu platform od strony natywnej, plus oczywiście znajomość Xamarina. Sam framework bywa także dość chimerny w przypadku podbijania wersji i bez dokładnych testów się nie obędzie.

Tuż po stworzeniu Xamarin Native powstał projekt Xamarin.Forms (2014 r.). W jego założeniu było użycie uniwersalnego języka do tworzenia UI - XAML (ehhh), w celu pisania jednego widoku, który byłby interpretowany na wiele platform (iOS, Android, UWP i inne mobilne). Pomimo kilku wad (mniejsza wydajność niż w przypadku Xamarin Native, większy rozmiar aplikacji) stał się obok starszego brata popularnym frameworkiem do tworzenia mobilnych aplikacji w .NET. Szczególnie, że po śmierci mobilnego Windowsa był niemalże jedynym sensownym sposobem na reużycie kodu .NET w mobilnych świecie.

Xamarin Native nie jest tak łatwy w utrzymaniu, jak Xamarin.Forms ze swoimi wadami, ale to właśnie ten ostatni został skazany na śmierć w roku 2020. Wówczas ogłoszono, że Xamarin.Forms 5.0 będzie ostatnim wydaniem, a jego miejsca zastąpi MAUI

.NET MAUI - nowe stare rozdanie w świecie .NET mobile z poślizgiem

.NET Multi-platform App UI (MAUI) jest nowym pomysłem (w ramach tego artykułu można dodać ponownie) na tworzenie mobilnych aplikacji w .NET. Z boku może wygalać to jak rewolucja, ale dostrzegam to raczej jako ewolucję, a nawet sposób na uporządkowanie istniejącego ekosystemu skupionego wokół Xamarina.

W tym momencie .NET 6 (z korzeniami w .NET 5) będzie ujednolicał runtime, w tym runtime mobilny. Natywny Xamarin dla Androida i iOS (Xamarin.Android, Xamarin.iOS) stanie się częścią .NET 6 (.NET for Android i .NET for iOS). MAUI jako element .NET 6 będzie kolejną ewolucją Xamarin.Forms. Tylko, że jeszcze na to poczekamy.

Premiera MAUI planowana była razem z wydaniem .NET 6 w listopadzie 2021. Niestety ze względu na niesatysfakcjonujący stan prac przesunięta została na bliżej nieokreślone Q2 2022. Dodatkowo możliwe będzie migrowanie projektu z Xamarina na MAUI (Upgrade Assistant), aczkolwiek oby nie skończyło się to tylko na prostych aplikacjach typu "Hello World" (tak, patrzę na ciebie legendarny "migratorze" AngularJs do Angular 2.x ;) ).

Programowanie mobilne w .NET w 2021 - ciągle w rozkroku

Planując nowy projekt mobilny w .NET mamy obecnie na prawdę ciężką sytuację. Do tej pory mieliśmy dość wymagający, ale dający wiele możliwości Xamarin Native lub szybszy w pisaniu, ale wolniejszy w działaniu (rym niezamierzony) Xamarin.Forms. Po ogłoszeniu śmierci Xamarin.Forms i przesuniętej premierze MAUI, nie jest zadaniem trywialnym wybranie frameworku, gdy chcemy stworzyć mobilną apkę w .NET.

Nie da się ukryć, że do tej pory wszystkie próby Microsoftu do technologii mobilnych skończyły na cmentarzysku dobrych, ale nieużywanych technologii. Mobilne systemy operacyjne z Redmond nie przetrwały do obecnych czasów, mimo, że było ich całkiem sporo: cała rodzina Windows Mobile, oba wydania Windows Phone i Windows 10 Mobile. Dodajmy do tego jeszcze technologie mobilne: .NET Compact Framework, Silverlight for Windows Phone, UWA, a nawet uniwersalny UWP idzie w odstawkę. Podobny los za chwilę będzie czekał Xamarin.Forms. MAUI jest tuż za rogiem, chociaż Q2 2022 brzmi bardzo mgliście. Co więcej na GitHubie ciągle jest otwarty wątek/błąd (w momencie pisania tego artykułu) ze zgłoszeniem związanym z problemami wydajnościowymi, gdzie MAUI pod Androida działa wolniej niż Xamarin.Forms, który nie był królem prędkości.

Póki finalny MAUI nie będzie gotowy (a ciągle nie wiemy co z tego wyjdzie i czy wersja 1.0 będzie "ready to prod"), chyba zostaje deweloperom .NET pisanie mobilnych aplikacji (fanboy mode off) we Flutterze...