Google gaat ontwikkelaars webapps laten installeren via Play Store

De Google Play Store installeert de Twitter- en YouTube TV-apps nu automatisch als webapps als een gebruiker deze op een Chrome OS-apparaat probeert te installeren. Eerder werden deze apps via de Store alleen aangeboden als Android APK-apps, die slecht of niet werkten.

Het standaard installeren van een pwa, kort voor progressive web app, werd voor het eerst opgemerkt door Chrome Unboxed. Eerst werd op Chrome OS-apparaten standaard de Android APK-app geïnstalleerd. Deze app werkte volgens de site minder goed op Chrome OS-apparaten dan de pwa-versie. Chromebooks konden eerder al pwa's installeren via bijvoorbeeld de browser, maar het is voor het eerst dat een pwa via de Play Store wordt aangeboden, zo schrijft Chrome Unboxed.

De site benaderde Chrome OS-manager Dominick Ng over het nieuws. Ng had eerder het bericht van de site geretweet en noemde het 'een van de meest uitdagende en bevredigende' klussen die hij ooit had uitgevoerd. Tegen Chrome Unboxed zegt hij dat de YouTube TV-app op Chrome OS nu ook als pwa wordt geïnstalleerd. De Android APK-versie van de YouTube TV-app is niet compatibel met Chrome OS, waardoor Chromebook-gebruikers deze app niet konden installeren via de Play Store. Door het standaard installeren van de pwa-versie, kunnen Chrome OS-gebruikers dat wel. Volgens de site werkt deze pwa precies hetzelfde als de Android APK-versie.

Op Twitter schrijft Ng dat alle app-ontwikkelaars in de toekomst moeten kunnen aangeven welke appversie moet worden geïnstalleerd op welk platform. Deze wijziging betekent dus niet dat alle Chromebook-apps straks pwa's worden. Ook is het niet de bedoeling dat de gebruiker zelf via de Play Store tussen de pwa- of Android APK-versie kan kiezen, om verwarring bij gebruikers te voorkomen.

Pwa's zijn applicaties die niet specifiek voor één besturingssysteem zijn ontworpen, maar juist op verschillende platforms en schermgroottes kunnen werken. Deze apps zijn ook offline te gebruiken. Tweakers schreef eerder een achtergrondverhaal over de webapps.

Door Hayte Hugo

Redacteur

14-04-2020 • 11:30

62

Reacties (62)

62
59
40
3
1
15
Wijzig sortering
In principe is het al mogelijk om een PWA toe te voegen aan de Play Store via een "Trusted Web Activity" (https://developers.google...roid/trusted-web-activity). Dit gebruikt i.t.t. de bekende WebView of Cordova varianten gewoon je standaard ingestelde browser (zoals Chrome of Samsung Internet). Google doet dit zelf met de lite varianten van de apps (bijv. https://play.google.com/s...droid.apps.mapslite&hl=en).
Vanuit Chromium bestaat daarnaast "Project Fugu" om meer "native" app functionaliteit naar de browser te krijgen (zoals wake lock api, of file system api).
Op KaiOS gaat het ook om allemaal om web apps.
Nu lijkt Apple eigenlijk alleen de vertragende partij, omdat zij geen baat hebben bij web apps die in potentie buiten de beperkingen van de App Store gaan, of omdat Safari achterloopt met implementatie van sommige API's.
Hoe zit het eigenlijk met de ondersteuning voor de android/playstore apps op chromiumOS? Zelf gebruik ik die van arnoldthebat.co.uk en daar krijg ik het niet (even snel) voor elkaar om op een oude laptop android apps te 'installeren'. Eerlijk is eerlijk, er zijn bij arnoldthebat issues met de play-store.
Mijn mening is dat het bij apple vooral draait om $$$. Dat zie aan hun lineup van producten.
Als ze er geen 30% markup op kunnen aanrekenen, komt het hun app store niet binnen!

Ik hoop echt dat webstandaarden uiteindelijk gaan winnen.
JavaScript is een plezier om te gebruiken de laatste jaren vooral met Typescript.

Verschillende teams hebben die allen dezelfde app maken... als je het uitlegt aan een leek zou die meteen roepen: "Dat is toch driedubbel werk?!"
Ik hoop dat javascript echt snel verleden tijd is :) Webassembly (Blazor .Net) bevalt me prima en ontwikkelt zooooooo veel lekkerder als je C# programmeur bent :) En ja, een Blazor WebAssembly PWA hebben we al in productie draaien :)
Is ook maar een persoonlijke mening toch?

