Jeg byggede en Progressive Web App og offentliggjorde den i 3 appbutikker. Her er hvad jeg lærte.

En måneds arbejde, flere hundrede dollars og masser af bureaukrati.

Jeg udgav for nylig Chavah Messianic Radio, en Pandora-lignende musikafspiller, som en Progressiv Web-app og sendte den til de 3 appbutikker (Google Play, iOS App Store, Windows Store).

Processen var både smertefuld og oplysende. Her er hvad jeg lærte.

Hvorfor?

For det første spekulerer du måske på, ”Hvorfor endda placere din app i appbutikkerne? Bare bo på det åbnede web! ”

Svaret er i en nøddeskal, fordi det er her brugerne er . Vi har uddannet en generation af brugere til at finde apps i proprietære appbutikker, ikke på det gratis og åbne web.

For min webapp var der to store grunde til at komme i appbutikken:

  1. Brugernes efterspørgsel
  2. Webappsbegrænsninger fra Apples fjendtlige mobile platforme

Brugernes efterspørgsel: Mine brugere har spurgt mig i årevis, “Er der en app til Chavah? Jeg kan ikke se det i butikken. ”

De spørger det, fordi vi har uddannet brugere til at søge efter apps i proprietære appbutikker.

Mit svar til mine brugere har hidtil været,

“Aww, du har ikke brug for en app - bare gå til webstedet på din telefon! Det virker!"

Men jeg lyver lidt.

Ægte webapps fungerer kun kinda-sorta på mobil. Hvilket bringer mig til den anden grund: webapp-begrænsninger fra Apples fjendtlige mobile platforme.

Mobilplatformsleverandører, som Apple, er helt seje med apps, der bruger din telefon fuldt ud. Få adgang til din placering, afspil baggrundslyd, få dine GPS-koordinater, spil mere end én ting ad gangen og mere.

Apple er helt cool med det.

Men kun hvis du betaler Apple $ 99 / år for privilegiet.

Hvis du vil gøre nogen af ​​disse ting i en almindelig gammel webapp, ja, goshdarnit, vil Apple ikke bare nægte dig disse ting, det forhindrer dig i at overhovedet bede om tilladelse .

Til min Pandora-lignende musikafspiller-app dukkede denne forfærdelige brokenness op på mange måder.

Fra mindre ting som "iOS Safari giver dig ikke mulighed for at afspille lyd uden først at interagere med siden" til store, show-stop ting som "iOS Safari lader dig ikke afspille den næste sang, hvis din app er i baggrunden eller hvis din skærm er slukket. ”

Åh plus underlige visuelle uregelmæssigheder som at skrive i en tekstboks og se din tekst vises andre steder på skærmen.

Så for at gøre min HTML5-musikapp faktisk funktionel og arbejde på folks mobile enheder var det nødvendigt at gøre min PWA til en app i app store.

Hindringer for indrejse

I den ideelle verden ser udgivelsen af ​​din webapp til appbutikkerne sådan ud:

  • Din web / cloud vært eller kontinuerlig integrationsudbyder
  • Du har udgivet en Progressiv webapp. Udgive til appbutikker?

☑ iOS App Store

☑ Google Play

☑ Windows Store

(Eller skiftevis, når Microsoft eksperimenterer med, vises din PWA bare automatisk i appbutikken, når Bing gennemsøger den.)

Men ak, vi lever ikke i denne ideelle verden. I stedet skal vi beskæftige os med alle former for proprietær native BS for at få vores webapps i butikkerne.

Hver af appbutikkerne har en adgangsbarriere: hvor svært det er at tage en eksisterende webapp og den i appbutikken.

Jeg viser nogle af hindringerne nedenfor.

Koste

  • Apple : $ 99 / år for at få din app opført i iOS app store.
  • Google: Engangsgebyr på $ 25 for at angive din app i Google Play Butik.
  • Microsoft: Gratis!

Lad mig ikke betale dig for at gøre min app tilgængelig for dine brugere. Min app beriger din platform. Uden gode apps bliver din platform opgivet.

Apple plejede at forstå dette. Da det først introducerede iPhone, var Steve Jobs overbevist om, at HTML5 var fremtiden, og at apps simpelthen bare ville være webapps. Der var ingen native iPhone SDK til tredjeparter. Apple har siden opgivet denne vision.

Google bad om et engangsgebyr på $ 25. Sandsynligvis for at undgå spammere og mindske virkelig uønskede apps fra at komme ind i butikken.

