Wraz z biegiem czasu obserwujemy stale rosnącą rolę urządzeń mobilnych w naszym życiu. Wychodząc od przenośnej skrzynki pozwalającej na wykonanie połączenia głosowego z dowolnego miejsca, telefony spełniają coraz więcej funkcji. Obecnie trudno wyobrazić sobie sferę życia, w której smartfon nie służyłby pomocą. Komunikacja, socjalizacja, zakupy, bankowość czy umawianie wszelakich wizyt stało się dostępne (dosłownie!) na wyciągnięcie ręki.
Jak tworzyć takie aplikacje? Natywnie czy cross-platformowo? Przy więcej niż jednej powszechnie używanej platformie, to pytanie, od którego warto zacząć planowanie pracy. Każdy z tych wyborów niesie za sobą określone konsekwencje.
Aplikacje natywne
Są to aplikacje budowane z myślą o jednej, konkretnej platformie mobilnej. Jeśli naszą grupą docelową są zarówno użytkownicy Androida i iOS-a, oznacza to w praktyce konieczność prowadzenia dwóch równoległych projektów.
Aplikacje cross-platform
Żeby uniknąć zwielokratniania pracy poprzez tworzenie niezależnych aplikacji na każdą platformę, możemy użyć cross-platformowych „nakładek”. Z ich pomocą możemy stworzyć jedną bazę kodu źródłowego działającą na Androidzie, iOS-ie, jak i ewentualnych innych platformach.
Proces i koszt wytworzenia
Możliwość utrzymywania jednej wersji kodu stanowi zdecydowaną zaletę rozwiązań cross-platform. Mniejszy nakład pracy związany z projektowaniem aplikacji, wspólny dla wszystkich platform interfejs użytkownika, jeden zespół skupiający się na jednej technologii. Zarówno koszt, jak i czas realizacji takiego projektu będzie niższy, niż przy konieczności realizowania kilku projektów równolegle (bądź sekwencyjnie, jeśli nie posiadamy zasobów).
Włączając testowanie aplikacji natywnych w proces wytwórczy, zespół oddelegowany do pracy nad daną platformą może skupić się na testowaniu tylko tego, z czym pracuje. Równoległa praca pozwoli może skrócić czas testowania. Przy cross-platform, zespół powinien testować aplikację równolegle na wszystkich wspieranych platformach dla zapewnienia wymaganego poziomu jakości.
Poza samym kosztem realizacji projektu, warto nie zapominać o późniejszym utrzymaniu aplikacji. Ewentualnie modyfikacje czy nowe funkcjonalności muszą być rozpropagowane dla wszystkich wspieranych platform, co ma istotny wpływ na nakład pracy przy kilku rozwiązaniach natywnych.
Wydajność, API urządzenie
Aplikacje cross-platform stanowią „nakładkę” na aplikację natywną. Co z tego wynika? Aplikacje natywne będą lżejsze, wydajniejsze, łatwiejsze do zoptymalizowania. Zajmują też mniej miejsca w pamięci. Moc obliczeniowa oferowana przez współczesne urządzenia mobilne jest na tyle duża, że ta różnica może być niezauważalna acz w wybranych projektach może być to kluczowe. Natywnie łatwiej też jest o pełne wykorzystanie potencjału urządzenia – nic nie ogranicza dostępu do natywnego API czy funkcji takich jak lokalizacja, aparat czy żyroskop. Pracując cross-platformowo, operujemy na tym, co dostarczy nakładka/framework bądź community – może oznaczać to brak dostępu (albo utrudniony dostęp) do części funkcji.
Bezpieczeństwo aplikacji
Pracując z aplikacjami natywnymi, mamy pełny wgląd w to, z czego korzystamy. Łatwiej jest nam skonfigurować i zabezpieczyć taką aplikację. Jesteśmy podatni na znane ataki, acz będąc świadomym zagrożenia, możemy podjąć kroki w celu zapewnienia możliwie wysokiego poziomu bezpieczeństwa.
Cross-platform do potencjalnych podatności natywnych dokłada podatności właściwe dla platformy, z której zdecydujemy się skorzystać. Mogą być to biblioteki czy rozwiązania webowe. Z drugiej strony, zabezpieczyć wystarczy tylko jedną aplikację. Pracując natywnie, każda z tworzonych przez nas aplikacji może mieć własne, zupełnie różne podatności.
Spójny interfejs użytkownika
Jeden wspólny kod źródłowy może (acz nie musi) oznaczać też jeden wspólny projekt graficzny naszej aplikacji. Nie musi – z racji różnic w samym interfejsie natywnym. Różnice w standardach czy sugestiach projektowania interfejsu między Androidem a iOS są spore. Desktop czy web to potencjalnie zupełnie oddzielna część projektu – projekt mobilny na ekranie full hd może być nieprzyjemny dla oka. Frameworki cross-platformowe wspierają tworzenie interfejsu zgodnego z natywnym standardem. Może nie być to jednak całkowicie zgodne między platformami. Chcąc to dostosować do naszych wymagań, możemy potrzebować dodatkowych kawałków kodu specyficznego dla platformy.
Przegląd technologii
Programując natywnie, nasz wybór jest ograniczony. Dla Androida, możemy zdecydować się na Kotlina, Javę czy C++ (natywny software development kit). Dla iOS nasze opcje to Objective-C i Swift.
Z rozwiązań cross-platform, warto zwrócić uwagę na:
– Flutter – https://flutter.dev/
– React Native – https://reactnative.dev/
– Kotlin Multiplatform Mobile [Beta] – https://kotlinlang.org/lp/mobile/
Podsumowanie
Wybór rozwiązania idealnego dla naszego zapotrzebowania nie jest oczywisty. Konieczne jest przeanalizowanie, co jest dla nas najważniejsze. Wydajność? Szybkość i koszt realizacji projektu? Spójność? Dostęp do funkcji natywnych?
Jeżeli założeniem naszej aplikacji jest możliwie wysoka wydajność (przykładem, ma działać na urządzeniach o ograniczonej mocy obliczeniowej, bądź rodzaj danych wymaga dużej dokładności), jeśli nasz projekt interfejsu opiera się silnie na założeniach natywnych, jeśli chcemy korzystać z samego urządzenia (nawigacja, kamera, żyroskop..) – możemy chcieć wybrać rozwiązania natywne.
Jeśli potrzebujemy dostarczyć rozwiązanie na wiele platform szybko, bądź nie mamy wystarczająco dużo zasobów, żeby podzielić prace natywne, a nasza aplikacja jest raczej prosta (odpowiednik strony webowej na urządzenia mobilne), frameworki cross-platform mogą nam bardzo pomóc.