Progressive web apps have been in the news a lot recently – organizations ranging from WhatsApp to NASA are using the technology. But what are they exactly, and what advantages do progressive web apps bring us? Where are they positioned between native and cross-platform apps? In this blog we want to introduce the topic, but without getting too technical – so this post is for quality assurance (QA) and user experience (UX) specialists, as well as developers and business executives.
But let’s start with the challenges for which progressive web apps can be a solution.
In a typical software project, you cover at least three different platforms:
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.
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’):
Anybody who has already published an app knows the pain this can cause – whether in the form of license costs, signing, and a lots of platform specific regulations. It can also take days to publish an app or an update, and time for critical fixes and features, which can be a problem. And from a user’s perspective, you have to manually install the app on the phone, using the 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 have these problems – you can put almost anything there and 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 a saying, 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 such as in a browser). Apps are just so much nicer!
One of the biggest technical challenges for almost every project concerns the data for your app or page. To not make the subject too long for this post – because there’s a lot to say about this – let’s examine three main app states:
App is online. Here 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 just shows a ‘sorry’ sign.
The offline state is already challenging. Usually this is ‘solved’ with a complex synchronization 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.
Poor connectivity is the case that is not solved properly in most of the applications and web pages. The operating system 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.
From a security standpoint, native applications have the advantage of the checks that are completed during the publishing procedure in the specific stores. Also, apps are 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. Although of course, there is more complexity involved, and therefore there are more possible security loopholes.
Let’s see what progressive web apps have to say about the different challenges we analysed in the previous section.
(support of Service Workers)
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:
As we described before, a PWA doesn’t have to be published in any store, but gets published on a web server. The installation happens through the browser. In the first moment, the user simply visits the page and uses it as they typically would. 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 also use offline implementation.
So, from a UX standpoint this is interesting. You don’t have to force the user to install an app, when he or she 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 the splash screen and fullscreen mode, without ever showing the browser again.
When you need to update a PWA, there are different solutions to replace an old service worker with a new implementation.
Here we come to the online-, offline- and liefie – scenarios. Online doesn’t need an 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 the business model level.
The basic strategy for progressive web apps 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 with the one that comes back first. This guarantees a responsive UI, and smooth animations and scrolling, even on liefi connections.
As we discussed before, native apps have some advantages. A progressive web app can be less secure. I say ‘can be’ because there are some good concepts and tools to reduce the risk, and ensure security:
For the second point, a user would have to trigger this check on their own, in order to trust a PWA before using/installing it. That’s obviously something a normal user wouldn’t do, but this topic is still young, and the standards and implementations for PWA support are constantly in development.
Looking to Google, which has one of the most complete implementations for PWAs available, ‘Lighthouse’ is very interesting:
You could also use webpagetest.org which enables you to test any page against any device type, and every possible browser. In the 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 reduces risks!
There will certainly always be the argument that a progressive web app is not native, and therefore not as performant and secure as a native app, and will never feel 100% like it to the user. And to be fair that’s probably right. But it’s also very probable that these differences will almost disappear, particularly for the 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 their PC, iPhone, 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 fully 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 importantly is the fact, that the big tech giants are working on support: Google, Microsoft, Apple. In the world of the web and apps, it’s rarely a mistake to follow what they agree on. 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. So all in all, there is certainly a big future for progressive web apps.
February 13 / 2020
December 17 / 2019
Digital technology enables organizations to boost productivity and better engage with customers. However, many technology initiatives continue to see cost overrun, damaging the bottom line and undermining the value...Read post