Microsoft ser ud til at være fast besluttet på bare at øge det samlede antal apps i deres appbutik, uanset kvalitet.

Vinder: Microsoft. Det er svært at slå fri.

Tilføjelse af indfødte funktioner

I en ideel verden behøver jeg ikke skrive en ekstra linje kode til min webapp for at integrere i operativsystemet. Eller som Steve Jobs sagde tilbage i 2007,

”Den fulde Safari-motor er inde i iPhone. Og så kan du skrive fantastiske Web 2.0- og Ajax-apps, der ser nøjagtigt ud og opfører sig nøjagtigt som apps på iPhone. Og disse apps kan integreres perfekt med iPhone-tjenester. De kan ringe, de kan sende en e-mail, de kan slå et sted op på Google Maps. ” -Steve Jobs, 2007

For mig betyder det, at min webapp afspiller baggrundslyd ved hjælp af standard HTML5-lyd; det fungerer fint på alle operativsystemer.

Min webapp erklærer, hvilken lyd der afspilles, og operativsystemerne opfanger det og viser sanginformation på det aktuelle spil på låseskærmen.

Min app styrer lyd ved hjælp af standard HTML5-lyd-API; OS opfanger det og giver afspil / pause / næste / lydstyrke / trackbar kontrol på låseskærmen.

Men desværre lever vi ikke i denne ideelle verden. Alle de ovennævnte ting fungerer faktisk ikke ud af kassen på alle 3 platforme.

Min webapp skal afspille lyd i baggrunden. Og indlæs webadresser fra min CDN. Det lyder rimeligt, ikke? Og bonus, hvad med at vise sanginformation, der aktuelt afspilles på låseskærmen? Og styring af lyden (afspil / pause / næste osv.) Fra låseskærmen? Hvor svært er dette?

Tre meget forskellige tilgange taget her:

  • Apple : Vi giver ikke webapps en måde at erklære sådanne muligheder på; du bliver nødt til at skrive en indbygget indpakning (f.eks. med Cordova) for at interagere med operativsystemet.
  • Google : Web FTW! Lad os oprette en ny webstandard, der viser lyd og kontrol fra låseskærmen. Baggrundslyd? Sikker på, gå videre!
  • Microsoft: Vi injicerer vores proprietære API, window.Windows. *, I dit globale JavaScript-navneområde, og du kan bruge det til at gøre de ting, du vil gøre.

Gå ind på flere detaljer her for hver butik:

For din iOS-appbutik skal din webapp afspille baggrundslyd? Brug et Cordova-plugin. Brug for at vise sang, der afspilles i øjeblikket, på låseskærmen? Brug et Cordova-plugin. Brug for at kontrollere den aktuelt afspillede sang fra låseskærmen? Brug et Cordova-plugin. Du får ideen. Grundlæggende nar Cordova Apple til at tro, at du er en indfødt app. Og da du ikke er en yucky webapp, lader Apple dig gøre alle de ting, native apps kan gøre. Du har bare brug for native tricks - Cordova-plugins - for at lade dig gøre det.

For Google Play er det rart, at jeg bare kan skrive JS-kode for at få dette til at fungere; ingen Cordova-plugins kræves her. Selvfølgelig fungerer JS ikke hvor som helst undtagen Chrome på Android ... men hej, måske en dag (i en ideel verden!) Vil alle mobilbrowsere implementere disse web-API'er ... og verden vil leve som en. Jeg er næsten klar til at sprænge nogle John Lennon hippie utopi melodier.

I Windows Store vil du afspille baggrundslyd? Undskyld! Det vil sige, medmindre du erklærer dine hensigter i vores manifestfil til proprietære funktioner (let) OG du implementerer denne proprietære mediegrænseflade ved hjælp af window.Windows.SystemMediaTransportControls (ikke så let). Ellers dæmper vi dig, når din app går i baggrunden.

Vinder : Google. Jeg vil være i stand til bare at skrive JavaScript og lade operativsystemet hente signaler fra min app.

2. plads : Windows. Jeg kan stadig skrive almindelig gammel JavaScript, men jeg skal tale med en proprietær Windows JS API, der blev injiceret i min proces, når jeg kører på Windows. Ikke forfærdeligt.

Taber : Apple. De er ligeglade med webapps. Faktisk er det værre end det. Det føles som om de faktisk er fjendtlige over for webapps. iOS Safari er den nye Internet Explorer 6. Det er bagud i næsten alle webstandarder, især omkring Progressive Web Apps. Dette er sandsynligvis af forretningsmæssige årsager: webapps forstyrrer deres $ 99 / år + 33% køb i app-racket. Så for at få min webapp til at fungere på deres platform, er jeg dybest set nødt til at lade som om jeg er en hjemmehørende app.

