WebView or External App Picker? Or, When To Give Users Freedom
I recently had to fulfil a requirement to display downloaded PDFs in a Xamarin.Forms app implemented across the three platforms : IOS, Android and Windows.
My first instinct, like most people, was to implement the functionality via an embedded WebView to keep the experience seamless. Unfortunately things didn’t go so smooth. For one, it doesn’t work on any Android version before Lollipop. Secondly, it’s not supported at all on Windows phones at present. That’s right, that’s two out of three dead in the water.
I soon then realized that the only way to implement a cross-platform PDF viewer solution was to tap into native behavior and let the user choose their own pdf viewer. Once I knew that was the case, I reconsidered my previous approach and actually after some thought I concluded that this is actually a much better decision. In fact, unless I had very specific requirements that explicitly told me not to, I would still choose this approach even if the ability to render PDFs in Web Views across all platforms was up to scratch. Let me elaborate.
The behavior of Web Views across the different platforms is extremely inconsistent. This is true in many levels including rendering, performance and capabilities. On top of that, because Web Views are native components that can be updated at any time, even work-arounds cannot be completely relied on if you are trying to create a consistent experience. For instance, you can force web views in Android versions prior to Lollipop to render PDFs by including the PDF.js library from Mozilla; however, you cannot guarantee that library will compatible with future updates of the web view component.
By allowing the user to choose an external viewer, not only you are allowing them the freedom of choice, but are also removing dependency on a tool, in this case the web view, which could be be updated and change at any time and would directly impact the stability and consequently the users’ opinion of your app.
This philosophy is very much in line with the proactive measures that first parties such as Apple, Google and Microsoft take to ensure as much as possible that apps are not able to completely incapacitate a device if they are buggy or leak memory or inadvertently delete files from the file system or bear any other kind of fatal flaw that would have a high impact on the device’s health. That is because they know that if your app wreaks havoc, consumers are not going to blame you, they are going to blame the main brand behind the device. Most often they will say “iPhones suck” or “Apple sucks” if the phone, let’s say, was allowed to run out of memory due to a background process that some rogue app triggered and never terminated.
So, going back to our example, following that same line of thought, if the user chooses a PDF viewer app they are now conscious that they are about to use a completely different piece of software and should that ever stop working, then they will be saying “Adobe sucks” or “Polaris Office sucks” or whatever other app they may choose to use, instead of blaming your brand. Another benefit is that by allowing them to open the PDF in another app, you are potentially opening up a array of other features for the user that the other app may have besides just opening the PDF allowing it to become part of what I call a Symbiotic Productivity Chain (SPC).
An SPC is when your software becomes just another piece in a chain of interaction with various other productivity programs aimed at producing one goal. Much like a line-of-business app which is relied upon to produce output for the next LOB app in a business process chain. For instance, a user may use Notes to create a quick note on their phone, upload it to Dropbox, open the file on their desktop in Word, format i, save it as a pdf, then use Gmail to finally achieve what was their goal all along which was to share a formatted pdf of their notes with someone. Now this is a very long winded process and many segments in this chain could be replaced by introducing different software or getting the user to change the way they do things. But users create SPCs all the time, particularly when using their mobiles since the nature of apps is to provide bite-sized pieces of functionality and focus on doing only a few things really well. There is also the factor of cost; users are not shy to go to extra lengths of effort in order to save money, specially younger crowds.
Now, you may be thinking that the same could be said for any native control. The OS could update the behavior of labels at any time, or even worse, buttons. While that could be true, it is far less likely and this has to do with the fact that web views are a complex beast in their own league. They are, in essence, embedded web browsers and as such they have to cope with all the same burdens such as interpreting and executing code and rendering HTML and CSS. A far cry from the predictable structure of labels and buttons which will most likely always contain just properties for setting text and its color and background color, etc in addition to a limited set of available interactions.
In a nutshell, always think about where your app will sit in a productivity chain. Carefully consider how much is it really worth from a commercial and strategic point of view to add extra effort to try to handle everything within the boundaries of your app and entertain the possibility of perhaps allowing certain features to be handled by external apps. This may not only save you time, but also make your app more useful by having its output serve as input to another and be used in unexpected ways by the users which ultimately bringing your app more visibility and, hopefully, money.