Felépítettem egy Progressive Web App alkalmazást, és 3 alkalmazásboltban tettem közzé. Itt van, amit megtanultam.

Egy hónap munka, több száz dollár és sok bürokrácia.

Nemrég a Chavah Messianic Radio, egy Pandora-szerű zenelejátszót tettem közzé Progresszív Webalkalmazásként, és beküldtem a 3 alkalmazásboltba (Google Play, iOS App Store, Windows Store).

A folyamat egyszerre volt fájdalmas és megvilágosító. Itt van, amit megtanultam.

Miért?

Először is elgondolkodhat: „Miért is tenné fel az alkalmazását az alkalmazásboltokba? Csak éljen a megnyitott interneten! ”

A válasz dióhéjban azért van, mert ott vannak a felhasználók . A felhasználók egy generációját képeztük arra, hogy alkalmazásokat saját tulajdonú alkalmazásboltokban találjon, ne pedig az ingyenes és nyitott interneten.

A webalkalmazásomnak két nagy oka volt, hogy bekerüljek az App Store-ba:

  1. Felhasználói igény
  2. Webalkalmazás-korlátozások az Apple ellenséges mobilplatformok által

Felhasználói igény: A felhasználóim évek óta kérdezik tőlem: „Van-e alkalmazás a Chavah-hoz? Nem látom a boltban.

Ezt azért kérik, mert kiképeztük a felhasználókat arra, hogy saját tulajdonú alkalmazásboltokban keressenek alkalmazásokat.

A felhasználóimnak eddig válaszoltam,

„Hoppá, nincs szükséged alkalmazásra - csak menj a telefonra a weboldalra! Működik!"

De valahogy hazudtam.

A valódi webalkalmazások csak kinda-sorta működnek mobilon. Ez a 2. okhoz vezet: az Apple ellenséges mobilplatformok általi webalkalmazás-korlátozásokhoz.

A mobilplatform-gyártók, például az Apple, nagyon ügyesek az alkalmazásokkal , amelyek teljességgel használják a telefont. Hozzáférés a tartózkodási helyéhez, háttérhang lejátszása, GPS-koordináták megszerzése, egyszerre több dolog lejátszása és még sok más.

Az Apple nagyon jó ezzel.

De csak akkor, ha az Apple számára évi 99 dollárt fizet a kiváltságért.

Ha ezeket a dolgokat egy szokásos régi webalkalmazásban szeretné megtenni, nos, goshdarnit, az Apple nem csak megtagadja ezeket a dolgokat, hanem megakadályozza, hogy engedélyt is kérjen .

A Pandora-szerű zenelejátszó alkalmazásomnál ez a borzalmas közvetítés számos módon megmutatkozott.

Az olyan apró dolgoktól kezdve, mint például: „Az iOS Safari nem engedi meg, hogy hangot játsszon le anélkül, hogy előbb interakcióba lépnél az oldallal”, egészen az olyan nagyszerű, műsorokat megállító dolgokig, mint például: „Az iOS Safari nem engedi eljátszani a következő dalt, ha az alkalmazás a háttérben van, vagy ha a képernyője ki van kapcsolva. ”

Ó, plusz olyan furcsa vizuális anomáliák, mint a szövegmezőbe történő beírás és a szöveg máshol való megjelenése a képernyőn.

Tehát ahhoz, hogy a HTML5 zenei alkalmazásom valóban működőképes legyen, és az emberek mobileszközein működjön, szükség volt arra, hogy a PWA-m az App Store alkalmazásává váljon.

A belépési korlátok

Az ideális világban a webalkalmazás közzététele az alkalmazásboltokban a következőképpen néz ki:

  • Web / Cloud Host vagy folyamatos integrációs szolgáltató
  • Ön közzétett egy progresszív webalkalmazást. Közzéteszi az alkalmazásboltokban?

☑ iOS App Store

☑ Google Play

☑ Windows Store