App Store-registrering

At sende din PWA til appbutikken kræver registrering, virksomhedsbekræftelse og mere bureaukrati. Sådan gik de 3 appbutikker klar:

  • Apple : Du skal bevise, at du er en lovlig, registreret virksomhed. Denne verifikation udføres ikke af os - men af ​​en tredjepart, som måske eller måske ikke kender til din virksomhed.
  • Google : Vil du have din app i vores butik? Cool af os.
  • Microsoft : Vil du have din app i vores butik? Cool af os.

Det største smertepunkt for mig var at blive verificeret som en juridisk virksomhed af Apple.

Først gik jeg til stedet og tilmeldte mig Apples udviklerprogram. Jeg udfyldte mit navn og virksomhedsoplysninger. (Bortset fra: Jeg antager, at Apple ikke vil lade dig indsende en app, medmindre du har et registreret, juridisk firma?)

Jeg klikker næste.

"De oplysninger, du indtastede, matchede ikke din D&B-profil."

Min hvad?

En smule Googling viste, at "D & B-profil" er Dun og Bradstreet. Jeg har aldrig hørt om denne gruppe før, men jeg finder ud af, at Apple bruger dem til at bekræfte dine juridiske selskabsoplysninger.

Og tilsyneladende matchede min D&B-profil ikke det, jeg satte i min Apple Dev-registrering.

Jeg googler lidt mere og finder Apple dev-fora fyldt med lignende indlæg. Ingen havde et godt svar.

Jeg kontakter Apple Dev-support. 24 timer senere kontaktes jeg via e-mail, hvor jeg siger, at jeg skal kontakte D&B.

Jeg beslutter at kontakte dem ... men Apple siger, at det vil tage op til et par dage for dem at svare.

På dette tidspunkt tænker jeg på at opgive hele ideen.

Mens jeg ventede på D&B support for at komme tilbage til mig, beslutter jeg at gå til D&B webstedet, kontrollere min identitet og opdatere mine virksomhedsoplysninger, som jeg antager, de havde taget fra regeringsregistreringsregistreringer.

Sagde jeg, hvor sutter dette er? Jeg vil bare liste min eksisterende webapp i butikken. Plz hjælp.

Jeg går til D&B for at opdatere min forretningsprofil. Overraskelse! De har en JavaScript-fejl i deres valideringslogik, der forhindrer mig i at opdatere min profil.

Heldigvis er jeg en dygtig udvikler. Jeg klikker for at sætte et brudpunkt i deres JavaScript, klikke på send, ændre isValid-flag til sandt og voila! Jeg har opdateret min D&B profil.

Tilbage til Apple Dev -> lad os prøve dette igen. Registrer mit firma ...

"Fejl: De oplysninger, du indtastede, matchede ikke din D&B-profil."

AREYOUFREAKINKIDDINGME.

Tal med Apple igen. "Åh, det kan tage 24–48 timer for de opdaterede D&B-oplysninger at komme ind i vores system."

Du ved det, fordi digital information kan tage 2 dage at rejse fra server A til server B. Sigh.

To dage senere forsøger jeg at registrere ... endelig fungerer det! Nu er jeg i Apple Developer-programmet og kan sende apps til gennemgang.

Vinder : Google og Microsoft; begge tog alle 5 minutter at registrere.

Taber : Registreringen af ​​Apple-udvikleren var langsom og smertefuld. Det tog omkring en uge at blive registreret med deres udviklerprogram. Det krævede, at jeg kontaktede support fra 2 forskellige freaking-virksomheder. Og det krævede, at jeg kørte fejl i JavaScript-koden på et tredjepartswebsted, så jeg kan komme forbi deres fejlbehæftede klientsides validering, så min info flyder til Apple, så jeg kan sende min app til butikken. Wow, bare ... wow.

Hvis der er nogen redning her for Apple, er det, at de har et 501c3 nonprofit-program, hvor nonprofitorganer kan få deres $ 99 årlige gebyr frafaldet. Jeg udnyttede det. Og måske er dette ekstra trin kompliceret.

App-emballage, bygning, indsendelse