Ik hoop dat .NET, alle Microsoft varianten van bestaande programmeertalen (C#, F# en weet ik t) wat altijd minder goed op Linux werkt, en Oracle en Java snel verleden tijd is. JavaScript is dan de belangrijkste open standaard die ons uit die jaren '90 verkokerde silo-drab zou moeten kunnen helpen.

Maar ik kan ook de mensen en bedrijven wel enigszins begrijpen, die wel graag met zo'n drab-silo (denkten te) willen werken, omdat ze niet beter weten of gewoon helemaal opgesloten zitten in hun silo.
Ja, erg persoonlijk. En .Net Core draait heerlijk op Linux en is juist daarvoor bedoeld. Het is niet meer Microsoft afhankelijk en open source. Het is een prima oplossing voor non-ms hosted apps.

JS als backend heb ik nog nooit gezien bij een klant. Dat is 99% van de tijd MS of Java, waarbij Java een klein deel is. Als je als team MS als backend gebruikt, dan is een MS front-end niet meer dan logisch. Alle JS frameworks voelen als een nood oplossing omdat er niets anders is voor web.... en dat is gelukkig verleden tijd met webassembly. Ik verwacht straks hele andere frameworks te zien ontstaan, wellicht ook gebaseerd op Javascript maar dan in een hele andere vorm dat het huidige "geknutsel" ;)
Zeker, stuk beter dan dat geklooi met packages, toolchains en andere afhankelijkheden edg wat je met als dat JS gezeur hebt.... :) Tja, ik ben een echte C# ontwikkelaar en heb daar al 16 jaar ervaring mee en kan er mee lezen en schrijven. Ben je Javascript gewend kan je daar veel beter mee uit de voeten. Dat zegt niet dat het ene beter is dan het andere of sneller ontwikkeld. Ik kan met C# erg snel een applicatie in elkaar zetten, jij vast met Javascript.
Dus juist wel. Syntax is erg krachtig en razor brengt logica en opmaak goed samen als je dat wilt. C# staat echt niet stil. Blazor maakt de dom integratie geweldig eenvoudig.
Ja maar vergelijken met laten we zeggen python is het wel een totaal andere tier dan wat er nodig is om het goed te laten werken naar mijn ervaring. Ik zie het vooral op web gebied en mobile app gebied ook niet in the wild eigenlijk?
Ik vind eerlijk gezegd dat jullie beiden ergens wel gelijk hebben.. reden daarvoor is het eindproduct. Focus je daarop, de taal etc is vaak bijzaak imo.

Ik kan full stack JS, maar heb alle respect voor mensen die liever in een andere taal ontwikkelen.
Programmeren is altijd knutselen @Tadango, dat is net het leuke eraan.
JavaScript wordt vaak als inefficient bestempeld omdat je vaak meerdere frameworks bijeen moet knutselen om iets te hebben zoals in andere ecosystemen, maar is dat een nadeel?
Is vrije keuze niet juist verlossend?

Wat wel eens mag komen is een standard library wat andere talen wel hebben..

En mijn gevoel is dat JavaScript en python de laatste jaren het algemene developer wereldje aan het verbeteren zijn.

Easy to get going, ubiquitous and powerful if you know what you are doing... JavaScript!
Ik vind dit een mooie vooruitgang en hoop dat Apple in de toekomst ook betere ondersteuning gaat geven voor WebApps. Zoals het ondersteunen van notificaties.
Ik hoop het niet. Dit zal nog meer developers er van weerhouden een goede native app te maken in plaats van lekker goedkoop een webpagina in elkaar laten prutsen.
Wat is er mis met een "webpagina"? Zeker als je kijkt naar WebAssembly is er qua performance nagenoeg geen verschil.