(Vagy felváltva, amint a Microsoft kísérletezik, a PWA-ja csak automatikusan megjelenik az App Store-ban, amikor a Bing feltérképezi.)

De sajnos nem ebben az ideális világban élünk. Ehelyett mindenféle saját, natív BS-sel kell megküzdenünk, hogy webalkalmazásainkat az üzletekbe szerezzük.

Mindegyik alkalmazásbolt akadályozza a belépést: mennyire nehéz egy meglévő webalkalmazást és azt az alkalmazásboltba venni.

Az alábbiakban felsorolok néhány akadályt.

Költség

  • Apple : 99 dollár / év, hogy az alkalmazásod szerepeljen az iOS alkalmazásboltban.
  • Google: egyszeri 25 dolláros díj az alkalmazás Google Play Áruházban történő listázásáért.
  • Microsoft: Ingyenes!

Ne kényszerítsen arra, hogy fizessek neked, hogy elérhetővé tegyem az alkalmazásomat a felhasználók számára. Az alkalmazás gazdagítja a platformot. Jó alkalmazások nélkül a platformod elhagyásra kerül.

Az Apple ezt szokta megérteni. Amikor először mutatta be az iPhone-t, Steve Jobs határozottan állította, hogy a HTML5 a jövő, és hogy az alkalmazások egyszerűen csak webalkalmazások lesznek. Nem volt natív iPhone SDK harmadik felek számára. Az Apple azóta elhagyta ezt a jövőképet.

A Google jelképes 25 dolláros egyszeri díjat kért. Valószínűleg azért, hogy elkerülje a spamküldőket és csökkentsék a valóban ócska alkalmazások belépését az üzletbe.

Úgy tűnik, a Microsoft eltökélt szándéka, hogy minőségétől függetlenül csak növelje az alkalmazásboltjukban található alkalmazások számát.

Nyertes: Microsoft. Nehéz verni szabadon.

Natív képességek hozzáadása

Ideális világban nem kellene egyetlen külön kódsort írnom ahhoz, hogy webalkalmazásom integrálódhasson az operációs rendszerbe. Vagy ahogy Steve Jobs még 2007-ben elmondta,

„A teljes Safari motor az iPhone belsejében található. Így csodálatos Web 2.0 és Ajax alkalmazásokat írhat, amelyek pontosan úgy néznek ki és pontosan úgy viselkednek, mint az iPhone-on található alkalmazások. Ezek az alkalmazások tökéletesen integrálhatók az iPhone szolgáltatásaival. Hívhatnak, e-mailt küldhetnek, és helyet kereshetnek a Google Maps-en. ” -Steve Jobs, 2007

Számomra ez azt jelenti, hogy a webalkalmazásom háttér hangot játszik le HTML5 hang használatával; ez minden operációs rendszeren remekül működik.

A webalkalmazásom kijelenti, hogy milyen hangot játszik le, és az operációs rendszerek ezt felveszik, és a lezárási képernyőn megmutatják az éppen lejátszott dalok adatait.

Az alkalmazásom a szabványos HTML5 audio API segítségével irányítja a hangot; az operációs rendszer ezt felveszi, és a lejátszás / szünet / következő / hangerő / trackbar vezérlőket biztosítja a lezárási képernyőn.

De sajnos nem ebben az ideális világban élünk. A fent felsorolt ​​összes dolog valójában nem működik a dobozból mindhárom platformon.

A webalkalmazásomnak hangot kell lejátszania a háttérben. És töltsön be URL-eket a CDN-ről. Ésszerűen hangzik, igaz? És bónusz, mit szólnál ahhoz, ha az éppen lejátszott dalinformációkat megjelenítenéd a zár képernyőn? És a hang vezérlését (lejátszás / szünet / következő, stb.) A lezárási képernyőről? Mennyire nehéz ez?

