Clearly PhoneGap, and Cordova are still required today in the mobile world, but when is it really needed? Did the web ever catch up? Do we always need to turn to a PhoneGap shell for all our solutions?
I remember first hearing about PhoneGap through excitement over Twitter in 2009. The first jsconf.us had just run, but I hadn't attended (at the time, the distance and costs were too much). One thing was for certain: PhoneGap, team Nitobe with front man, Brian LeRoux, had cracked something hugely important: deploying webapps inside of a native shell with native access.
In the same year I coined the term polyfill:
A polyfill …, is a piece of code or plugin that provides the technology that you, the developer, expect the browser to provide natively. Flattening the API landscape if you will.
Back in 2010, mobile browsers didn't expose many of the APIs nor mobile sensors to the browser, such as orientation data. In conversations and conference talks, Brian LeRoux would talk about closing the gap between mobile and desktop. Something to raise the level of API access within mobile devices. Eventually publishing exactly what he meant on the web:
That bears repeating: [the] purpose of PhoneGap is to cease to exist.
Now, obviously this is not in Adobe's interest, given their purchase back in 2011. However, it is PhoneGap’s philosophy: to create software that helps developers to get to where they need to get to whilst we wait for the technology to catch up.
Once that technology bridge exists natively (i.e. via the browser), the "gap" bridge can and should be removed without any (real) impact. This is exactly the way a polyfill works.
This post (and talk) is about the current state of that gap some 7 years later, and whether application developers still need to turn to PhoneGap or whether in fact the web is fully capable of delivering a first class experience whilst also solving your user's needs. Did team PhoneGap succeed? Did the web catch up? Did user's needs surpass what's possible?
Though, spoilers: progressive web apps.
Many More APIs
There are many many more interesting and exciting APIs in browsers today, including
navigator.sendBeacon() (for analytics after your tab is closed), Streams, Bluetooth, and Physical Web.
I'll admit, I've shoehorned this in, but I recently saw a physical web demo that combines beautifully with bluetooth discover and control.
This individual is interacting with a bluetooth device without having to jump into any settings. The beacon discovery is landing directly in Chrome (he’s using a separate app), and bluetooth is currently behind flags, but it shows how frictionless the process was to start using this new toy:
When looking at a PhoneGap plugin (for example), there's a strong focus around support across platforms, because the hard part is coding in multiple languages. PhoneGap has core support for three platforms (Android, iOS, Windows Phone) and a number of other platforms supported by the community through Cordova. Though, as I was checking out the featured PhoneGap apps all of the ones I saw only supported Android and iOS…
The web is different, in that if the browser fully supports a class of APIs, then the support across devices is the same (mostly, hardware oddities aside!). A key feature of browsers is to support interoperability. It's a relatively simple equation–site looks amazing in browser X, browser Y should want to provide the same experience to pull the users across.
The web is the long game. It will always make progress. Free access to both consumers and producers is a core principle. Security is also a core principle, and sometimes at the costs of ease to the developer (but if it were easy it wouldn't be fun, right?).
Over the years since 2009, the web's native support for APIs that PhoneGap provided has improved dramatically. The ecosystem is very different from the day that PhoneGap was needed.
In my game of Q&A bingo, "what about Apple?" is always a sure bet. On one hand, I hate that Apple doesn't pull up to the table and discuss their intentions and how they will support developers.
Even getting the hint of interest from Apple is a process of dumper-diving the mailing lists scanning for the smallest hint of interest.
Apple also won't allow any other browsers into their platform as such, and this really annoys me, so Chrome is just a wrapped view on WebKitView (the Safari render engine). So all the new technology that lands in Chrome or Firefox does not land in iOS. iPhone users have to wait for Apple and Safari to get involved.
Equally, Apple—just like Mozilla, Chrome, Opera, Microsoft—is a company. They can behave as they please. They do not necessarily have to answer to our call. This secrecy is how they operate (for better or worse).
The upshot, however, is that technology like Service Workers and push notifications are already implemented in Chrome, Opera, and Firefox, and there are positive signals coming from Microsoft (via active development and their dev status pages)—so that just leaves Safari. If web developers start making amazing web apps that use these technologies, Apple will want to serve the developer demand.
Could Instagram Work As a Web App?
I posed the question recently via twitter, purely as a thought exercise. Instagram today is a hybrid app. I asked: why is Instagram a native app? More specifically, what's missing on the web to do it?
The answers were interesting, particularly as I felt that a great deal of functionality is possible today. However, the limitations (i.e. not possible at all with web tech) we found included:
- The ability to focus the camera (when used as an inline object)
- Access to list camera roll images (inline)
- Inbound share intent (i.e. sharing to our web app, aka "web intents" of yesteryear)
- Client side transcoding and compression (of video in particular)
With respect to transcoding: Sole Penadés wrote up an excellent follow up article explaining the biggest issues and the research that they undertook in Mozilla a few years ago.
The items possible via web technology today (but, as caveats go: not across all platforms):
- Filters via WebGL (and using CSS for fast previews)
- Inline video and audio playback (long available in Chrome and hackable for iOS)
- Fast loading shell: Service Workers and Intersection Observer API
- Push notifications
Discoverability (of the app) was also a question that came up a few times. In particular, citing that "users are used to app stores." I don't quite agree because app stores are a relatively new paradigm and it can be changed—it's not set in stone.
Why Wouldn't You Use the Web?
It depends on your criteria and context. I recently read an article comparing hybrid apps (such as PhoneGap based apps) to web, and one of the pros of a hybrid was the API access available.
The truth is that a lot of that has changed with respect to Web APIs, and, in fact, a lot of the core APIs available in hybrid app development come directly from the browser APIs, for applications such as social media, gaming, and the like.
What a hybrid app frame does offer that web cannot (today), is a plugin system that allows the developer to bridge to native functionality that isn't available in a browser—like sending an SMS.
The bottom line is that being able to write custom plugins for tools like PhoneGap will always put the technology ahead of the web. Flash was the plugin that was ahead of the web for a long time, it was the only way to play video for heavens sake!
If a new sensor is shipped with a device tomorrow and plugin giving developers API access can be available the next day. The same cannot be said for browsers. It takes many months, if not years to get to the same API access.
Why Have Web Apps Been "Avoided"
I've heard "app stores" being cited as a reason to use build hybrid or native. One story goes: the CEO wants their company present in an app store. They want adverts, telling listeners to go to their homepage, then download their app from the Apple or Google store.
It's well known that Apple takes a reasonably significant cut of sale profits (I'm not familiar enough with the other stores to know the status).
However, when you put it up against numbers, it really doesn’t look that attractive.
Research has shown that the UX of requiring an action creates a 20% fall off rate, which has a direct effect when you want to send your users away to an app store. Alex Russell uses this in number of his recent presentations, and I'll use the same numbers.
Say you have 1,000 interested users. Here are the steps:
Even if they're directed straight to your app, you're skipping step 1 & 2, you’re still only left with 410 users. That’s less than 50% of users for your app store.
Selio (a buy/sell/chat commerce app) moved to PWA for their site and saw an average of 6+ minutes spent in the app. More importantly, the user acquisition was up to 10 times cheaper than native apps. Putting a (CPA) cost of €3-5 for native apps, and €0.30-0.40 for PWA users.
That's a huge cost.
What if there was an alternative path…?
Progressive Web Apps
#LOLMarketSpeek. Well, yup, sort of. But every big change needs a hook. A word. Like ajax. Or comet. Or polyfills. This is, in part, a marketing ploy by the web (and some clever hats at Google) aimed squarely at those people who keep building "native apps" that replicate web functionality.
And it's working.
Flipkart is a commerce site in India that recently shut down their mobile app in favor of a progressive web application. Google has a case study that includes some really interesting data and insights:
Obviously, it's not working because of good marketing, it's working because web technology is getting really solid backed by solid APIs.
What Makes a Progressive Web App?
Alex Russell coined the term and posted on his blog last year: Escaping the Tab: Progressive, Not Hybrid. He notes that "an evolution has taken place in browsers.".
Frances Berriman and Alex enumerated the factors that make for a progressive web app, which I've taken the liberty to (attempt to) distil into three main topics:
- Security: TLS/HTTPS, permissions
- Performance: fast, responsive (in all senses)
- Availability: control of the network, homescreen, push notifications
Importantly, the users will not be actively differentiating between progressive web apps and "native" apps. That means they must behave with the same level of performance.
It's our jobs, as web developers, to change the mindset of our users. We want and them to say to themselves, If I add this app to my home screen, it will work when I open it.
A Note About Add to Home Screen
At the risk of repeating myself (over and over and over…):
Without HTTPS and without service workers, you can't add to home screen. This is an intentionally high bar of entry with damn good reasons.
When the user installs a PWA, it has to work. It's our job as web developers to provide the most excellent experience for our users.
It has to work.
Once an app is on the home screen, it has space in the highest valued real estate on the user's device. It's fast to access so it's our jobs to instill trust into our users over and over.
With time, and persistence, users (us, included) will come to expect PWAs to work. If it's on my home screen, it'll work. The same way as any good native app might work today.
There's a huge (business) demand for push notifications. The opportunities to re-engage with a customer are almost overwhelming!
Push technology also requires a service worker, because the service worker will do the subscription, and receives the
push message event.
In this push notification demo, what's important to notice here is that I didn't install the app to my phone. The tab and browser were completed closed. I simply accepted push notifications from the website, and the notification still arrives. It's a little hard to see from the small animated gif (sorry about that), but after I close the browser, a notification from Chrome comes in at the very top left of the screen.
Over a conversation I was having with some developers, I explained how I was using the native Android Amazon app recently and tried to compare a product (that I wanted to buy).
I quickly realized I couldn't switch back and forth the way I would normally with a tabbed browsing system. Someone else pointed out that they had uninstalled the native app, and exclusively use Amazon in the browser at the expense of not getting the delivery notifications.
Push notification technology can change this!
Beyond the Rack, in another Google case study, stated that:
Push notifications allowed us to bring one of the most compelling capabilities from our native app to our mobile site. We see a direct 20% click through rate from push notifications…
An Anecdote in the Wild
In preparing the content for this talk and post, I had been taking screenshots and videos on my phone that I needed to transfer to my laptop.
Ordinarily I would send myself a hangout message to my additional Google Plus account—which, now that I've written it down is bananas.
I knew I just wanted a simple peer to peer file transfer app. I'd need this in the past, so I started to spelunk the Google Play store.
The result was installing three separate apps all of which didn't quite do what I wanted. It either did way too much or didn't let me transfer the way I wanted (I even found an app that moved files from my laptop to my phone—the wrong way around!).
Then, through twitter, I was notified about snapdrop.net. Right away I realized this was exactly what I needed—a peer to peer file transfer application.
Not only was this a progressive web app, but I've also installed this app to my home screen and it did exactly what I needed. Perfect and simple. Irrespective of the fact it was entirely web technology. This app was a perfect example (for me) of a PWA in the wild.
Brian wrote this of the PhoneGap philosophy back in 2012 (emphasis mine). It’s still fitting today and, in my humble opinion, it will always be true.
We agree that there are no silver bullets, and the web isn’t the best tool for every job. However, the web is not getting worse, and the browser abstraction layer is ultimately the same across operating systems (C, C++). If the web doesn’t do something today it’s not because it can’t, or won’t, but rather it is because we haven’t gotten around to implementing that capability yet.
If there is demand for access to a native API or native access point (such as the home screen), first the hackers will take on the problem, then the masses will use the hacks and then, eventually, it’ll land in browsers. It’s a long bet, but the web will get there.
For now, though, there’s a lot of new and exciting prospects with the technology available right now. Do it right, make your users trust the web.