Når du har en webapp, skal du køre noget magi på den for at gøre den til noget, du kan indsende til App Store-gennemgang.

  • Apple : Først skal du købe en Mac; du kan ikke oprette en iOS-app uden en Mac. Installer XCode, og disse opbygningsværktøjer og -rammer, erhverv et certifikat fra vores udviklerprogram, opret en profil på et separat websted kaldet iTunes Connect, knyt det sammen med det certifikat, du genererede i Apple Dev-centret, og indsend derefter ved hjælp af XCode. Let som en, to, tre ... syvogtredive ...
  • Google : Download Android Studio, generer et sikkerhedscertifikat gennem det, pakk det derefter ved hjælp af Studio. Upload pakken til Android Developer-webstedet.
  • Microsoft : Generer en .appx-pakke ved hjælp af disse gratis kommandolinjeværktøjer eller Visual Studio. Upload til Microsoft Dev Center-webstedet.

Den gode nyhed er, at der er et gratis værktøj til at gøre det magiske ved at gøre din webapp til app-pakker . Det fantastiske gratis værktøj kaldes PWABuilder. Den analyserer en URL, fortæller dig, hvad du skal gøre (fx måske tilføje nogle startskærmikoner til dit PWA-webmanifest). Og i en tretrinsguide kan du downloade pakker, der indeholder al magien:

  • For Windows genererer det faktisk .appx-pakken. Du kan bogstaveligt talt tage det og indsende det på Windows Dev Center-webstedet.
  • For Google genererer den en wrapper Java-app, der indeholder din PWA-webapp. Fra Android Studio bygger du dette projekt, der genererer Android-pakken, der kan uploades til Android Dev Center-webstedet.
  • For Apple genererer det et XCode-projekt, som kan bygges med XCode. Hvilket kræver en Mac.

Igen var Apple den mest smertefulde af alle disse. Jeg har ikke en Mac. Men du kan ikke opbygge XCode-projektet til din PWA uden en Mac.

Jeg vil ikke betale flere tusinde dollars for at udgive min gratis app i Apples app store. Jeg vil ikke betale for privilegiet at berige Apples iOS-platform.

Heldigvis koster MacInCloud omkring $ 25 / måned, og de giver dig en Mac-maskine med allerede installeret XCode. Du kan fjerne det ved hjælp af Windows Remote Desktop eller endda via en webgrænseflade.

Det var ikke nok at bare opbygge XCode-projektet og indsende. Jeg var nødt til at generere et sikkerhedscertifikat på Apple Developer-webstedet og derefter oprette en ny appprofil på et separat sted, iTunes Connect, hvor du faktisk sender pakken.

Og det var ikke alt: da Apple er fjendtlige over for webapps, måtte jeg installere nogle specielle rammer og tilføje Cordova-plugins, der gør det muligt for min app at gøre ting som at afspille lyd i baggrunden, føje den aktuelle sang til låseskærmen, styr sangvolumen og afspilningsstatus fra låseskærmen og mere.

Dette tog mindst en uges finagling for at få min app til at fungere, før jeg kunne sende den til appbutikken.

Vinder : Microsoft. Forestil dig dette: Du kan gå til et websted, der genererer en app-pakke til din webapp. Og hvis det ikke er din ting, kan du downloade kommandolinjeværktøjer, der gør jobbet. GUI person? Det gratis Visual Studio fungerer.

2. plads : Google. Kræver Android Studio, men det er gratis, kører alle og var enkelt nok.

Taber : Apple. Jeg skulle ikke være nødt til at købe en proprietær computer - en flere tusind dollars Mac - for at opbygge min app. Apple Dev Center -> iTunes Connect-sammenfiltring virker som en out-of-touch manager-forsøg på at skubbe iTunes til udviklere. Det skal simpelthen være en del af Apple Developer Center-webstedet.

Apptest

Når du endelig har gjort alle de magiske besværgelser for at gøre din eksisterende webapp til en mobilappakke, vil du sandsynligvis sende den ud til testere, inden du frigiver din app til de uvaskede masser.

  • Apple : Til test skal du have dine testere til at installere Test Flight på deres iOS-enhed. Derefter tilføjer du testers e-mail i iTunes Connect. Testeren får en underretning og kan teste din app, før den er tilgængelig i App Store.
  • Google : I Android Dev Center tilføjer du e-mail-adresser til testere. Når de er tilføjet, kan de se din alfa / beta-version i App Store.
  • Microsoft : Jeg brugte faktisk ikke dette, så jeg vil ikke kommentere det.

Vinder : Kast op. Apples Test Flight-app er enkel og strømlinet. Du kan kontrollere alfa / beta udløb blot på admin siden. Google var ikke langt bagefter; det var ret smertefrit og krævede ikke engang en separat app.