Három nagyon különböző megközelítés van itt:

  • Apple : Nem adunk módot a webalkalmazásoknak az ilyen képességek deklarálására; írnia kell egy natív csomagolást (pl. a Cordovával), hogy kapcsolatba léphessen az operációs rendszerrel.
  • Google : Web FTW! Hozzunk létre egy új webes szabványt, amely a hangot és a vezérlőket mutatja a lezárási képernyőn. Háttérhang? Persze, csináld!
  • Microsoft: A saját API-junkat, az window.Windows. * -Ot beinjektáljuk a JavaScript globális névterébe, és ezt felhasználhatja a kívánt dolgok elvégzésére.

További részletek itt az egyes üzletekről:

Az iOS alkalmazásboltban a webalkalmazásnak háttérhangot kell lejátszania? Használjon Cordova plugint. Meg kell jelenítenie az éppen lejátszott dalt a zár képernyőn? Használjon Cordova plugint. A zár képernyőn kell irányítania az éppen lejátszott dalt? Használjon Cordova plugint. Megkapja az ötletet. Alapvetően Cordova becsapja az Apple-t, hogy azt gondolja, hogy natív alkalmazás. És mivel nem vagány webalkalmazás vagy, az Apple lehetővé teszi, hogy a natív alkalmazások mindent megtegyenek. Csak natív trükkökre - Cordova beépülő modulokra - van szüksége, hogy ezt megtehesse.

A Google Play számára nagyon jó, hogy csak JS-kódot tudok írni, hogy ez működjön; itt nincs szükség Cordova bővítményekre. Természetesen ez a JS sehol sem fog működni, kivéve az Androidos Chrome-ot ... de hé, talán egyszer (egy ideális világban!) Az összes mobil böngésző megvalósítja ezeket a webes API-kat ... és a világ egyként fog élni. Már majdnem kész vagyok lebuktatni néhány John Lennon hippi utópia dallamot.

Windows Store esetén szeretne háttérhangokat lejátszani? Sajnálom! Vagyis, hacsak nem nyilatkozik szándékairól a saját tulajdonú képességek nyilvántartási fájlunkban ( könnyű) ÉS ezt a saját médiafelületet az window.Windows.SystemMediaTransportControls használatával valósítja meg (nem olyan egyszerű). Ellenkező esetben elnémítjuk, ha az alkalmazás háttérbe kerül.

Nyertes : Google. Szeretném, ha csak JavaScriptet írhatnék, és hagynám, hogy az operációs rendszer felvegye a jeleket az alkalmazásomból.

Második helyezett : Windows. Még mindig tudok sima régi JavaScript-et írni, de beszélnem kell egy saját Windows JS API-val, amelyet a Windows rendszeren történő futtatáskor fecskendeztek be a folyamatomba. Nem szörnyű.

Vesztes : Apple. Nem érdeklik őket a webalkalmazások. Valójában ennél rosszabb. Olyan érzés, mintha valóban ellenségesek lennének a webalkalmazásokkal szemben . Az iOS Safari az új Internet Explorer 6. Szinte minden webes szabványban elmaradt, különösen a Progresszív Webalkalmazások körül. Ez valószínűleg üzleti okokból történik: a webalkalmazások megzavarják az évi 99 dolláros + 33% -os alkalmazáson belüli vásárlási ütemet. Tehát ahhoz, hogy a webalkalmazásom működjön a platformjukon, alapvetően úgy kell tennem, mintha natív alkalmazás lennék.

App Store regisztráció

Ha elküldi a PWA-t az alkalmazásboltba, regisztrációra, üzleti ellenőrzésre és további bürokráciára van szükség. Így teljesített a 3 alkalmazásbolt:

  • Apple : Bizonyítania kell, hogy legális, bejegyzett vállalkozás. Ezt az ellenőrzést nem mi, hanem egy harmadik fél végzi, amely lehet, hogy nem tud a vállalkozásáról.
  • Google : Szeretné az alkalmazását az üzletünkben? Hűvös általunk.
  • Microsoft : Szeretné az alkalmazását az üzletünkben? Hűvös általunk.

