I wrote this post together with a colleague for my current company’s blog, and I publish it here too – with some slight modifications.

We hear a lot about this new technology, and there are already a lot of productive systems using it – like WhatsApp or NASA. But what is it about exactly, what advantages do Progressive Web Apps bring us, and where are they positioned between native and cross-platform apps? I want to introduce you to the subject, without getting too technical.

But let’s start with the challenges  we are facing currently, and for which PWA’s can be a solution…

Challenges

Lots of platforms

In a typical software project, you have to cover at least three different platforms nowadays.

• iOS App
• Android App
• Web Page

So in the end, there are three different products that often cover the same pages and use cases, but they have to be implemented in different ways, and with different technologies. And needless to say that each of these parts have to be tested separately. So not only do you need specialists for each platform, but you also have a lot of redundancy in testing.

Of course there are cross-platform solutions like Cordova or Xamarin, but do they cover the web page itself? And also, there’s always platform- and/or version-specific code involved. And still, you have to test the mobile app on the different platforms.

Availability of the app

Another question is ‘How does the app get to the user?’. From a developer’s perspective, you always have three different ways (in our ‘typical project’).

• Publish the iOS app to the App Store
• Publish the Android app to the PlayStore
• Host the page on a web server

Whoever published an app somewhen knows the pain that it can cause – like license costs, signing and a lot of platform specific regulations. It can also take days to publish an app or update, and for time critical fixes and features, that can be a problem.  And from a user’s perspective, you have to install the app on the phone, using App Store or Play Store. In many cases, users don’t even try an app, because of this step.

Publishing a web page on a server doesn’t bring these problems – you can put almost anything there and the people just open it with their browsers. But this ‘easy’ approach also brings problems. The most obvious is, that the page is only available when connected to the Internet. If an application is supposed to have local data – like a record of your running tracks, or the messages received earlier, a web page is already out of the game. And from a UX standpoint there is to say, that you can never compare a page inside a browser with a local app that appears with a splash screen and fullscreen mode, without ever showing standard controls and text url’s like in a browser. Apps are just so much nicer!

Connectivity to backend

And last but not least, it’s about the data for your app or page, and the biggest technical challenge for almost each project. To not make the subject too big for this post – because there’s a lot to tell about this – let’s put it into three app states:

1. App is online
2. App is offline
3. Connectivity is poor

(1) An existing, fast internet connection is the happy path for each programmer and user. Just load and write the data directly from and to the service. And when it’s not available, the app or page is just showing a ‘sorry’ sign.

(2) The offline state is already challenging. Usually this is ‘solved’ with a complex synchronisation mechanism, trying to keep database content and documents in sync with the server. You ‘just’ need a local database and access to the file system. And conflicting datasets can be solved automatically or with user interaction.

(3) The poor connectivity is the case that is not solved properly in most of the applications and web pages nowadays.The OS thinks it is online, but the connection is extremely slow (this is often referred to as LieFi). In this case, it’s almost impossible to guarantee a good user experience. Of course you can keep the UI alive at all times, with async programming and loading animations, but the user gets frustrated all the same.

Security

From a security standpoint, native applications have the advantage of the checks that are being done during the publishing procedure in the specific stores. Also, apps are being built directly on top of native APIs, which reduces complexity and weakness.

Web applications can naturally be anything, and you depend on trusting the page provider and the browser implementation, to not expose your device resources. And of course there is more complexity involved, and therefore there are more possible security loopholes.

Solution

Let’s see what PWA’s have to say about the different challenges analysed in the previous part.

Lots of platforms

There’s just to say – a PWA is technically a pure web application (for example with Angular), just with an additional (Javascript) Service Worker implementation. So it runs in any browser supporting it. And this is already the crucial point in this subject… Yes, the browser must support the technology, to use all the benefits. Still, you can make it a ‘classic’ web page, and just offer the other benefits if PWAs are supported. If you want to know more about support for Service Workers, I recommend you to follow this GitHub page.

Of course, a PWA isn’t (and never will be) a native application, because it’s running on top of a browser driver. But this is also the case for Cordova apps, and even Xamarin comes with an additional Mono bundle. And those technologies have already proven that it is possible to write performant multi-platform apps with device specific features. Here is a short overview about the interfaces that are available and planned for PWAs:

• Native mechanisms to re-engage users ( PWAs feature list image)
• network proxy
• background sync
• Local storage
• media capture and playback
• device vibration
• battery status
• gamepad (compatibility with usb devices)
• integrated payments
• credential magnagement
• network stream
• bluetooth
• web share
• push notifications

Availability of the app

Like described before, a PWA doesn’t have to be published in any store, but gets published on any webserver. And the installation happens through the browser. In the first moment, the user just visits the page and uses it as usual. Then, he or she has the ability to make it available like an app (it’s even planned for Windows 10 on Desktops). In that moment, it can be used entirely offline.

So from a UX standpoint, this is very interesting. You don’t have to force the user to install an app when he just wants to try it. It can be used like that, and be installed optionally. After this installation, the PWA is available through an icon on the home screen, and starts directly with splash screen and fullscreen mode, without ever showing the browser itself again.

When you need to update a PWA, there are different solutions possible to replace an old service with a new implementation.

Connectivity to backend

Here we come to the online-, offline- and liefi – scenarios. I think, online doesn’t need explanation. When it’s about making data available offline, the strategy is usually to copy files and database entries back and forth, which is usually implemented on business model level.

The basic strategy for PWAs is to implement the offline synchronisation on the communication level. So in any case, the UI communicates directly via http, through the same business logic. But these calls can be processed offline and/or online. The offline data storage could still be a synchronised database, but you could also just cache previous http calls, and recycle them. Or use hard coded data.

Technically, this is a very interesting concept, and even allows strategies like processing http calls offline and online simultaneously, and serve the UI the response that comes back first. This guarantees responsive UI and smooth animations and scrolling, even on liefi connections.

Security

Like discussed before, native apps have some advantages. A PWA can, naturally, be much less secure. But I say ‘can be’ because there are some good concepts and tools to reduce the risk, and ensure security:

• HTTPS is a must-be, but can be turned off for development
• There are pages that automatically test PWAs for weak implementations and typical security loopholes

For the second point, a user would have to trigger this check on his own, in order to trust a PWA before using/installing it. That’s obviously nothing a normal user would do, but this whole subject is still young, and the standards and implementations for PWA support are constantly in development.

Having a look to Google, who has one of the most complete implementations for PWAs available, ‘Lighthouse’ is very interesting:

• it’s a Chrome extension to run metrics on a page, and create a report – link
• npm package to run these tests automatically as End2End test – link

You could also use webpagetest.org which allows to test any page against any device type, and every possible browser. In case of Chrome, this includes lighthouse tests.

In the end, when it’s about security, it’s all about testing and running simulated attacks on your app. When you just have one implementation instead of three, you can concentrate your testing resources. Less redundancy also reduces risks!

Conclusion

There will certainly always be the argument that a PWA is not native, and henceforth not as performant and secure as a native app, and will never feel 100% like it to the user. Probably that’s right, but it’s also very probable that the differences will almost disappear, especially to a normal user. And perhaps there are even users that prefer to see the same controls and to have the same look and feel when they access an application on the PC, their iPhone, an Android Tablet, a Surface computer, on the TV and in the car.

From a development perspective, there are lots of arguments for a ‘one implementation serves them all’ solution. I won’t start with that again 😉

And another very interesting point is this: Since a PWA is basically a web app, the migration for many pages to a full fledged device application is very close at hand! So even traditional online-only, browser-based pages could become offline applications on the home screen of your device.

So finally and most important is the fact, that the big ones work on the support: Google, Microsoft, Apple! In the world of web and apps, it’s certainly no mistake to follow what they agree on! And when Apple first introduced their iPhone 1 in 2007, they went with a concept very similar to PWAs. The only problem was, that there wasn’t the web technology like we have now. And Flash just didn’t meet their standards, or they couldn’t agree on a deal with Adobe. That’s why they went with native apps.

There certainly is a big future for Progressive Web Apps

HAPPY PLANTING

Update 2018-04-04

Apple just released an update to support PWA’s for Safari
https://medium.com/@firt/progressive-web-apps-on-ios-are-here-d00430dee3a7