App gennemgang

Når din app er klar til prime time, sender du din app til gennemgang. Gennemgangen udføres ved hjælp af både en programmatisk tjekliste (f.eks. Har du et startikon?) Og af rigtige mennesker (“din app er en klon af X, vi afviser den”)

  • Apple : Før indsendelse advarer XCode dig om potentielle problemer under build. Den menneskelige appanmeldelse tager cirka 24–48 timer.
  • Google : Er der nogen derhjemme? Android Studio fortalte mig ikke om eventuelle problemer, og min app blev godkendt inden for få minutter efter indsendelse. Jeg tror ikke et rigtigt menneske kiggede på min app.
  • Microsoft : Efter indsendelse fik en hurtig programmatisk gennemgang et problem vedrørende forkerte ikonformater. Efter bestået gennemgik et menneske min app inden for 4 dage.

Vinder : Apple.

Sikker på, som udvikler kan jeg godt lide, at min app straks var i Google Play-butikken. Men det er kun fordi, jeg formoder, at det faktisk ikke blev gennemgået af et menneske.

Apple havde den hurtigste leveringstid for faktisk menneskelig gennemgang. Opdateringer bestod også gennemgang inden for 24 timer.

Microsoft blev ramt eller savnet her. Den indledende gennemgang tog 3 eller 4 dage. En senere opdatering tog 24 timer. Derefter tog en anden opdatering, hvor jeg tilføjede XBox-platformen, yderligere 3-4 dage.

Konklusion

Det er smertefuldt og koster penge at tage en eksisterende PWA og få dem til at fungere på mobile platforme og opført i App Store.

Vinder : Google. De gjorde det nemmest at komme ind i appbutikken. Det gjorde det nemmest at integrere i den oprindelige platform ved at forsøge at standardisere web-API'er, som OS-platforme kan hente på (hej, dejlige navigator.mediaSession)

2. plads : Microsoft. De gjorde det nemmest at sprøjte din webapp med magi og gøre den til en pakke, der kan sendes til deres butik. (Kan gøres gratis ved hjælp af PWABuilder-webstedet!) Integrering med deres platform betyder brug af det autoinjicerede vindue. Windows. * JavaScript-navneområde. Ikke dårligt.

Taber : Apple. Kræv ikke mig at købe en Mac for at oprette en iOS-app. Tving mig ikke til at bruge native wrappers til at integrere med din platform. Kræv ikke mig at skrue med sikkerhedscertifikater lad dine byggeværktøjer gøre dem til mig, og gem dem automatisk på min Dev Center-konto. Lad mig ikke bruge 2 forskellige websteder: Apple Dev Center og iTunes Connect.

Afsluttende tanker: Internettet vinder altid. Det besejrede Flash. Det dræbte Silverlight. Det ødelagde native apps på skrivebordet. Browseren er den rige klientplatform. OS er blot en browser-launcher og hardware-communicator.

Internettet vinder også på mobil. Udviklere ønsker ikke at bygge 3 separate apps til de store platforme. Virksomheder ønsker ikke at betale for udvikling af 3 apps.

Svaret på alt dette er internettet. Vi kan bygge rige webapps - Progressive Web Apps - og pakke dem til alle appbutikkerne.

Især Apple har et pervers incitament til at stoppe udviklingen af ​​internettet. Det er det samme incitament, at Microsoft havde i slutningen af 90'erne og begyndelsen af 2000'erne: den ønsker at være den platform for gode apps. PWA'er underminerer det; de løber overalt.

Min software-visdom er dette: PWA'er vil i sidste ende vinde og overhale native mobile apps. Om 5-10 år vil native iOS-apps være lige så almindelige som Win32 C-apps. Apple vil sparke og skrige og holde iOS Safari bag kurven og blokere PWA-fremskridt, hvor de kan. (Selv deres nylige "support" til PWA'er i iOS Safari 11.1 lammer faktisk PWA'er.)

Mit forslag til mobile app-platforme er at omfavne det uundgåelige og enten automatisk tilføje kvalitets-PWA'er til din appbutik eller lade udviklere nemt (f.eks. Gratis og med 3 klik eller mindre) indsende en PWA til din butik.

Læsere, jeg håber, at dette har været nyttigt at kigge på PWA'er i App Stores i 2018.

Har du sendt en PWA til en appbutik? Jeg vil meget gerne høre din oplevelse i kommentarfeltet. Og du kan læse flere af mine blogindlæg på min blog.