Hacker News new | comments | ask | show | jobs | submit login
Google Play Store Now Open for Progressive Web Apps (medium.com)
256 points by jbuild 14 days ago | hide | past | web | favorite | 78 comments

One of the wonderful things about a PWA is that it is so freeing (no app store gods to appease for approval etc etc). I'm a little afraid that putting PWAs in an app store may actually reduce the flexibility they offer by restricting what PWAs can and can't do. Then again, an app store may be a necessary to allow PWAs to diffuse into mainstream usage.

Personally, I am looking forward to the day PWAs are considered on par with native apps by the general populace. I think we're getting there in terms of functionality and flexibility - I run https://usebx.com/app which is a PWA, and my users are pretty happy with the functionality it delivers on all platforms. It also helped me launch with a smaller budget, since it's a single code base that runs on desktop, mobile or tablet.

The one thing I will add is that building a high-quality, performant PWA is significantly harder than building a native app - why? because you really need to understand the workings of modern browsers to squeeze native like performance, and unfortunately, in my experience, very few web developers have that depth of understanding. I have been building web apps for 20 years (I started young), but when I decided to build Bx as a PWA, I had to learn a lot to achieve the quality I desired.

That's not the issue. The TWA has been created specifically on the request of app creators (including me).

The problem is that users find PWA very difficult to install. Like massively hard. They are used to the "app Store installation model" - they search for stuff, they click install, they check for permissions and then apps are available in their dock.

This model breaks down in a PWA "add to homescreen" kind of experience. In fact, it is hard to explain what a "homescreen" is in vernacular languages.

The TWA is a massive jump in usability - publishers can now work using web technologies and users can still get the same experience. This is what will unlock web use on mobile phones.

I think app stores are a great discovery tool for PWA. Searching for PWA in a centralize marketplace will most likely be one the tipping points of PWA, and putting amd emphasis on the "app" point.

If their goal is to be the same as native apps, putting them together makes them even closer to that objective

Well I find myself not using the app store anymore because it's useless to find apps.

There are no filters and no way to order results.

Top downloads sometimes have worse scores than indy apps that only have a hundred downloads but work much better.

I don't understand the love that PWAs get around here. All things being equal, as a user I'll chose a native app every time.

As a developer, I'd much rather be working in a native toolkit as well. There's less to learn to get going and the foundations are more stable than the browser and billion lines of javascript from 40 different parties.

I also think it's a lot harder to reason about security with a web app. I might be able to satisfy myself that the app I load today isn't doing anything nefarious, but you could sell your business and tomorrow I might be running a significantly different app.

> There's less to learn to get going

There are thousands of pre-existing web developers for whom this is not true because they've already put the effort in to learn the web platform. For these people, PWAs represent significant new functionality which they can now use without having to learn a whole new toolkit.

You may be dramatically underestimating just how many web developers there are.

> I also think it's a lot harder to reason about security with a web app.

