Dlaczego w KISS digital piszemy mobilne aplikacje natywne? Jakie wady mają technologie hybrydowe, a kiedy warto z nich korzystać? Oto jest pytanie. Na szczęście, potrafimy na nie odpowiedzieć.

W KISS digital piszemy obecnie aplikacje mobilne na wszystkie trzy platformy tylko natywnie, jednak w podjęciu takiej decyzji nie opieraliśmy się jedynie na teorii, ale wynikła ona z naszej wcześniejszej praktyki. Nasze krakowskie biuro pamięta wdrożenia mobilne w technologiach cross-platformowych, i na chwilę obecną uważa je za niegotowe do profesjonalnego wykorzystania.

Rozwiązania cross-platformowe, takie jak Xamarin lub ReactNative, są bardzo dobre w przypadku niewielkich projektów, które wykorzystują podstawowe funkcje urządzeń mobilnych. W przypadku rozbudowanych projektów, bardzo ważną rzeczą jest ich architektura. Aplikacja napisana natywnie pozwala na wybór dowolnej architektury, a dzięki temu rozwój projektu jest możliwie prosty. Standardy te są międzynarodowe i zmiana programisty, czy też całego zespołu, jest możliwa - a aplikacja rozwijana według pierwotnych założeń architektonicznych jest spójna i stabilna. Technologie cross-platformowe pozwalają, a czasem wręcz wymuszają, na mieszanie różnych architektur. To z kolei powoduje, że kod jest przede wszystkim mało czytelny.

Xamarin

Rozpocznijmy głębszą analizę od Xamarina - jest on rozwijany przez Microsoft, który niestety nie tworzy obecnie najpopularniejszego systemu mobilnego. Raczej kroczy on za Androidem i iOS'em, próbując za nimi nadążyć. W tej technologii występują pewne problemy z wydajnością w stosunku do aplikacji natywnych. Sam Xamarin może być wykorzystywany w 2 opcjach: Native oraz Forms. Pierwsza z nich – Native – gdzie programowana jest wspólna logika aplikacji, ale osobno na każdą platformę jest pisany interfejs użytkownika. Druga opcja – Forms – gdzie pisana jest wspólna logika, a także istnieje zaimplementowany wspólny UI, który można samodzielnie nadpisywać, choć jest to bardzo problematyczne.

Jeden z naszych najlepszych programistów, który ma znaczący wpływ na ustalanie strategii rozwoju technologicznego, brał udział w dwóch dużych projektach Xamarinowych. W pierwszym z nich realne koszty wytworzenia aplikacji crossplatformowej zrównały się z estymatami wytworzenia trzech osobnych, natywnych aplikacji. W drugim przypadku natomiast, koszty realizacji przekroczyły znacząco estymaty aplikacji natywnych. Większość czasu zespół poświęcił na szukanie różnych sposobów obejścia rozwiązań proponowanych przez wbudowane moduły Xamarina, zwłaszcza w dziedzinie nawigacji GPS. Sam Xamarin posiada bardzo ubogie biblioteki, a także nie ma możliwości wykorzystywania bibliotek dostępnych dla aplikacji natywnych – oczywiście można je portować, w sposób automatyczny lub ręczny, jednak nakład czasu poświęcony na tę operację jest ogromny.

Ciekawostka - podczas korzystania z Xamarina do kodowania aplikacji wymagane są dwa komputery z różnymi systemami operacyjnymi, ponieważ:

• Mac OS - możemy pisać aplikację pod iOS oraz Android'a
• Linux - możemy pisać aplikację pod Androida
• Windows - możemy pisać aplikację pod Windows Phone oraz Android'a

Niedawno dodano support iOS na systemie Windows, ale nie zostało to w żaden sposób przetestowane przez nas w praktyce.

Przykładowe problemy, z jakimi mierzyliśmy się podczas projektu w Xamarinie:

• ScrollView – zapanowanie nad tym, by zachowywał się zgodnie z oczekiwaniami, jest trudne. Nie można w prosty sposób zrealizować takich elementów jak paginacja, czy scroll do danej pozycji. Finalnie problem został rozwiązany poprzez własną implementacją scrollbara dla każdej z platform.
• ViewPager – przełączanie pomiędzy ekranami za pomocą Swipe. Również nie ma takiej funkcji wbudowanej.
• Brak wielu bibliotek, które wydają się być oczywiste – np. płatności (Braintree, PayPal), wtyczek social (Facebook SDK jest ze stycznia 2015!). Częstym przypadkiem jest także to, że znaleziona biblioteka nie jest wspierana przez najnowszy Xamarin.
• Xamarin Forms obsługuje tylko trzy gesty: Tap, Pinch, Pan. Nie posiada nawet tak prostego gestu jak Swipe.
• Środowisko jest niestabilne. Dwukrotnie (w trakcie trwania jednego z projektów), po aktualizacji Xamarin Studio, przestały działać podstawowe narzędzia developerskie, np. debugger. Również środowisko często blokowało się na kilka godzin sygnalizując, że „coś naprawia”, a efektów nie było widać żadnych. Błąd był naprawiony po kilku minutach, natomiast Xamarin uruchamiał poprzednią wersję aplikacji, zamiast nowej - naprawionej.
• Microsoft ogłosił, że Visual Studio jest środowiskiem do pisania aplikacji pod Xamarina (ma zastąpić Xamarin Studio) z rekomendacją przejścia na Visual Studio. Następnie pojawiła się aktualizacja dla Xamarin Studio, po której połowa funkcji przestała działać, czym wymuszono bardzo brutalnie przejście na Visual Studio.

To tylko część problemów, jakie można napotkać podczas programowania aplikacji mobilnych w Xamarinie. A jak wygląda sytuacja, gdy wybierzemy technologię React Native?

React Native

De facto wykorzystując tę technologię piszemy stronę internetową, która następnie jest interpretowana jako aplikacja mobilna. Używamy technologii webowych takich jak JavaScript, a aby zrealizować to dobrze, kod aplikacji powinien być tworzony przez programistę webowego, a nie mobilnego. Jeżeli aplikacja będzie potrzebowała użyć klas, czy też elementów dostępnych tylko w wybranym systemie operacyjnym (Android, iOS) lub elementów customowych – należy je samodzielnie napisać natywnie, osobno dla każdej z platform. Tę czynność z kolei powinien wykonać programista mobilny. Idealnym wykonawcą byłby programista posiadający zarówno duże doświadczenie w kodowaniu stron internetowych, jak i aplikacji mobilnych - jednak takich osób na rynku pracy jest niewiele, ich stawki są wysokie, a i tak zwykle są oni ekspertami w jednej technologii, drugą znając w mniejszym stopniu.

Czas tworzenia aplikacji w React Native jest stosunkowo długi. Jeżeli tworzymy elementy natywne, musimy je bardzo dobrze przemyśleć i odpowiednio zaprogramować, aby platforma mogła ich prawidłowo używać. Nie jest to jednak największy problem. Znacznie większym są zaawansowane peryferia, typu Bluetooth, czy żyroskop, ponieważ mamy jedynie możliwość wykorzystać to, co daje framework React Native. Nowe funkcje są na bieżąco dodawane, jednak nadal bardzo odstają od możliwości z aplikacji natywnych. Językiem używanym przez React Native jest JavaScript, który posiada wiele wad, np. utrzymanie przejrzystego kodu w dużym projekcie jest nie lada wyzwaniem, a jego wydajność jest znacznie niższa w porównaniu do nowoczesnych języków natywnych – Switf, Java czy Kotlin.

Technologie cross-platformowe vs aplikacje natywne

Technologie natywne istnieją od samego początku platform mobilnych, co oznacza, że są dobrze rozwinięte i doskonale przetestowane. Większość błędów została już wyeliminowana, natomiast rozwiązania cross-platformowe dopiero się rozwijają. React Native otrzymuje duże aktualizacje praktycznie co miesiąc, co oznacza że funkcja zaimplementowana przez nas „dzisiaj”, za miesiąc może już nie być wspierana przez platformę, a w konsekwencji tego, będziemy zmuszeni dany element napisać na nowo.

Z powyższych względów nasz zespół obecnie nie realizuje projektów cross-platformowych. Kalkulacja dla takiej realizacji byłaby równa lub wyższa 3-krotnemu wdrożeniu natywnemu, a w zestawieniu tych faktów ze sporymi problemami w utrzymaniu i rozwoju aplikacji po jej wdrożeniu - jest to wystarczający powód do tymczasowej rezygnacji z technologii cross-platformowych na rzecz natywnych.

Czy technologie cross-platformowe należy jednak odsunąć bardzo daleko? Czy są tak kiepskie i problematyczne, że nie mają prawa bytu w firmach technologicznych? Decyzje, które podjęliśmy, są tymczasowe. Na bieżąco śledzimy rozwój technologii cross-platformowych i upatrujemy w nich przyszłości developmentu mobilnego. I choć obecnie preferujemy aplikacje natywne - czekamy na moment, gdy z dużą pewnością będziemy mogli je zarekomendować naszym klientom.