Számomra a legnagyobb fájdalmat az jelentette, hogy legális vállalkozásként igazoltam az Apple-t.

Először felkerestem a webhelyet és regisztráltam az Apple fejlesztői programjába. Kitöltöttem a nevemet és a cég adatait. (Eltekintve: azt hiszem, az Apple nem engedi meg, hogy beküldjön egy alkalmazást, hacsak nincs regisztrált, legális cége?)

Kattanok tovább.

"A megadott információk nem egyeztek a D&B profiljával."

Az én mim?

Egy kis guglizás megmutatta, hogy a „D&B profil” Dun és Bradstreet. Még soha nem hallottam erről a csoportról, de megtudtam, hogy az Apple felhasználja őket a vállalat jogi adatainak ellenőrzésére.

És nyilvánvalóan a D&B profilom nem egyezett meg azzal, amit az Apple Dev regisztrációmba tettem.

Még guglizok, és megtalálom az Apple fejlesztői fórumokat, amelyek tele vannak hasonló bejegyzésekkel. Senkinek nem volt jó válasza.

Felveszem a kapcsolatot az Apple Dev ügyfélszolgálatával. 24 órával később e-mailben lépnek kapcsolatba velem, hogy vegyék fel a kapcsolatot a D&B-vel.

Úgy döntök, hogy felveszem velük a kapcsolatot ... de az Apple szerint néhány napba telik, mire válaszolnak.

Ezen a ponton azon gondolkodom, hogy felhagyok az egész ötlettel.

Amíg arra várok, hogy a D&B támogatás visszajusson hozzám, úgy döntök, hogy elmegyek a D&B webhelyére, igazolom a személyazonosságomat, és frissítem a vállalatom adatait, amelyeket feltételezem, hogy az állami nyilvántartásokból vettek át.

Megemlítettem, hogy ez milyen szopós? Csak a meglévő webes alkalmazásomat szeretném felsorolni a boltban. Plz segítség.

A D&B-hez megyek frissíteni az üzleti profilomat. Meglepetés! Az ellenőrzési logikájukban van egy JavaScript-hiba, amely megakadályozza, hogy frissítsem a profilomat.

Szerencsére jártas fejlesztő vagyok. Rákattintok, hogy egy töréspontot tegyek a JavaScript-be, rákattintok a beküldésre, megváltoztatom az isValid jelzőt igazra, és voila! Frissítettem a D&B profilomat.

Vissza az Apple Dev oldalra -> próbáljuk újra. Cégem regisztrálása ...

„Hiba: A megadott információk nem egyeztek az Ön D&B profiljával.”

AREYOUFREAKINKIDDINGME.

Beszéljen újra az Apple-lel. "Ó, 24–48 órába telhet, amíg a friss D&B információk bejutnak a rendszerünkbe."

Tudja, mert a digitális információk eltartása 2 napot vehet igénybe az A szerverről a B szerverre. Sóhaj.

Két nappal később megpróbálok regisztrálni ... végre működik! Most az Apple Developer programban vagyok és alkalmazásokat nyújthatok be felülvizsgálatra.

Nyertes : Google és Microsoft; mindkettő 5 percet vett igénybe a regisztrációhoz.

Vesztes : Az Apple Developer regisztráció lassú és fájdalmas volt. Körülbelül egy hétbe telt, mire valójában regisztrálták magukat a fejlesztői programjukba. Megkövetelte, hogy vegyem fel a kapcsolatot két különféle furcsa vállalat támogatásával. És ez megkövetelte, hogy futás közben hibakeresjem a harmadik fél webhelyén található JavaScript-kódot, csak azért, hogy túlléphessem a hibás kliensoldali ellenőrzést, hogy az információim az Apple-hez jussanak, hogy elküldhessem az alkalmazásomat az üzletbe. Wow, csak… wow.

