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.
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.
If their goal is to be the same as native apps, putting them together makes them even closer to that objective
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.
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 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.
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!
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.
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.
Across multiple OS?
Maybe it'll help you see things from another perspective :)
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.
How Browsers Work: Behind the scenes of modern web browsers https://www.html5rocks.com/en/tutorials/internals/howbrowser...
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.
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.
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
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.
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...
Shameless plug: you can use https://pwa2uwp.fragara.com/ to create such a package (an appx package), using nothing but your browser and curl.
sorry in advance, if this has already been mentioned somewhere.
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.
:(
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.
Not sure how useful those humans are on average, though. The one I got was helpful.
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.
It's too bad it's Chrome-only now. But very good that using another engine is even possible.
In other words are PWA a way for people to write and run web apps but making sure the user can't run adblockers?
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.
Works brilliantly.
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.
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!
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.
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.
Edit: my dev has just issued a fix for this bug, so it will not be a problem going forward!
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.
https://developer.microsoft.com/en-us/windows/pwa
https://docs.microsoft.com/en-us/microsoft-edge/progressive-...
"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."
> 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.
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.
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.