English | EN 
Don’t tell my mother I’m building Secure Progressive Web Apps! She thinks I’m a native App developer working from an internet café.
Progressive Web Apps versus Native and Hybrid: forces are shifting.
Recently I was trying to find some articles on the state of the art of Progressive Web Apps. The purpose was to check if others noticed the same evolution I had, especially when comparing Progressive Web Apps (PWA) with hybrid native applications.
I didn’t expect to find so little meaningful information, and so many outdated affirmations. PWA developers seem to be the guys one needs to hide: a kind a shameful branch of the IT organisation. Well maybe not to that point, but you get the general idea.
Before going further, a disclaimer is required: I’m a huge supporter of hybrid native applications in general and React-Native in particular.
But let’s face it: it’s time for me to swallow my pride.
Coding Progressive Web Apps is nothing to be ashamed of. Cost, functionality, security, available competences, use cases from big players: so many boxes are checked.
Are PWAs for everybody? For sure not. Are PWAs for you? They sure might be, especially if you’re developing business apps. Let’s develop.
Cost of development and maintenance
This is the category where PWA really shine. In the name “Progressive Web Application“ there is “Web Application”. The build process is the same, just adding some features that allow you to access phone native features such as camera, geolocation, fingerprint or face identification, UI libraries, in particular HTML/CSS based libraries, such as BootStrap or Tailwind for the most classic ones.
Unlike what happened in the hybrid world, the probability to have bootstrap or tailwind dropped is very limited. There are plenty of very old bootstrap-based applications running in production. Some are more than 12 years old that still run without issues and pass pen-tests hands on, with limited maintenance costs.
The maturity of CSS frameworks is one key aspect of the lower cost, together with the huge pool of available competences. But that’s for the next paragraph.
Available competences
Any good front-end developer can be a PWA developer. Why “good”? Simply because a PWA requires a more refined UI due to responsiveness, space constraints, and manipulation of mobile-specific APIs. But this is still HTML5 and the CSS tricks continue to produce their magic. Websites have to be fast and responsive for years now, especially when exposed to Google’s SEO algorithms, so the first step already had to be learned.
If your web developers build slow sites that do not match with current state of the art, please don’t ask them to build PWAs. Mobile acts as an amplifier of common issues, in particular performance.
UI Performance
And here comes the great debate: native vs PWA vs hybrid. That’s where the hierarchy becomes blurred.Native is still the fastest, and some demanding apps like games absolutely need to go native.Between PWA and Hybrid-Native (such as React Native) the difference really depends on the app. There are many business apps where the hierarchy isn’t visible anymore: so why is that?
- Phones are renewed more often that laptops. The CPU available on any mobile phone isn’t a bottleneck for most applications.
- Browsers are more efficient.
In fact, in many business applications, where one deals with lists, forms, QR Code reading, and Geolocation, the main reason for slow performance is the number of objects that the UI has to build. The verb “to build” is here used on purpose, instead of “to display”.
And that’s where bad programming techniques have a huge impact. Taking the example of a list, there is a common practise to load new records when the user swipes down for more records, without freeing up the first items in the list. Despite the optimisations present in the frameworks that focus on only redrawing what has changed, those unnecessary objects have a negative impact on performance. This has a big impact on the coding practise, on most cases bigger than the choice of PWA vs hybrid technology.
To get to the hub of the matter, with clean code, business apps can show identical performance on PWA, at a much smaller cost.
Features
The purpose here is not to say that PWA can do anything native apps can: the limitations lie with the browser. A low-level API that can be accessed in native code or bridged by native code in a hybrid application won’t be available.
However, those features are barely used in business apps, and the available feature set is quite impressive:
- Audio playback, including on lock screen
- AR/VR to place app originating objects on real view
- Audio recording
- Authentication with webauthn (Fingerprint, Face ID, USB key)
- Background sync for offline mode
- Background fetch to defer large downloads when app is not active
- Barcode reading
- Bluetooth communication including BLE
- Contact picker (access to contacts of phone upon your authorization)
- Face detection in images
- File System access
- Geolocation
- Local Storage
- Media Capture
- Motion information
- Multi-touch management
- Network information
- NFC access
- Notifications (even when app is not active)
- Orientation
- Payment
- Screen capture management
- Screen lock prevention
- Speech recognition
- Text to speech (synthetic voice)
- Vibration
- Web Share.
Security
A very interesting feature is the support of webauthn without any external device. PWA are browser based, so support the webauthn protocol.
W3C’s Web Authentication (WebAuthn) specification is part of FIDO2, which supports passwordless, second-factor and multifactor user experiences with embedded (or bound) authenticators (such as biometrics or PINs) or external (or roaming) authenticators (such as FIDO Security Keys, mobile devices and wearables). This is an important step from classic password-based authentication: no password nor key is communicated to the service provider, as authentication is based on an asymmetric signature.
I recommend the reading of a very good document from the ENISA (European Union Agency for Cybersecurity) called “Digital Identity Standards”.
The great thing with PWAs running on mobile devices is the native access to Face ID or Fingerprint: so the asymmetric signature is delegated to the phone, turning it into an authentication device.
As a Web App, PWA is served via an https channel and runs on a well-protected browser, making it secure as long as the https communication isn’t compromised.
There is a special case where native and hybrid applications might keep a security advantage: the man in the middle attack. You comfortably installed on a sunny terrace and connect to a free wifi, which unfortunately is hosted by hackers. So far no issues: https is an end to end protocol. But if you don’t pay attention and accept a certificate from an untrusted party who routes all your https communications through his own proxy, then you are exposed. Native and hybrid apps can add certificate pinning, a technique which makes the app check the footprint of the original site certificate. Thanks to this dedicated identification, the man in the middle can be detected and the app stopped. However, this approach is less popular nowadays as it’s complex to maintain.
Finally, “real” apps must pass Apple and Google’s validations to be available on the app stores. But PWA can also be deployed as store apps.
Apple initially wanted to remove the Home Screen web apps in the EU. Reason given was the compliance with the Digital Markets Act (DMA) requirements, even on third-party browsers they don’t control. Finally this decision was reverted due to market feedback, and the Home Screen web app feature is still there. This feature is the one allowing to pin a PWA on the mobile’s Home Screen without having to launch it from an URL.
Demo
Here’s the video of a demo demonstrating a FIDO2 authentication followed by the display of a list, demonstrating the usage of geolocation. This list has been coded intentionally without any optimisation (so by instantiating all 10000 lines since the page load). Despite that, the list displays and scrolls flawlessly, demonstrating the huge gap in performance brought by modern phones (in this case an iPhone 13).
In a nutshell
Like AirBnB, Instagram, Mappy, MakeMyTrip, Next Train, Pinterest, Starbucks, Telegram, TikTok, Uber… Why should you move to PWA?
The answer is straightforward:
- Cost (of available resources)
- Cost (of learning curve)
- Cost (of development)
- Cost (of maintenance)
- Cost (of security, if you already protect web apps)
- Cost (of customer acquisition): being a web site, it’s searchable and once displayed in the browser the user can receive incentives to install it. That’s a great way to have new users try it
Why wouldn’t you move?
- You need the best performance, such as an FPV game
- You need to integrate with native code (e.g.: specific cryptographic operations that you want to run natively)
- You need access to special native APIs not part of PWA scope.
In any case, you should at least consider the option, and spend some time to explain to your mother that native isn’t the only option.
PWA Demo Credits : Roman Merck – Sogeti Luxembourg.