Ha van itt valami megtakarítási kegyelem az Apple számára, az az, hogy van egy 501c3 nonprofit programjuk, ahol a nonprofit szervezetek elengedhetik 99 dolláros éves díjukat. Ezt kihasználtam. És talán ez a plusz lépés bonyolult.

App csomagolás, építés, benyújtás

Ha van webalkalmazása, akkor varázslatot kell futtatnia rajta, hogy olyanná váljon, amelyet beküldhet az App Store felülvizsgálatra.

  • Apple : Először vásároljon Mac-et; nem készíthet iOS alkalmazást Mac nélkül. Telepítse az XCode-ot és ezeket az összeállító eszközöket és keretrendszereket, szerezzen tanúsítványt a fejlesztői programunkból, hozzon létre egy profilt az iTunes Connect nevű külön weboldalon, kapcsolja össze az Apple Dev központban létrehozott tanúsítvánnyal, majd küldje be az XCode használatával. Könnyű, mint egy, kettő, három ... harminchét ...
  • Google : Töltse le az Android Stúdiót, generáljon rajta egy biztonsági tanúsítványt, majd csomagolja be a Studio segítségével. Töltse fel a csomagot az Android fejlesztői webhelyre.
  • Microsoft : Hozzon létre egy .appx csomagot az ingyenes parancssori eszközök vagy a Visual Studio használatával. Feltöltés a Microsoft Dev Center webhelyére.

A jó hír az, hogy van egy ingyenes eszköz, amellyel varázsolhatja a webalkalmazást alkalmazáscsomagokká . Ezt a fantasztikus ingyenes eszközt PWABuilder-nek hívják. Elemzi az URL-t, megmondja, mit kell tennie (pl. Hozzáadhat néhány kezdőképernyő ikont a PWA webes jegyzékéhez). A háromlépcsős varázsló segítségével lehetővé teszi az összes varázslatot tartalmazó csomagok letöltését:

  • Windows esetén valóban létrehozza az .appx csomagot. Szó szerint ezt megteheti, és elküldheti a Windows Dev Center webhelyén.
  • A Google számára létrehoz egy burkoló Java alkalmazást, amely tartalmazza a PWA webalkalmazást. Az Android Studio alkalmazásból Ön készíti el ezt a projektet, amely létrehozza az Android Dev csomagot, amely feltölthető az Android Dev Center webhelyére.
  • Az Apple számára generál egy XCode projektet, amely XCode segítségével építhető fel. Amihez Mac szükséges.

Ismét az Apple volt a legfájdalmasabb ezek közül. Nincs Mac-em. De Mac nélkül nem lehet elkészíteni az XCode projektet a PWA-hoz.

Nem akarok több ezer dollárt fizetni azért, hogy ingyenes alkalmazásomat közzétegyem az Apple alkalmazásboltjában. Nem akarok fizetni az Apple iOS platformjának gazdagításáért járó kiváltságért.

Szerencsére a MacInCloud körülbelül 25 dollárba kerül havonta, és adnak egy Mac gépet, amelyre már telepítve van az XCode. A Windows Távoli Asztal használatával távoli lehet, vagy akár webes felületen keresztül is.

Nem volt elég csak elkészíteni az XCode projektet és beküldeni. Létre kellett hoznom egy biztonsági tanúsítványt az Apple Developer webhelyén, majd létre kellett hoznom egy új alkalmazásprofilt egy külön webhelyen, az iTunes Connect alkalmazásban, ahova ténylegesen beküldte a csomagot.

És ez még nem minden: mivel az Apple ellenséges a webalkalmazásokkal szemben, telepítenem kellett néhány speciális keretrendszert, és hozzá kellett adnom Cordova beépülő modulokat, amelyek lehetővé teszik az alkalmazásom számára, hogy olyan dolgokat hajtson végre, mint például a háttérben történő hanglejátszás, az aktuális dal hozzáadása a zárolási képernyőhöz, vezérelheti a dal hangerejét és lejátszási állapotát a lezárási képernyőről stb.

