Aplikacje natywne, hybrydowe, a może webview. Jakie podejście wybrać?

Niedawno prowadziłem rozmowy ze studiem specjalizującym się w aplikacjach mobilnych i otwarłem oczy szeroko ze zdziwienia, gdy dowiedziałem się, że wszystkie ich aplikacje, robione są jako hybrydy. Szybko rozważyłem w głowie dwa scenariusze:

– albo aplikacje hybrydowe dojrzały już do tego poziomu by oferować je klientom jako jedyne rozwiązanie,

– albo firma mając kiedyś kompetencje w tworzeniu stron internetowych (JavaScript) robi relatywnie proste projekty mobilne, dzięki czemu może rozwiązać problemy klientów hybrydami.

Wiele osób, które korzystają z aplikacji mobilnych lub je zamawiają, nie dostrzeże różnicy między tą samą aplikacją napisaną w różnych technologiach, ale dla specjalisty różnica jest zauważalna na pierwszy rzut oka – przede wszystkim w szybkości działania, w możliwości rozwoju aplikacji oraz w niewielkim stopniu UX dla użytkownika. Poniżej zestawiam argumenty za i przeciw responsywnym stronom internetowym (uruchomionym w ramach webview), aplikacjom natywnym i hybrydowym.

Aplikacja typu webview

Aplikacja typu webview to nic innego jak responsywna strona WWW (RWD), zazwyczaj z dodanym menu górnym i bardzo podstawowymi funkcjami, np. logowanie, zmiana języka, informacje o aplikacji etc. Aplikacje tego typu robi się przy minimalnym budżecie, na przykład dla przyzwyczajenia użytkownika. Klienci popularnych marek często szukają aplikacji mobilnej. Przykładem jest słownik angielskiego Diki. Aplikacja wyświetla hasła ze strony WWW. Prawie milion Polaków ściągnęło ją, by nie musieć każdorazowo wchodzić do przeglądarki internetowej w celu skorzystania ze słownika. Ogólny odbiór aplikacji, mimo jego ubogich funkcji jest pozytywny, gdyż pozwala na sprawdzenie hasła, odsłuchanie wymowy itp.

Przykład: słownik diki – aplikacja typu webview, Langmedia

Aplikacja natywna

Aplikacja natywna od początku pisana jest na urządzenia mobilne. W języku Swift dla iOS (dawniej Objective-C ) oraz Java dla Android. Ostatnio popularnosć zyskuje także Kotlin, który ma zbliżoną składnię do Swift). Najłatwiej jest uzyskać spójność z systemem operacyjnym, bo oparte są na natywnych komponentach z Xcode lub Android Studio, w związku z tym będzie oferowało najlepszy wygląd interfejsu oraz UX. Pobierając aplikację natywną, ściągamy także paczkę danych, np. etykiety, tłumaczenia etc. Tylko niektóre elementy są dociągane przez internet. To sprawia, że aplikacja wczytuje dane znacznie szybciej niż aplikacja webowa, potrzebuje mniej danych. Dodatkowo, aplikacja natywna zawiera tylko kod właściwy dla danego systemu operacyjnego, więc urządzenie szybciej je przetwarza. Co ważne, bez dodatkowych wtyczek, możliwe jest korzystanie z wbudowanych funkcji telefonu. Dotyczy to czujników – kamery, mikrofonu, GPS, czujnika linii papilarnych etc. Ale także wbudowanych systemowo kalendarza, kontaktów etc. Korzystanie z nich będzie wymagało zezwoleń, ale zaprogramowanie tego modułu jest najszybsze i najprostsze w przypadku aplikacji natywnej.

Poniżej przykład – aplikacja Zdrojek Woli Wodę (Grupa Żywiec). Aplikacja korzysta z kamery, mikrofonu, by nawiązywać interakcje z użytkownikiem. Zawiera też dużo animacji. Napisanie jej jest znacznie prostsze jako aplikacji natywnej.

Aplikacja hybrydowa

W uproszczeniu – aplikacje hybrydowe tłumaczą kod na języki natywne dla systemu Android i iOS. Mimo dużego postępu we wszystkich tego typu bibliotekach, nadal będzie to wiązało się z koniecznością instalowania wtyczek, dla wykorzystania elementów systemowych lub zaprogramowania elementów jak dla natywnej aplikacji. Jeśli więc aplikacja jest relatywnie prosta i prezentuje dane zaciągane z bazy danych, nie korzysta z wbudowanych funkcji urządzenia. W takim przypadku można stosować aplikacje hybrydowe.

