Mobile Dev Strategy: PWAs

 

When evaluated properly, a solid Progressive Web App (PWA) development strategy can have a huge cost and time savings affect for your organization.  This post is a dive into the necessary PWA principals which will best server today's business decision makers. 

Here, a realistic understanding of PWAs well beyond the often WAY over simplified - "PWAs allow you to access HW..." will be explored.

Let's begin with a question that often comes up when first discussing PWAs: "What's the difference between a PWA and responsive/mobile web page?"

An initial straight forward answer is that your PWA is a responsive web page, but not necessarily the other way around, and your PWA can access the device's HW.  However, there are critical PWA nuances many business leaders do not fully understand or miss with this very trivial explanation. 

Again, general understanding misconstrued as deep knowledge will likely lead to serious and costly mistakes when determining how a PWA can best fit into your organization's mobile strategy, and this (PWAs) is one area where it can cost you more dearly than others of mobile development.

PWA vs Responsive Web:

As mentioned - a PWA is likely a responsive web page but not the other way around.

NOTE:  Just to acknowledge this - yes, if I wrote some poorly designed HTML/CSS/JS which was not at all responsive, but still developed PWA capabilities along with my service worker and app manifest (more on these in a bit) - it is possible to have a PWA which isn't responsive.  This is simple acknowledgement, but not a scenario we'll be discussing further.

What we have so far is a PWA is a responsive web page which has a couple of extra files - the service worker and manifest.  All these files are, are files your developers use to state what HW and services the PWA will try to access (ie: GPS, Camera, Bluetooth, contacts, etc...) - as well as some behavior and UI specifics.  ie: the icon to install onto the user's home-screen when the user "installs" the PWA on their mobile device. 

Above, all good stuff, but pretty general web page reading.

Now let's look into the PWA surrounding capabilities, access levels, structure, and tactics which decision makers often don't fully understand and dive into the real PWA knowledge points which will have real world impact on your mobile and business strategies. 

PWA Capabilities Layer:

You'll hear it all the time, in fact, I've even stated it in this post - "PWAs can access HW and services on the device."  This is absolutely almost true!!!  And here's where PWA complexities will start to play a significant role in your mobile strategy decisions and where you will need to ensure you and your organization's decision-makers fully understand the finer points regarding a PWA's capabilities and perhaps more importantly, how they're achieved.  

The reality is - PWAs give you the ability to make request to the browser, which can then make a request to the O/S services for the information from the device's HW or other services.  So, does your PWA really have access to the device's HW and/or services - no.  Does this really matter?  Yes!  So yes!

Important points so far:

• Your PWA will have no additional access outside the device's browser capabilities, permission, or access levels.

• Your PWA only has direct access to the browser - not the device

• Your PWA will make requests to the browser for information and:
1. The browser chooses how or if to process the request from your PWA
2. The device's O/S then chooses how or if to process the request from the browser.  Note that the O/S will have no idea about your PWA - it cares about the mobile app. The mobile app is the browser - not your PWA

• The PWA will be running inside the permission boundaries and sandbox of the browser the user is using...
• Critical that you keep in mind that may not be the browser that natively comes installed on the mobile O/S - or even a browser you didn't fully test with.