Ez legalább egy hétig tartó finom kidolgozást igényelt, hogy alkalmazásom működőképes állapotba kerüljön, mielőtt beküldhetném az alkalmazásboltba.

Nyertes : Microsoft. Képzelje el ezt: elmehet egy olyan webhelyre, amely alkalmazáscsomagot generál a webalkalmazásához. És ha ez nem a te dolgod, letölthetsz parancssori eszközöket, amelyek elvégzik a munkát. GUI személy? Az ingyenes Visual Studio működni fog.

Második helyezett : Google. Szüksége van Android Studio-ra, de ingyenes, mindenkit futtat, és elég egyszerű volt.

Vesztes : Apple. Nem kellene megvásárolnom egy saját számítógépet - több ezer dolláros Mac-et - az alkalmazás elkészítéséhez. Az Apple Dev Center -> Az iTunes Connect összekeveredése érintés nélküli kezelői kísérletnek tűnik, hogy az iTunes-ot a fejlesztőkre tolja. Egyszerűen az Apple Developer Center webhelyének kell lennie.

App Testing

Miután végre megtett minden varázsigét, hogy meglévő webalkalmazását mobilalkalmazás-csomaggá alakítsa, valószínűleg ki szeretné küldeni a tesztelőknek, mielőtt kiadná az alkalmazását a mosatlan tömegeken.

  • Apple : A teszteléshez tesztelőit telepítenie kell a Test Flight-ot az iOS-eszközükre. Ezután hozzáadja a tesztelő e-mailjét az iTunes Connect alkalmazásba. A tesztelő értesítést kap, és tesztelheti az alkalmazását, mielőtt az elérhető lenne az App Store-ban.
  • Google : Az Android Dev Centerben tesztelők e-mail címeit adja hozzá. A hozzáadás után láthatják az alfa / béta verziót az App Store-ban.
  • Microsoft : Valójában nem ezt használtam, ezért nem kommentálom.

Nyertes : Dobd fel. Az Apple Test Flight alkalmazás egyszerű és korszerű. Az alfa / béta lejáratot egyszerűen az admin oldalon szabályozhatja. A Google nem volt messze elmaradva; elég fájdalommentes volt, külön alkalmazást sem igényelt.

App Review

Miután az alkalmazás készen áll a főműsoridőre, elküldi azt felülvizsgálatra. A felülvizsgálat mind programozott ellenőrzőlista (pl. Van indító ikonja?), Mind valós emberek felhasználásával történik („alkalmazásod az X klónja, elutasítjuk”)

  • Apple : A beküldés előtt az XCode figyelmeztet az építkezés során felmerülő lehetséges problémákra. Az emberi alkalmazás felülvizsgálata körülbelül 24–48 órát vesz igénybe.
  • Google : Van valaki otthon? Az Android Studio nem árult el semmilyen lehetséges problémát, és alkalmazásomat a beküldéstől számított perceken belül jóváhagyták. Nem hiszem, hogy egy igazi ember nézte meg az alkalmazásomat.
  • Microsoft : Beküldéskor a gyors programozási ellenőrzés hibás ikonformátumokkal kapcsolatos problémát fogott fel. Elhaladás után egy ember 4 napon belül felülvizsgálta az alkalmazásomat.

Nyertes : Apple.

Fejlesztőként biztosan tetszik, hogy az alkalmazásom azonnal a Google Play áruházba került. De ez csak azért van, mert gyanítom, hogy valójában nem egy ember vizsgálta felül.

Az Apple volt a leggyorsabb átfutási idő a tényleges emberi felülvizsgálatra. A frissítések 24 órán belül felülvizsgálták.

