Progressive Web Applications – dwie pieczenie na jednym ogniu

Aplikacje internetowe uruchamiane jak zwykłe strony www, ale działające jak natywne aplikacje mobilne będą rewolucją w świecie biznesu. Oszczędzą ich twórcom czasu – i wysiłku.

Ekran telefonu sczytuje linie papilarne. Zgadzają się. „Klient prosi o aktualizację oferty...” – słyszy doradca klienta, prowadząc samochód. Status pochodzi z jego aplikacji PWA i dotyczy otrzymanego powiadomienia push o zbliżającym się spotkaniu biznesowym.

Choć logowanie palcem i pushe to funkcje natywne, aplikacja jakiej używa doradca jest udostępniana przez jego bank na wewnętrznej stronie www i uruchamiana z poziomu ikony na ekranie głównym telefonu.

Odpala się i działa jak aplikacja natywna, choć nią nie jest.

Wizja Steve’a

Niewiele osób pamięta, że jeszcze w 2007 roku Steve Jobs i firma Apple widzieli przyszłość w aplikacjach webowych, a nie – natywnych, czyli tworzonych pod konkretną platformę: Android czy iOS.

A później nastał AppStore. Ale już wtedy na iPhonie można było przypiąć do ekranu głównego aplikację przeglądarkową i uruchomić ją bezpośrednio za pomocą ikony – czyli zrobić to, co robią dziś Progressive Web Applications.

A dziś pokusa ich budowania jest ogromna. Po co tworzyć coś dwa razy, raz pod jeden system operacyjny, raz pod drugi, skoro można to zrobić raz, a dobrze? W dodatku za pomocą popularnych technologii do tworzenia aplikacji webowych…

Wady i zalety

Na rynku jest popyt na aplikacje webowe. Z powodzeniem stosują je banki – w postaci aplikacji hybrydowych. To dlatego, że z punktu widzenia banków rozwiązania natywne mają szereg wad, na które składają się:

• powielenie kompetencji
• powielenie funkcji i konieczność ich utrzymywania
• konieczność dostosowania wszystkich aplikacji do regulacji prawnych
• potrzeba synchronizacji zmian w celu zapewnienia spójności

Powyższe problemy nie dotyczą aplikacji hybrydowych i PWA. PWA ma poza tym szereg dodatkowych zalet. Aplikacje PWA mogą być udostępniane poprzez link. Nie wymagają publikowania w sklepach – unika się dzięki temu dłużyzn w dostawie nowych funkcji i naprawie błędów. Nie ma też ryzyka, że długo będzie trwała sama publikacja, bo sklep odrzuci ją do czasu wprowadzenia poprawek.

Zagrożenie czy szansa?

Można by sądzić, że PWA są zagrożeniem dla właścicieli sklepów z aplikacjami. Ale jak pokazują dane SensorTower, dla Apple i Google PWA stanowią około 20% przychodów. Ponadto, w roku 2019 68%  przychodów AppStore pochodziło z gier. Natomiast dla Google Play gry stanowiły aż 84% przychodów. Stąd wynika, że brak aplikacji biznesowych w sklepach nie jest realną groźbą dla internetowych gigantów.

Trzeba jednak dodać, że Apple goni rynek jeśli chodzi o PWA. Przykładem może być np. brak obsługi odcisku palca w systemie iOS. Jest to związane z tym, że PWA nie korzysta z natywnych funkcji urządzeń w formie rozszerzeń – jak to robi hybryda – ale działa w oparciu o aktualne możliwości przeglądarki.

Wciąż zdarza się, że sklepy niechętnie patrzą na aplikacje hybrydowe, które nie korzystają z natywnych funkcji urządzeń. Pokutuje stereotyp aplikacji hybrydowej będącej obejściem obowiązujących reguł gry; „ramką” dla treści przeglądarkowych. PWA zmienia to myślenie i jednocześnie tworzy przestrzeń dla aplikacji webowych na urządzenia mobilne.

Do PWA jeden krok

Podstawą dla PWA jest Responsive Web Design (RWD) czyli technika projektowania strony tak, aby jej wygląd i układ dostosowywał się automatycznie do rozmiaru okna przeglądarki.

Nasze doświadczenia z prac nad systemem Comarch Corporate Banking (bankowość internetowa dla korporacji i SME) pokazały, że koszt realizacji  RWD to kilka do kilkunastu procent całkowitych kosztów wytworzenia oprogramowania – czyli relatywnie niedużo w stosunku do kosztów wytworzenia dwóch aplikacji natywnych.

A ponieważ od RWD jest tylko krok do PWA, już dziś można znaleźć wiele udanych wdrożeń PWA takich światowych marek jak: AliExpress, Alibaba, Flipkart, Twitter, czy Trivago.

Kolej na bankowość

To pokazuje, że czas PWA w bankowości też nadejdzie. Pierwszym zastosowaniem mogłyby być aplikacje mobilne przeznaczone dla pracowników banku – np. dla doradców klienta biznesowego. Takie aplikacje usprawniałyby ich pracę: porządkowały informacje dotyczące spotkań z klientami, analizowały potrzeby klientów, pomagały podtrzymywać relacje biznesowe z nimi.

Inne zastosowanie to aplikacje przeznaczone dla klientów banków. Aktualnie większość banków wprowadziła RWD w swoich aplikacjach dla bankowości internetowej. Jeden z powodów jest taki, że zazwyczaj nie wszystkie funkcje są dostępne w wersji natywnej takich aplikacji. Nie da się np. zmienić limitów na kartach, negocjować kursów walut czy delegować uprawnień innemu pracownikowi.

Z punktu widzenia banku, rozsądne kosztowo i operacyjnie może być udostępnianie niszowych funkcji i specyficznych produktów jako rozwiązań RWD, zwłaszcza w przypadku firm.  Rynek musi jednak do tego jeszcze dojrzeć.

Maciej Bachmiński, Product Owner, Comarch