Below is a general overview.  In the image the user has "installed" the PWA, ie: The "app" icon on the right side: (One note here - when a user starts a PWA after it's installed onto their mobile device, they don't see the browser really, but regardless, the PWA is in-fact running in the device's browser - just an FYI.)

Now that we have a more solid understanding of the PWA's inner-workings, let's take what we just learned and pertain it to solid mobile strategy decision making to determine how much of the organization's mobile presence is going to rest on a PWA.  Maybe all of it - maybe almost none of it...  

Leveraging PWA Capabilities:

When discussions come up about fully leveraging PWA capabilities, business leaders and non-engineer decision makers often find themselves frustrated with seemingly vague answers to what appear as straight-forward questions.  For example: when a business leader asks - "Can our PWA access the device's camera" and the answer comes back from the engineering team - "Probably" or "we should be able to."  Of course, inevitably, there's always one - "Absolutely/Of course!"

It is this very scenario which makes the decisions regarding how to properly incorporate a PWA into your organization's mobile strategy often difficult for business leaders.  

While it can seem frustrating, there are reason's your engineers are answering this way.  Here's how it breaks down technically:

• If the browser the mobile user is running your PWA inside of allows the call to take a picture...  Well then - Check-mark!

• If the O/S the user is running your PWA on allows that browser to access the camera to take a picture...  Well then - Check-mark!

• Does the user have an MDM/EMM/UEM active which does not restrict camera access?  If no...  Well then - Check-mark!

• Does the PWA make calls within the boundaries regarding what is allowed by both the browser and mobile O/S?  If yes...  Well then - Check-mark!
• ie: You can take a picture once every second on some mobile O/Ss, maybe once every 10 on others, but if you need to take 10,000 pictures a minute - a PWA isn't going to help you.

Thus, there are factors that play a role in your PWA's capabilities in the real world and "absolutely, we can access the camera!" - absolutely does not cut it when you're looking at serious investments dollars for your organization's mobile strategy and overall presence.

NOTE:  Regarding the first two points above, you're probably fine using the camera reasonably as most mobile O/S's and browsers have access and few MDM/EMM/UEM configurations are configured to restrict camera access (some do though).  But for simplicity's and clarity's sake,  I was just using the camera as a trivial example.

PWA Weaknesses (There aren't many - but there are some):

Let's start off this section with a discussion which revolves around the popular PWA concept of off-line storage.  This feature is a huge benefit and is truly awesome!  The issue isn't storing offline data using web technologies, it's understanding how much and for how long your PWA's data is stored and how it's "shared." 

What you'll need to understand as a decision maker is, there isn't a number regarding "how much" (ie: how many bytes) a PWA can stored nor for exactly how long. 

The browser will have some rules it follows for PWAs, such as evicting unused data.  This means that if the user hasn't interacted with your PWA for N (time), all your PWA's data, and your PWA itself are evicted from the device.  Evicted, since nothing was really installed - ie: nothing to "uninstall."

Some browsers state eviction after 30 days, others 90 days, and others have other rules...

Some mobile O/S's say PWAs are capped at X MB/GB - other mobile O/S's say X% of available disk space.  Again, "available" space.  Some users have a lot less than others...

Thus, when you as a decision maker states "we need offline storage."  You need to understand there are varying limits on amounts and durations...   How does that play into your organization's mobile strategy feeding into your organization's overall business strategy?

A final note about PWA storage to consider - remember your PWA is sharing the same sandbox memory segment along with all the other PWAs and the browser itself.  Therefore, if the browser your customer is using to run your PWA has a security issue - you likely do as well.  Essential rule of thumb - don't store hyper sensitive data on a mobile device, and certainly not in a PWA.  Keep in mind, this isn't logIn credentials - PWA's and browser excel at securing this type of info - this is about your organization's offline stored data.

Below is an image to help clarify:

The final point to consider when evaluating PWAs as a component of your organization's mobile strategy is frequency of device access to services and HW data and severity of background operations.  Please keep in mind that we're talking about more than the relatively simplistic use case of receiving notifications while the browser is inactive.  Instead what we're talking about is high pressure usage of the mobile device's HW and services at high rates while the browser is either shutdown or in the background.  There are some high performance BTLE or Location Based Services (LBS) access issues you'll fall short on with PWAs vs a native mobile app.

Again, this may be something which has no bearing on your organization's desired capabilities, but if real-time HW interactions plays a role in your mobile strategy - the PWA may need to play a different role, such as a support role to a hyper performant native app.

Regardless, it is highly likely that the inclusion of a PWA will only serve to strengthen your organization's overall mobile strategy no matter if its the primary or secondary component.

PWA Conclusion:

As we ended pointing out the finer details regarding the PWA's weaknesses, the fact of the matter is that an incredibly high percentage of organizations today could have their entire mobile solution more than satisfied by a PWA rather than a mobile app.  Now, regardless if the PWA's capabilities fully satisfy your organization's needs - PWAs should at least be considered as an extremely capable and great addition to any organization's mobile strategy today!