A Microsoft itt sújtott vagy hiányzott. Az első felülvizsgálat 3 vagy 4 napot vett igénybe. Egy későbbi frissítés 24 órát vett igénybe. Ezután egy újabb frissítés, ahol felvettem az XBox platformot, további 3-4 napig tartott.

Következtetés

Fájdalmas és pénzbe kerül, ha egy meglévő PWA-t veszünk, és működőképessé tesszük őket mobil platformokon, és felsoroljuk az App Store-ban.

Nyertes : Google. Megkönnyítették az App Store-ba való bejutást. Ez a legkönnyebben integrálható a natív platformba, megkísérelve szabványosítani azokat az internetes API-kat, amelyeket az operációs rendszer platformjai fel tudnak venni (hello, kedves navigator.mediaSession)

Második helyezett : Microsoft. Megkönnyítették a webalkalmazás varázslattal való megszórását, és az üzletükbe beküldhető csomaggá változtatták. (Ingyenesen elvégezhető a PWABuilder webhely használatával!) A platformjukkal való integráció az automatikusan beírt ablak használatát jelenti. Windows. * JavaScript névtér. Nem rossz.

Vesztes : Apple. Ne követelje meg, hogy vásároljak Mac-et egy iOS-alkalmazás elkészítéséhez. Ne kényszerítsen arra, hogy natív csomagolókat használjak az integrációhoz a platformjával. Ne követelje, hogy biztonsági tanúsítványokkal cseszegessem; hagyja, hogy a build eszközei elkészítsék azokat nekem, és automatikusan tárolja őket a Dev Center fiókomban. Ne kényszerítsen arra, hogy 2 különböző webhelyet használjak: Apple Dev Center és iTunes Connect.

Végső gondolatok: A web mindig nyer. Győzte a Flash-et. Megölte Silverlight-ot. Megsemmisítette a natív alkalmazásokat az asztali számítógépen. A böngésző a gazdag kliens platform. Az operációs rendszer csupán böngésző-indító és hardver-kommunikátor.

Az internet nyer mobilon is. A fejlesztők nem akarnak 3 külön alkalmazást építeni a főbb platformokhoz. A vállalatok nem akarnak fizetni 3 alkalmazás fejlesztéséért.

A válasz mindezekre a web. Gazdag webalkalmazásokat - Progresszív Webalkalmazásokat - készíthetünk és csomagolhatunk az összes alkalmazásboltba.

Különösen az Apple-nek van perverz ösztönzése arra, hogy megállítsa a web előrehaladását. Ez ugyanaz ösztönző, hogy a Microsoft a '90 -es évek végén és a korai 2000-es: azt akarja, hogy a platform jó apps. A PWA-k ezt aláássák; mindenhova futnak.

Szoftveres bölcsességem a következő: A PWA-k végül megnyerik és megelőzik a natív mobilalkalmazásokat. 5–10 év múlva a natív iOS-alkalmazások ugyanolyan gyakoriak lesznek, mint a Win32 C-alkalmazások. Az Apple rúgni és sikítani fog, az iOS Safari-t a görbe mögött tartva, ahol lehet, blokkolja a PWA előrehaladását. (Még a közelmúltbeli „támogatásuk” is a PWA-k számára az iOS Safari 11.1-ben valójában megbénítja a PWA-kat.)

A mobilalkalmazások platformjaira tett javaslatom az elkerülhetetlen felkarolását jelenti, és vagy automatikusan hozzáadja a minőségi PWA-kat az alkalmazásboltjához, vagy lehetővé teszi a fejlesztők számára, hogy egyszerűen (pl. Ingyenesen, legfeljebb 3 kattintással) nyújtsanak be PWA-t az Ön üzletébe.

Olvasók, remélem, hogy ez hasznos pillantást vetett az App Stores PWA-ra 2018-ban.

Beküldött egy PWA-t egy alkalmazásboltba? Szeretném hallani tapasztalatait a megjegyzések részben. És további blogbejegyzéseimet elolvashatja a blogomon.