Als dit ervoor zorgt dat er geen 5 verschillende apps meer nodig zijn waardoor het ontwikkelteam zich volledig kan focussen op 1 applicatie maakt het dus niet meer uit op welk platform je zit, elke functionaliteit is op elk platform te krijgen. Dat heb ik zelf toch een stuk liever dan dat je opeens je computer moet starten om een instelling aan te passen omdat die niet beschikbaar is op de telefoon app.
Meestal komt het er op neer dat je juist alleen de overeenkomende functionaliteit krijgt, en niet de verwachte platformfuncties. Allerlei integraties werken niet of nauwelijks, tenzij je alsnog veel native development toevoegd, en daarvoor heb je weer specifieke teams nodig, en heb je alsnog alleen de volle functionaliteit op desbetreffende platformen.
Waar denk jij dan aan? Als ik naar de apps op mijn telefoon kijk heeft geen enkele van die apps specifieke Android gerelateerde mogelijkheden nodig.
Netflix, Prime Video, Deezer, Floatplane, Slack, Email client, Steam, PostNL,Remote Desktop, TeamViewer, Shazam, Bankieren app. Elk van deze apps heeft alleen functionaliteit die zowel op PC, telefoons en tablets beschikbaar zijn.
Dat zeg ik ook niet, ik zeg alleen dat die functionaliteit alsnog vaak native is. Downloaden bij netflix, prime en deezer, delen naar een email app. De rest kan in principe ook als webapp (rabo bankieren is een webapp bijvoorbeeld).
Downloaden bij netflix, prime en deezer
XmlHttpRequest kan binary blobs downloaden en er zijn geschikte storage APIs om deze lokaal weg te schrijven. Daar heb je geen native functionaliteit voor nodig.
delen naar een email app.
Moderne browsers zoals Chrome implementeren de Share API om een brug te slaan naar de native share functionaliteit van het OS, waarmee je kunt delen via e-mail; social media; etc. alles wat het OS aangeeft als potentieel doel/ontvanger.

Heb je dus ook geen native functionaliteit voor nodig.

[Reactie gewijzigd door R4gnax op 23 juli 2024 07:18]

Je kunt toch niet vanuit een app naar een website sharen, dat bedoelde ik.

Maar goed, het zal zeker worden gebruikt, maar ik vind het erg zonde want native apps werken toch altijd nog sneller, maar zijn vooral vaak gewoon mooier omdat ze de designlanguage van een OS vaak (deels) naleven, waarbij webapps allerlei willekeurige designs aanhouden.
Dat kan wel degelijk als je het in de PWA aangeeft, net als dat je dat bij een native app moet aangeven.
Je kunt toch niet vanuit een app naar een website sharen, dat bedoelde ik.
Kan wel: https://web.dev/web-share-target/
Gui gewijs komt een webapp toch nog steeds ver achter tegenover een native app.
Wat je met een native app kan gui gewijs kan een web assembly app nog niet aan tippen.
Noem eens wat dingen dan? Kan niets verzinnen qua GUI wat met een PWA niet kan.
kunnen: in de zin van het is technisch mogelijk?
Of in de zin van het gaat als vanzelf en voelt heel natuurlijk aan...

Een webapp kan in principe bijna alles, maar niet altijd op een handige manier.
Denk aan bv office online of google docs vs een native office pakket.
Gestures lijken ook niet altijd goed te werken tegenover een native app die dat prima aan kan.

Treeviews, listviews, datagrids zijn ook alles behalve handig in webassembly.
Ze bestaan, maar zijn vaak heel lomp en beperkt in functionaliteit.
Ik zou niet weten waarom niet, daarnaast is WASM nog erg nieuw dus niet gek dat er nog niet super veel volwaardige applicaties voor bestaan. O.a. autocad als webapp en figma ben ik bijzonder over te spreken.

Waarom iets als een treeview niet zou werken als web app is mij een raadsel, ik gebruik deze de laatste weken erg veel in een bijzonder goed werkende web app. (https://astexplorer.net/)
Jij mag er gerust geen graten in zien. We hoeven het niet eens te zijn. :)

Ik verkies voor veel zaken nog altijd een native app omdat het pakken beter en sneller aan voelt.
Andere statische zaken kunnen dan weer beter op een web assembly.
Statische zaken kunnen doorgaans prima in een web app zonder wasm. :P
Toch heeft lang niet elke app die extra GUI mogelijkheden nodig.
100% akkoord.
Hangt er van af.
Voor veel zaken is een webapp net beter. Dank aan bv nieuws sites, sociale media.
Voor mij is een native app pas nodig als er locaal echt logica moet gedaan worden of er offline mogelijkheden moeten zijn.(navigatie, domotica in huis,...)

Beide hebben hun bestaansrecht en hun voordelen.
Een native app heeft lang niet altijd voordelen t.o.v. een pwa. Tweakers.net is een pwa en werkt prima, ongeacht of je een Pixel, iPhone of Huawai zonder play store hebt.
Ik vind het zelf maar een gedrocht de pagina van Tweakers op een telefoon.
Alleen als het echt noodzakelijk is om iets op te zoeken bekijk ik deze op een telefoon.

Gelukkig doen de rest van de tech sites wel aan native apps.
Het enige wat er wellicht 'schort' aan de Tweakers app (om het te vergelijken met een native app) is dat het geen SPA is en dat we dus wachten op page refreshes (wat het net iets minder vloeiend maakt). Ik weet niet of jij de Tweakers app destijds hebt meegemaakt, maar dan heb ik toch 1000x liever de huidige situatie.
Geen SPA is voor mij juist een plus, vooral bij iets als een nieuwssite. Anders krijg je gedrochten die pagina's proberen na te doen, maar dan net iets missen wat een browser wel heeft, zoals het onthouden van je scrolpositie als je heen en weer bladert tussen pagina's, het niet kunnen openen van een link in een nieuw tabblad, het niet paars kleuren van linkjes die al bezocht zijn — wat veel websites dan weer overschrijven met css, want het is niet mooi of zo — enzovoorts. SPA zijn handig als je een applicatie maakt, maar een webbrowser is een prima documentenweergever, dus probeer de functies die het heeft qua bladeren en bijhouden van pagina's niet opnieuw te implementeren als dat niet nodig is. Halfgebakken herimplementaties zijn irritanter dan de witte flits van minder dan een seconde.
Dit zijn allemaal elementen die je prima kunt oplossen met een dergelijke spa. Ik vind page loads ook geen probleem, maar ik ben ervan overtuigd dat over een tijdje alles SPA is, zonder alle issues die jij noemt.
De app was echt geweldig, zo jammer dat die weg is :'(
De tweakers app die ik ooit heb bekeken (toegegeven, jaren geleden) was zo veel minder dan de webpagina via de browser dat ik de app er heel snel vanaf gegooid heb en via firefox ben blijven browsen. Zowel op de desktop, laptop, tablet (samsung tab 2, tab S 2 en ipad 2) als android telefoon. Daarbij vind ik tweakers.net een voorbeeld pagina over hoe ze met de verschillende platformen om gaan.
Als iemand die Tweakers vaak op zijn mobiel bekijkt en deze prima vindt werken en ook eigenlijk geen andere tech sites bezoekt: wat doen die apps van andere tech sites beter? Wat voor functionaliteit of layout maakt het dat die apps voor jou geen 'gedrocht' zijn?

Zelf bezoek ik wel vooral nieuws / artikelen en de pricewatch, geen andere functionaliteit.

[Reactie gewijzigd door Ultimus XI op 23 juli 2024 07:18]

In tegenstelling tot het goedkop in elkaar prutsen van apps?

Waarom denk je dat ze wel aandacht besteden aan native apps, maar niet aan websites? Beiden zijn eerder crap of beiden zijn prima
Ik kan je niet vertellen waardoor het komt maar veel mobiele websites of webapplicaties werken gewoon niet zo lekker als een native app. Soms is de native app qua features niet echt heel sterk maar het verschil in UX is vaak dag en nacht.

Nogmaals, je kunt met web echt mooie dingen bouwen en ik heb ook vaak gezien dat simpele apps gebouwd in een Webview wél vrijwel onherkenbaar waren als niet native maar op de een of andere manier werkt het gewoon meestal niet zo lekker.

