Progresywne aplikacje w końcu na iPhonie? Apple mniej zarobi na App Store

Podejście Apple do aplikacji webowych było przez te wiele latwręcz negatywne – i nic dziwnego, biorąc pod uwagę na setkimilionów dolarów zarabiane na zamkniętym ekosystemie natywnychaplikacji dostępnych oficjalnie tylko przez AppStore. Webukontrolować się tak nie dało, więc Apple robiło wszystko, by doWebu użytkowników zniechęcić. Mobilne Safari jako jedynadopuszczona przeglądarka na iOS-a była taka sobie, a gdy w końcufirma z Cupertino dała zielone światło przeglądarkomkonkurencyjnym, to postarała się, by działały one gorzej. Tylkomobilne Safari miało dostęp do szybkiego silnika JavaScriptu Nitro,konkurencja musiała zadowolić się systemowym, powolnym komponentemUIWebView. Własny silnik? O tym w ogóle zapomnijcie – takie urokiżycia w niewoli.

Dopiero iOS 8 przyniósł poprawę sytuacji, deweloperzy dostaliznacznielepszy komponent WKWebView.Pod względem obsługi standardów webowych przynosił on wnajważniejszych kategoriach to samo, co oferowało Chrome naAndroida. Był to jednak 2014 rok, a technologie webowe jakoś niechciały stanąć w miejscu.

W 2015 roku inżynierowie Google’a zaproponowali standardProgressiveWeb Apps. Nowa generacja aplikacji webowych miała błyskawiczniesię ładować, nawet w nie najlepszych warunkach sieciowych, działaćbłyskawicznie, z responsywnością porównywalną do aplikacjinatywnych i oferować taki sam dostęp do zasobów sprzętowych, coaplikacja natywna. Ikonka przypięta do pulpitu, jedno dotknięcie –i właściwie dla zwykłego użytkownika nie ma różnicy, czykorzysta z natywnej aplikacji ze sklepu, czy też aplikacjiprogresywnej z przeglądarki.

By jednak aplikacje progresywne mogły działać na urządzeniu,silnik skryptowy musi wspierać m.in. interfejs programowania ServiceWorkers. API to umożliwia uruchamianie sterowanych zdarzeniamiskryptów w tle oraz zarządzanie ich instalacją i działaniem.Aplikacje progresywne wykorzystują Service Workers do pobieraniazbuforowanych treści, dzięki czemu mogą działać nawet bezpołączenia sieciowego.

Od samego początku na rozwiązanie to stawiało Google, dlaktórego szybki i dynamiczny Web to wręcz biznesowa misja. Wsparcieprzyszło też ze strony Mozilli i Opery, a w końcu Microsoftprzyznał, że aplikacje progresywne pasują do jego strategii „CloudFirst Mobile First”. Apple? No cóż, Apple nie zauważało tejgroźnej herezji tak długo, jak to tylko było możliwe. Kto towidział, by aplikacja webowa działała równie dobrze jak natywna?I niestety zdania Apple nie można było zlekceważyć. Nanajważniejszych rynkach iPhone jest najważniejszym smartfonem,numerem 1., bez wsparcia na iPhonie żadna mobilna technologia nieprzejdzie.

24 lipca Greg Blass, programista z Filadelfii, opublikowałna swoim blogu surowy w wymowie artykuł, w którym stawia tezę, żeodmowa wsparcia aplikacji progresywnych przez Apple to uszczerbek dlaprzyszłości webu. Wyjaśnia tam dlaczego Safari nawet nie zbliżyłosię do obsługi niezbędnych standardów, a jego trybpełnoekranowy dla Safari jest pełen niedoróbek. W końcu piszeotwarcie: dla Apple aplikacje webowe to obywatele drugiej kategorii,ponieważ nie przynoszą pieniędzy ze sprzedaży w App Store.

Artykuł wzbudził ogromny odzew w społeczności – inajwyraźniej zawstydził menedżerów Apple. Nagle na liście pracdeweloperskich silnika WebKit dla funkcjonalności Service Workerspojawiło się oznaczenie In Development. Żadnych konkretów niepodano, ale można się spodziewać, że zawita ono do iOS-a 11, jakoistotna funkcja, którą można się pochwalić. Samo Service Workersto oczywiście nie wszystko, ale zarazem jest to sygnał, że firma zCupertino już się tak nie wzbrania przed aplikacjami spoza AppStore.

Dla deweloperów będzie to miało ogromne konsekwencje. Dzisiajmarnuje się wiele sił i środków na pisanie aplikacji na trzypodstawowe platformy: Android, iOS oraz web. Możliwość napisaniajednej progresywnej aplikacji, działającej na wszystkichplatformach w sposób, który zadowoli większość użytkownikówpozwoli ten czas poświęcany na rozdrabnianie się przeznaczyć narozwój samej aplikacji. Być może zmniejszy to liczbę aplikacjinatywnych w sklepach Google’a czy Apple’a, ale czy naprawdępotrzebujemy, by każdy durny przewodnik po muzeum czy aplikacja dozamawiania pizzy były aplikacjami natywnymi? Na pewno iOS SDK orazAndroid SDK dalej będą miały swoje miejsce, ale po rozwiązanianatywne będzie się sięgało tylko wtedy, kiedy będzie to naprawdęniezbędne.