Przykład: Aplikacja Nauka w Polsce, PAP, napisana z wykorzystaniem Ionic

Czy hybrydy zastąpią aplikacje natywne?

Obecnie dostępne są zarówno aplikacje webowe, hybrydowe i natywne. Nie ma na razie dostępnych statystyk, jaka jest proporcja w sklepach Google czy iOS między hybrydami i aplikacjami natywnymi, bo hybrydy są „tłumaczone” przed dodaniem do danego sklepu na język danego systemu operacyjnego. Natywne podejście przeważa tam, gdzie liczy się szybkość działania, stabilność oraz wykorzystanie czujników w telefonach (kamery, mikrofonu, lokalizacji). Popularność hybryd w moim przekonaniu wynika z łatwości ich aktualizowania jak i napisania. Pisząc jeden program, otrzymujemy dwa produkty. Nie bez znaczenia jest również łatwość i koszt utrzymania. Modyfikując aplikację natywną, musimy pamiętać o wprowadzeniu zmian na obie platformy.

Wielu programistów zna JavaScript, wykorzystywany do interaktywnych elementów stron internetowych. To podstawowy język najpopularniejszych frameworków aplikacji hybrydowych – Ionic, React. React został stworzony przez programistów Facebooka, dla ułatwienia rozwoju aplikacji mobilnej. Mimo to dominującym podejściem aplikacji Facebook jest nadal aplikacja natywna. Prawdopodobnie ze względu właśnie na szybkość działania jak i ilość funkcji jakie spełnia. Obecnie aplikacja FB to także trzecia najpopularniejsza przeglądarka internetowa! Jednocześnie niektóre jej elementy są pisane w React.

Wspólny mianownik wszystkich aplikacji

Większość aplikacji mobilnych prezentuje informacje z bazy danych, czyli poprzez API (najczęściej RESTowe). Innymi słowy, pobierają informacje z innych źródeł. Niezależnie więc jakie podejście przeważy, bardzo ważne jest by źródło danych (np. CRM, ERP) z którego pobierasz dane, prezentowało dane w przystępnej i bezpiecznej formie. Doświadczenie uczy, że najwięcej pracy zajmuje stworzenie dobrych punktów styku, z których aplikacja – czy to hybrydowa, czy natywna – będzie korzystała. W przypadku aplikacji webowej, sytuacja jest jasna, bo źródłem danych jest strona WWW.

Jakie podejście wybrać – natywne czy hybrydowe?

Salomonowym rozwiązaniem jest stworzenie aplikacji tylko na jeden system operacyjny. Co jest podejściem często stosowanym dla przetestowania gier czy aplikacji we wczesnej fazie rozwoju. Posiadacze iPhone’ów, mimo że w mniejszości, stanowią o większości wydanych pieniędzy na aplikacje. Wiedzą o tym deweloperzy decydując się czasem tylko na ten system. Jednocześnie, jeśli zależy Ci na szerokim dotarciu i aplikacji bezpłatnej, warto zacząć od Androida. To podejście stosują choćby firmy taksówkowe dla kierowców. Może warto przetestować swój pomysł, zaczynając tylko dla jednego systemu operacyjnego?

Aplikacji mobilnej nie warto tworzyć, jeśli użytkownicy nie będą do niej powracać – na przykład jeśli tylko raz czy dwa wejdą np. celem przeczytania artykułu czy zapisania się na newsletter. Podejście webowe wykorzystaj, jeśli nie planujesz rozwijać aplikacji, a chcesz jednak zaistnieć w sklepach Google i Apple. Jeśli Twoja aplikacja nie korzysta z czujników w telefonie, a chcesz zredukować koszty, pomyśl nad aplikacją hybrydową. Wreszcie, jeśli uważasz, że możesz zaoferować wartość dodaną dla użytkowników poprzez aplikację mobilną, warto zacząć od rozwinięcia jej na jeden system operacyjny. Gdy przetestujesz ją i dopracujesz, możesz przygotować ją także na drugi system operacyjny. Pamiętaj jednak, że najważniejsze jest bardzo dobrze dopracowane źródło danych oraz API, z którego aplikacja (niezależnie czy hybrydowa czy natywna) będzie pobierać dane.

Mam nadzieję, że zdołałem Ci pomóc, a na koniec krótkie podsumowanie tez z artykułu.

Autor

Dr Krzysztof Wojewodzic – ekspert w zakresie aplikacji mobilnych oraz edtech, wspiera korporacje w zakresie strategii IT oraz procesów digitalizacji. Prezes Escola. WWW: krzysztof-wojewodzic.com