Waar het aan kan liggen:
  • Widgets lijken niet op native
  • Animatie performance is minder of animaties ontbreken in het geheel
  • SE (in ieder geval de kleinste) schermgrootte wordt niet getest
  • Bouwer is een iOS / Android fanboy die niet op het andere platform test (bij een Ionic app moet je door de Appstore checks heen, of je het wil of niet)
  • Minder goede integratie met native capabilities
UX heeft bar weinig te maken met of het een native app is of niet. Meer met hoe de oplossing zelf gedeveloped is. Als hjet niet meer is dan het herschikken van wat div's om alles passend te maken op het kleine scherm ja dan is het geen dendere UX. Maar een native app betekent niet automatisch betere UX.
Onzin, alles binnen iOS is primair bedoeld voor een touch UI en als je helemaal niets doet (qua standaard groottes, fonts, kleuren, lettertype, controls) dan werkt het al fantastisch voor een mobile UI. Gewoon sleur & pleur in Interface Builder. Je hebt navigation controller segues of modal presentation als makkelijkste manier om een scherm te laten zien. Wil je het slechter doen dan moet je extra werk verrichten. Je moet kortom je best doen om het niét te laten werken.

Bij web moet je dat bouwen. Vervolgens werken standaard dingen als swipe to go back vaak niet. Of zijn knoppen die in de navigatiebalk boven zitten niet veel groter dan dat ze lijken zodat je ze ineens steeds mist omdat je verwacht dat ze net zo makkelijk te raken zijn als native knoppen. Ziet de back knop er anders uit en scroll je eerst naar boven voordat je terug gaat.

[Reactie gewijzigd door BikkelZ op 23 juli 2024 07:18]

Je kan letterlijk voor een mobiele web interface alles bepalen hoe het moet zijn net zoals dat bij een native app het geval is. Als jij een iOS interface wilt voor je mobiele website dan kan dit (naast zo geweldig is de iOS interface niet voor bepaalde interacties,). Er zijn genoetg touch first web frameworks die precies hetzelfde doen.

Ook voor web zijn dit soort UI kits gewoon kant en klaar beschikbaar, niemand wilt dit gebruiken alleen omdat jou interface dan bar weinig mogelijkheden heeft qua branding.
Je kan letterlijk voor een mobiele web interface alles bepalen hoe het moet zijn net zoals dat bij een native app het geval is.
Dat het kán wil niet zeggen dat het gebeurt. Wist jij überhaupt voordat ik het zei dat UINavigationBar buttons nog een centimeter uitsteken onder de navigation bar? Dat zijn kleine irritaties die zich opstapelen tot dit "dit is gewoon niet zo goed als een echte app" gevoel.
Ook voor web zijn dit soort UI kits gewoon kant en klaar beschikbaar, niemand wilt dit gebruiken alleen omdat jou interface dan bar weinig mogelijkheden heeft qua branding.
Daar hebben de standaard controls binnen iOS of Android weer geen last van. Je kunt het standaard laten of zo gek maken als je wil.

[Reactie gewijzigd door BikkelZ op 23 juli 2024 07:18]

In de praktijk blijken native apps statistisch voor een mindere ervaring te zorgen. Mede omdat het een extra stap is voor de gebruiker om daadwerkelijk te downloaden, daarintegen ook vanwege de vaak extra metric maar ook voor een groot deel omdat de interface vaak mede door luiheid van de designers/developers niet perfect is toegespitst op het doel van de applicatie. Dan is die extra 1cm navigatie balk geen factor. Dit is dan ook voornamelijk de mindset van een developer dat je projecteerd en niet van een eindgebruiker. De voornamelijke reden dat native apps nog gepushed kunnen worden is voornamelijk 2 redenen. Extra metric vergaren (Reddit app bijvoorbeeld) of native functionaliteit van een toestel kunnen aanroepen, denk aan bijvoorbeeld bepaalde camera functionaliteit. Uiteindelijk gaat het bij UX design niet om wat ik of jij vinden, het gaat er om wat de eind gebruikersgroep verwacht van de interface en daarbij wordt bij elke grootschalige user test dat ik heb uitgevoerd een web app verkozen boven een native app als we van start tot finish tracken.
Daar hebben de standaard controls binnen iOS of Android weer geen last van. Je kunt het standaard laten of zo gek maken als je wil.
Dat geld voor kant en klare frameworks ook. Het ging mij er om dat je de look en feel van standaard iOS of Android design elementen ook kant en klaar voor web frameworks hebt liggen.

Het enige wat je webapps kan aanrekenen in selectieve gevallen is de zeer minimale uitvoering het adapten naar een mobiel platform. Maar dat gebeurt bij native apps ook waar alleen standaard meegeleverde componenten worden ingezet zonder iets met precies maatwerk te desigen voor de perfecte interactie.
Dit zal nog meer developers er van weerhouden een goede native app te maken in plaats van lekker goedkoop een webpagina in elkaar laten prutsen.
Hoezo goedkoop? Staat ook heel veel goedkope meuk in de App Store's.

Uiteindelijk gaat het om de meerwaarde van zo'n app voor de doelgroep (jou bijv.). Niet om de techniek.

[Reactie gewijzigd door JorzoR op 23 juli 2024 07:18]

Hangt er van af.
Voor veel zaken is een webapp net beter. Dank aan bv nieuws sites, sociale media.
Voor mij is een native app pas nodig als er locaal echt logica moet gedaan worden of er offline mogelijkheden moeten zijn.(navigatie, domotica in huis,...)

Beide hebben hun bestaansrecht en hun voordelen.
Voor bedrijven zijn er zat redenen om te kiezen voor een PWA in plaats van een native app. Uit de survey van stackoverflow werd bekent dat 70% van alle ontwikkelaars bekend zijn met talen/technieken zoals Javascript, CSS en HTML.

Tegenwoordig is het erg gemakkelijk om met deze stack een leuke app in elkaar te zetten die vaak het zelfde kan bereiken als een native app. Dit heeft als voordeel voor een bedrijf dat je niet opnieuw personeel hoeft te zoeken wat bekend is met Java/Kotlin (Android) en of Swift (IOS). Je kunt dus gebruik maken van het talent dat je al in huis hebt.

Er zijn natuurlijk ook een aantal redenen om niet gebruik te maken van de bovengenoemde technologieën om een app te bouwen. Je bent vaak afhankelijk van Third Party Dependencies en het is maar net hoe snel deze updaten om compatibel te zijn met de nieuwste versie van Android of IOS
Een ander probleem dat ook meespeelt is dat een native app pas na goedkeuring van de winkel eigenaar geüpdatet kan worden. Met een PWA kun je dit enigszins omzeilen. Vanuit een beveiligingsoogpunt kan dat ook als een nadeel worden gezien overigens. Maar voor ontwikkelaars maakt dit het wel makkelijker om de app up2date te houden. Met name Apple wilt nog wel eens lang doen over de verificatie van een app, dat kan in vervelende gevallen betekenen dat een app een week lang niet goed functioneert doordat er bijvoorbeeld een bug in zit.
Als je kijkt naar bijvoorbeeld React Native, dan heb je al gauw 15000 packages voor iets wat "Hello World" niet echt te boven gaat. Als Android update: React Native update. Als iOS update: React Native update. En dat dan bovenop de bestaande build en deploy systemen van beide platforms.

Ik heb in 2012 in Objective-C een applicatie gebouwd, daar hoef ik nauwelijks wat mee te doen om hem bij te houden. Wie heeft er een op JavaScript gebaseerde applicatie uit 2012 waarbij alles nog in een moderne browser werkt en je geen enkel veiligheidslek hebt in één van de dependencies? Al waren web apps in 2012 nog niet zo gek complex als ze nu zijn natuurlijk - ik wil niet weten wat je moet doen om een React Native applicatie up-to-date te houden tot 2028.
Zo is dat, duurder is altijd beter en de klant betaalt toch wel. 🤷🏿‍♂️
Vaak genoeg is een native app niet nodig. Als een progressive web app goed gemaakt is dan werkt het best lekker. Alleen zijn er op dit moment niet veel goed gemaakt, omdat voor veel dingen native toch net wat beter in elkaar steekt.
Lekker goedkoop. Je hebt geen idee wat er bij een goede pwa allemaal komt kijken. Je mening over native apps deelde ik vroeger ook, maar die begint toch echt (voor Android dan tenminste) aardig achterhaalt te worden.
Anoniem: 1350842 @Aaargh!14 april 2020 13:45
Voor een hele zooi aan websites is een webpagina natuurlijk prima. Waarom moet een nieuwssite perse een native app zijn ipv een website, wat is de toegevoegde waarde daarvan?
Wat je nu juist krijgt is een legio aan apps die zijn gemaakt omdat er een app moest komen. Als je nu bedrijven niet dwingt om een app te maken in een progameertaal die ze niet kennen wordt de kwaliteit alleen maar hoger denk ik.
Totdat Apple je app uit de appstore flikkerd omdat het niet conform hun verdien model is.
in plaats van lekker goedkoop een webpagina in elkaar laten prutsen
Volgens mij heeft Femme Taken destijds lekker goedkoop Tweakers.net in elkaar gezet en daarmee alle duurbetaalde initiatieven van de grote bedrijven ver achter zich gelaten. Moraal van het verhaal: het gaat om wat je doet, niet om wat het kost.
In je (en mijn) dromen. Dan gaat hun verdienmodel voor een deel stuk.
Safari op iOS is nu al de nieuwe internet explorer aan het worden omdat ze allerlei nieuwe api's die concurreren met native apps weigeren te ondersteunen.
Ga er maar niet van uit, een bedrijf dat de data van een applicatie wist nadat die een week niet gebruikt is, zal niet graag meewerken met zulke standaarden.

Apple wil zijn geld blijven verdienen aan de app store en ontwikkellicenties. Zodra er ineens een alternatief komt dat cross-platform werkt zijn ze natuurlijk meteen die markt kwijt.

Tot die tijd zul je dus PWA-achtige sites in vage Cordova-achtige systemen tegenkomen op iOS als de keuze wordt gemaakt om met webtechnologie te ontwikkelen. Dat zijn nog steeds apps bestaande uit een webbrowser met een laagje, maar daarmee kan Apple wel een percentage van abonnementen die bedrijven verkopen eisen.
Ik lees hier vooral meningen, maar tal van studies en echte metrics bewijzen net dat PWA's zeer voordelig zijn voor bedrijven. Niet alleen is het goedkoper om te ontwikkelen, het is ook toegankelijker. Je bereikt er gewoonweg meer gebruikers mee.

Iedereen die hier zonder redenen "NATIVE!" zit uit te roepen gebruikt waarschijnlijk dagelijks een paar apps gemaakt met webtechnologie zonder het te weten.

Native zal altijd wel sneller zijn, maar het verschil is in de meeste toepassen nagenoeg onmerkbaar. Waar je vaak op zit te wachten zijn calls naar de server, en die gebeuren weliswaar even snel.

Een punt dat je ook niet mag vergeten is dat PWA's via chrome of eender welke tussenlaag ook gewoon native api's aanspreken.

Wel moet gezegd worden dat een PWA niet altijd de juiste keuze is. Maar die keuze is toch niet aan ons ;).

[Reactie gewijzigd door bruinebeer op 23 juli 2024 07:18]

Ik lees hier vooral meningen, maar tal van studies en echte metrics bewijzen net dat PWA's zeer voordelig zijn voor bedrijven.
Het is wel érg makkelijk om dat te roepen zonder vervolgens bronnen aan te leveren. :Y)
Ik kijk veel naar tech talks op youtube.. moeilijk om allemaal bij te houden, maar een case die ik mij herinner is FlipKart. Een startup die momenteel met Amazon om marktdominantie strijdt in India.

https://www.youtube.com/r...ge=&utm_source=opensearch

Verder raadt ik je aan om gewoon want rond te zoeken op het internet naar case studies, het zou je kennis wel eens kunnen verrijken!

Op dit item kan niet meer gereageerd worden.