I'm not sure that's true, because the web runtime itself tends to provide quite good security (partly because it doesn't allow access to a lot of device APIs in the first place). Native apps are often granted quite wide permissions, and auto-update by default too.

I don't like Web Apps, but there are a huge class of Apps that doesn't require a Native App to work. Services Sector which already has their Web Platform sorted out, and are only providing an "App" in the App Store. Paying for App Development is expensive, when majority of the functions in these Apps are exactly the same as online. Having PWA meant they could offer an "App" at a ( relatively speaking ) much lower cost.

Example, why would every Restaurant wants to have an Apps of its own?

That is of course assuming PWA for these kind of Apps work close to Native App in performance and usability. Time will tell.

> Example, why would every Restaurant wants to have an Apps of its own?

Why would any restaurant have an app?

> close to Native App in performance and usability

Javascript in the browser will never be close to a native app as far as CPU, battery, memory, and bandwidth utilization goes. I don't think they will ever work as well with assistive technologies either.

> All things being equal, as a user I'll chose a native app every time.

The reality is that most potential users don't install native apps, and will use a PWA without knowing it. Its just a URL.

Numbers are still as high as 20% don't install due to lack of space. Thats a ridiculously dumb bounce rate.

"Solutions" were presented already 3-4 years ago, for android. Native apps that don't install! And hey look, nobody cares!

Well, from a user perspective you might enjoy having an app on every platform. So no need to wait until the developer rebuilds some app on a new platform. No need to bother the dev to port his app to Mac/Linux/BSD/(other non-mainstream OS).

In my opinion, the single most reason not to use a PWA from a user perspective is the performance. But I still use my Samsung S3 and when I look at the current flagship smartphones... They have more RAM and CPU cores than many laptops nowadays.

So I think the performance issue is going to be much less relevant. Others might say that usability is an issue too, but with the upcoming component libraries, that is going away too. After all, projects like framework7 [1] support quite good components already.

[1]: https://framework7.io

> As a developer, I'd much rather be working in a native toolkit as well.

Across multiple OS?

Definitely. The last thing anybody wants is to run an application on a Mac that looks and acts like a Windows application. How could you be proud of that?

I don't think that's even remotely true.

For example: Photoshop, Autodesk Maya, Da Vinci Resolve, Premiere, Ableton Live, and a very long etc. Those are not your crappy Electron apps, but industry standards.

I find people generally overplay the "all apps must look native on my OS" card as an argument against PWAs. Yet they are often very happy using Google docs for most of their day to day work... I personally like the fact that a web app looks the same across all OSes. I find that is a better type of consistency to aim for, in that if someone changes their OS, they don't need to relearn your app's UI.

In terms of the web one could use different stylesheets for the different platforms... the business logic can stay the same. OnsenUI and ionic are providing just that.

So on Windows it feels like a Windows app and on Mac it feels like a macOS app? All of the widgets work the same as native controls with accessibility devices like screen readers?

It's only about expectations.

When you open your web browser you suddenly expect apps you access there to be the same across all OS, and you certainly don't mind them all being different from each other - it's actually a good thing.

So why shouldn't we expect the same of native OS? I know I care only about few details - like native notifications instead of custom ones, native close, minimize, maximize buttons etc.

I wrote an article on why I think PWAs are the future in my opinion: https://osrec.co.uk/publication/3/Why_PWAs_may_be_the_Future

Maybe it'll help you see things from another perspective :)

I've read this before and I get what you are saying. From a business point of view it makes a lot of sense. I'm saying from every other point of view, it doesn't.

> I'm sure you'll agree that having a standardised platform that runs on any machine, while being unlimited in the variety and nature of things it can conjure is the utopia we are all working towards.

Are you talking about Java + Swing? :)

I like that macOS feels different from Windows and that I can load up a Linux with many more variations that all have their own personality. I don't like how web apps use my bandwidth (I pay $10 / GB on Google Fi), how they use my battery, or my CPU.

> I pay $10 / GB on Google Fi

Wait, what? That is insanely expensive. I pay far less even on just 4g. Is that a normal price there?

I don't use a lot of data so my monthly phone bill is usually under $35. That doesn't seem unreasonable to me.

But is that something normal in the US? I live in a remote location in Europe, I pay 19 euros and download/upload well over 100gb per month.

Any good resources on developing that kind of understanding? What sorts of things would a web developer need to learn?

I don't have a list of resources, but here is a not-so-comprehensive list of things I find important:

  1) Understand how requestAnimationFrame() works
  2) Understand how setTimeout() works
  3) Know how to minimise the number of DIVs you have in the DOM at any one time
  4) Understand the touchstart, touchmove and touchend events properly.
  5) Understand the browser viewport model and the vw, vh CSS units. These units can even be used to scale text, which, if done well can allow for truly responsive text scaling.
  6) Understand the various layout engines. Grid is good for static layouts, Flex is great when you want to animate things.
  7) Understand the different element positioning modes. I'm amazed how little most web devs understand absolute and relative positioning. Understanding this is super useful.
  8) Understand promises properly. Understand async/await and try/catch. Understand Promise.all() and Promise.race().
  9) Understand what 'this' means and how func.call() works in Javascript
  10) Understand indexedDB and localStorage
  11) Be aware that any Javascript on a page executes in a single thread
  12) Understand which JS likely to trigger a "recalc" and "repaint" in a browser
  13) Become a master of your browser's dev tools and be comfortable debugging asynchronous code.
The MDN pages for a lot of the above are pretty good - all the best :)

Don't know how much of this still applies (2011), but it's a good starting point:

How Browsers Work: Behind the scenes of modern web browsers https://www.html5rocks.com/en/tutorials/internals/howbrowser...

> I think we're getting there in terms of functionality and flexibility

One big thing that is missing IMO is getting out from under the 5% quota. If you want to write a "serious" app that might store large amounts of data locally you are under constant threat of your data being arbitrarily deleted from the device.

This should help alleviate the issue somewhat: https://developers.google.com/web/updates/2018/11/writable-f...

Your demo login is broken. I don't want to sign up for understanding your product.

Apologies - there was a subtle race condition in our code which meant that if you try to log in to the demo at the instant we're resetting our demo's data, you end up using stale demo credentials. This has now been fixed :)

Also want to report this. Running safari on an iPad, fwiw, but it looks like the username/password for the demo user are just wrong.

Sorry about that - we have a cron job that resets the demo user data every few hours. Sometimes if you happen to catch it just at the moment we're resetting, a bug in our code means the demo credentials used by the frontend to log in to the app are stale. If you refresh, you should be okay now :)

Edit: my dev has just issued a fix for this bug, so it will not be a problem going forward!

Thanks — much appreciated!

You application looks quite nice.

I do prefer native to Web, but also have spend the large majority of project assignments on the Web side.

If PWAs everywhere get the same capabilities as in UWP, then I really admit defeat on my preferences. :)

On my specific case, it would be so nice to finally have WebGL catch up with ES 3.2 at very least.

What's UWP?

The future of Windows APIs, aka COM Runtime.

Ah, thank you!

Nice work. How many users? Are using some cloud services for the backend? Thanks in advance

Just over 100k users. All of the backend is managed by ourselves - no cloud services, apart from the servers/hosting.

Wow. This is big.

Do you have some blog? Explaining technologies, knowledges and etc about this app? How did you grow to reach 100K users?

Thanks in advance, and congratulations.

  I'm a little afraid that putting PWAs in an app store
  may actually reduce the flexibility they offer by
  restricting what PWAs can and can't do
Not sure what you're saying here. Are you afraid that app store policies (privacy requirements etc) will be stricter than what you can do with browser APIs, or that the app store will ban API abuses that're currently necessary for acceptable performance/usability?

The web is analogous to an untamed forest. It's got a bit of everything in it, and you can choose which parts of the forest you wish to go to. Don't like app XYZ because it locks up your CPU? Don't visit its URL. If you like and trust app ABC, use it regularly. It's like when you visit a restaurant - if the food's good, you go back. Otherwise you don't. I feel people are smart enough to work this out on their own without needing a corporate app store to set out rules for everyone.

If we start to restrict the web, I feel it takes away from what makes it great; the fact that it's a platform for untamed creativity and choice.

I think its a good change. There are a fair bit of apps that should have been web pages but the owner wanted something on the app store.

wow you're app is really nice! superfast too

Thank you! We've got version 2 coming out at the end of the month which aims to make it a bit quicker with more functionality :)

Is the UI entirely custom-made or do you use any framework for that?

We built our own framework, but do make use of d3 for charts and jQuery for cross browser events. We modified d3 a bit to make the animations more performant.

Apparently he/she used jQuery, jQuery UI, and D3.

It's amusing that Microsoft is still the one embracing PWAs most - Win10 app store allows to publish them directly (you have to upload a package, but all that package contains is the URL for the actual app, and name and icon for the store). But then there's also Bing PWA crawler which finds and adds existing apps.

It's literally the reverse of early 00s, when Microsoft was entrenched with rich desktop GUIs, and everybody else was hoping that web apps would be the way out of that lock-in. And now iOS and Android are the rich UI lock-in...

> you have to upload a package, but all that package contains is the URL for the actual app, and name and icon for the store

Shameless plug: you can use https://pwa2uwp.fragara.com/ to create such a package (an appx package), using nothing but your browser and curl.

Actually Flutter allows to create Material apps on iOS, and iOS-themed apps on Android.

Will the developer need to give 30% of the progressive app price to Google (if it is in the play store)?

sorry in advance, if this has already been mentioned somewhere.

Yes. The "Trusted Web Activities" (TWA) API referenced in this article is just a convenient way to turn a web page into an Android Activity. (An Activity is a screen in an Android app.)

They don't let you paste an URL into the Google Play Store and convert it to APK automagically. You still have to install Android Studio, build your app as an APK, and upload it.

You could do this before by coding up a full-screen WebView, but TWA is just nicer in a number of ways.

If your app is a paid app, you'll pay Google 30% of that. TWA offers no convenient way to do in-app purchases; if it did, you'd still have to pay Google 30% for those IAPs.

> You still have to install Android Studio, build your app as an APK, and upload it.


Not having to do that was what I was hoping for with stores allowing PWAs. Maybe it at least means that the APK only needs to be built once? If it has to be rebuilt for every release, I don't see what this offers that Cordova can't do better.

From the article:

"Is TWA a Hybrid framework, similar to Cordova?

No. With Cordova or other hybrid solutions, you are typically shipping your web resources (HTML, JS, CSS, etc.) within your APK package. Also, the engine is different and isolated from the users’ browser, so no session or cache sharing.

With Trusted Web Activity you don’t need to package any resource file from your PWA (only native components, in case you want them); all your resources will be downloaded and updated on the fly from your Service Worker. Your PWA will still be rendered with the installed Chrome version, sharing all storage, cache, and sessions with the browser. Therefore, if your user has a session on your website opened when the user installs the app from the Play Store, she will still be logged in. The user is just installing a shortcut to Chrome using a special mode."

So what's the point of the APK?

The OS needs an APK to run it. Just opening your page in the browser won't let you customize as much.

To contain the metadata for the store entry?

You'll also be switching to a payment provider you can never contact.

I think Google customer service has gotten better, last time I called I had a human in 3 mins or so.

Not sure how useful those humans are on average, though. The one I got was helpful.

If I already have a web app with a built-in recurring subscription functionality, I shouldn't be required to abandon it just to get it published on the Google Play Store.

The entire idea of allowing PWAs on Google Play Store seems to be a part of Google's wider product strategy, which includes ChromeOS and Android Go, where using a native app is not always the best choice.

Microsoft Store has already been doing this for a while for a different reason: a lack of Windows alternatives to the most popular mobile apps.

Apple, on the other hand, has no business case for integrating PWAs into the App Store, because they would just reduce its revenue.

If they allow PWAs to get around the 30% IAP feature, then in 5 years there will be no more native apps, only PWAs. I doubt they will allow any non-google play in app purchases to take place.

I think the essence of a web app is that it works on any platform. It shouldn't know anything about Google Play Store or Apple App Store. Otherwise, it's just a native app with a webview.

They are called PWA, not WA, with P meaning Progressive.

The idea is that the app should check for available browser/OS APIs that progressively enhance user's experience.

And no they aren't necessarily just a native app with a webview, on UWP a store delived PWA has full access to the UWP APIs, just like .NET and C++, no need to write extra FFI manually.

No need for Frankenstein solutions like Cordova.



Team member here. You have to abide by all the rules of the store to be listed in the store.

> TWAs work only with Chrome today, but the API might be also cloned by other browsers, such as Samsung Internet, Edge or Firefox in the future.

It's too bad it's Chrome-only now. But very good that using another engine is even possible.

Can a user have as much control over a PWA as it's running in a browser instance compared to loading the site in regular Firefox mobile?

In other words are PWA a way for people to write and run web apps but making sure the user can't run adblockers?

Depends on the host OS.

On Windows 10, PWAs are just another way of doing UWP native apps, as they replaced the former JavaScript language projection (WinJS) introduced in Windows 8.

That’s a good point. My guess is that extensions do not run when a PWA is installed and launched in standalone mode.

PWAs along with Web Payments and WebAssembly seems like it will make big changes to the way the web works. It's blurring the line with web and native even further.

I'm pretty confident that this is Google's long-term strategy and why I think chromeos will become popular in future.

Firstly it needs to move beyond an US centric market.

There has been a production TWA in the Play Store for a while now - https://play.google.com/store/apps/details?id=com.google.and...

Works brilliantly.

I couldn't figure out how to mute voice directions during navigation

Is there a way for me to tell TWA to then tell Chrome to report itself different in the meta data? There are services that I use that do not work properly when the source identifies itself as a mobile browser. Currently with Cordova, you have have it change the headers on all requests to report a different browser OS.

This is cool but I tried yesterday to figure out what was going on in the samples and it still super green.

It looks like you have to still write Android code to do this. There is a sample that has no code in it ... but it is not documented.

Hopefully over time they will get the process worked out.

It would make a lot of sense to use Node.JS as a backend service for your web app, instead of a Java app. It's much easier for a web developer to use JavaScript then to learn Java, or Objective C. The API would be implemented with Node.JS modules.

This is actually huge news. I'm really excited about this!

I'm the author of a document management and annotation platform named Polar:


I'm working on the web+mobile version built on Firebase.

The PWA should be straight forward but don't want to have to build another mobile app for it.

With PWA this is going to be 100x easier.

Additionally, the Play Store is a major source of new users.

One of the things most independent app developers don't think about is distribution.

Being in the Play Store means people have another chance to find your app!

im following your steps and waiting for web&mobile to getpolarized ! any ETA to beta test ?

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact