You may not realize it, but there’s an earth-shattering debate raging all across the web right now that is shaking the very foundations of our digital civilization:
“Should developers build progressive web apps (PWA), or should they opt for a Native mobile app experience?”
Okay well, maybe it’s not that serious, but it is an important consideration for building your next mobile app.
With the ubiquity of mobile devices, and the rise of the mobile web, developers are beginning to question whether native experiences (I.E. downloadable apps from an app store) are going the way of the dodo bird. After all, if you could build a PWA and get a truly cross-platform, no-download experience with all the benefits of a web app and a native app nearly for free…why wouldn’t you?
As an app developer, you’re probably asking yourself that very question; or, rather, you’re asking Google that very question (that’s how you got here, isn’t it?). Rest assured dear reader, we’ve thought on this long and hard, and our wealth of experience building both native and progressive apps has given us valuable insight into this fractious debate.
Before we can share our wisdom, though, let’s get a few things straight. Namely, just what is a PWA exactly?
PWAs for Dummies
We’ve all downloaded apps from the App Store or Google Play. You probably have Facebook, or YouTube, or Gmail on your phone’s home screen right now, so the concept of a “native” app should be pretty familiar. On the other hand, Progressive Web Apps are fairly new on the scene – only seeing more widespread adoption in recent years – and at first glance they are can be indistinguishable from a regular web app, so without knowing what to look for you may have used one without even knowing it.
Despite this surge in popularity, however, for one reason or another PWA’s have yet to take over the mobile market completely. Not least among these reasons is that they’re still not treated as first-class citizens on iOS devices.
But we’ll get to that. For now let’s focus on getting a solid definition for these “new-fangled” PWA things.
PWAs have many different definitions depending on who you ask, but the technical (and arguably the original) definition, as outlined by Frances Berriman and Alex Russel all the way back in 2015, specifies three things which are required of an app in order to qualify as a PWA:
- The app must run under HTTPS
- The app must serve a Web App Manifest
- The app must use Service Workers
But as far as definitions go, that honestly isn’t very helpful. (Too much Jargon!)
Luckily thanks to our experience with building PWAs, I think we can offer a much more intuitive explanation for what exactly makes a PWA.
Put more plainly, PWAs are web apps that seek to appear and act exactly like their native counterparts: They fullscreen to make the experience immersive, can be installed and accessed from the home screen just like a native app, they can save state from session to session, and even have access to the hardware capabilities of your device, so they can do things like track your location, access your health data, or use your device’s camera.
PWAs promise many things: an experience that is indistinguishable from native apps, an untethered existence free from app stores or lengthy downloads and updates, a unified in-app experience accessible across all devices (even desktop!), and a simplified development process that can take between 50 and 75 percent less time than a traditional native mobile development process.
That said, reaping all these benefits turns out to be harder than it seems. Even with their supposed advantages over native apps, PWAs still suffer from performance problems (being especially hard on a device’s battery), a lack of features, and hardware integration problems–which I’ll continue to explore below.
Despite these potential shortcomings, PWAs are still powerful new contenders on the scene with a lot to offer, so whether they are right for you and your company depends entirely on your app and your business. To find out if they’re right for your use case, let’s drill down and try to make a case for whether you should choose to build a PWA.
The Good, The (Maybe) Bad, and The Ugly of PWAs in 2019
Let’s explore three of the aspects of PWAs that may affect your decision to build one: the good, the (maybe) bad, and the truly ugly.
First we’ll explore the unadulterated good: the ease of development that PWAs can offer compared to native development.
Then, we’ll look at the bad (or still good, depending on who you are) that can come with the purely web-based promise of PWAs.
And finally we’ll explore the tragic situation that results from PWAs being second-class citizens on iOS devices.
The Good: Ease of Development
This reliance on the well-trodden ground of js callbacks and DOM elements means that development is significantly easier compared to building a native app. You won’t have to worry about making sure your team can handle building an iOS and an Android app in parallel, since you only need to build a single web app.
Having a singular codebase that is entirely web-based also means that a lot of the smaller annoyances that go with mobile development are taken off the roster. Gone are the days of tracking and squishing bugs for both versions of your app. Say goodbye to having multiple release schedules for all the app stores. Differing app-store guidelines limiting what one or the other version of your app can do? Seeking app store approval for changes? I don’t think so. And as an added benefit you definitely won’t have to worry about the app stores taking a cut of your app’s purchase price.
The “write once, deploy everywhere” workflow behind PWAs is at the core of all of these development benefits, and it is probably one of – if not the single greatest – benefit of PWAs. These benefits exists because PWAs are web experiences first and foremost, but while that web based experience can end up being the best thing that ever happened to your developers, and maybe even your users, it may also be the very thing that prevents your new app from being discovered.
The (Maybe) Bad: A Web-Based Experience
Since they’re just web apps at the end of the day, PWAs can leverage all of the benefits of a web app, including those mentioned above, while still getting access to native features through mobile devices’ browser capabilities (via Service Workers).
Service workers may make them feel like native apps, but PWAs are still effectively websites under the hood, and that means they are:
- Shareable — This may be more or less useful depending on your app, but in theory a user should be able to take the URL of the page they are on and share it with a friend, or access that same URL on another device and get the same page.
- Installation Optional — Users can simply use your app like a website if they choose not to install it on their device. In other words, no more awkwardly asking users to install your app. They can if they want, but they can still use your app. Again, many people are already using PWAs without knowing it.
- SEO Relevant — Being a webpage at heart means that search engines can crawl your PWA (the publicly facing parts, at least) and suddenly your app becomes searchable.
For companies that are transitioning their existing web apps into PWAs, these could potentially be huge boons. With the right attention to detail you could keep all of your “SEO juice” (so to speak) and continue to reap the spoils of a well-indexed and eminently shareable website while still going all in on the mobile space.
But, for companies starting from scratch or transitioning away from a native app, building up your web presence from scratch might be less enticing, and indeed disastrous. Any good SEO consultant will tell you that it takes time, effort, and indeed sometimes money and advertising to maintain a competitive search presence nowadays. Without a central one-stop-shop like native apps have in the Google Play Store, and the Apple App Store, PWAs live and die by their ability to be found by people searching on the web.
It turns out that app stores offer a lot of discoverability right out of the box: everyone knows where to go to find the apps they want. There are efforts out there to provide a similar experience for PWAs like Appscope, but their popularity obviously pales in comparison to Apple and Google’s marketplaces. If you’re a smaller shop with less of a chance of reaching the top of search results, you might not see the adoption you need without costly marketing or SEO consulting.
However, even if you are blessed with good SEO and top-ranking search results, don’t celebrate just yet. Chances are that around half of your users are on iPhones or iPads, and I hate to break it to you but…
The Ugly: iOS, Safari, and PWAs
That’s right, we’re finally going to address the fact that iOS doesn’t fully support PWAs (as of iOS version 12). It is probably the single most limiting thing about PWAs right now, so let’s get into it.
In short: Apple values the integrity of its walled-garden, so many of the capabilities that Chrome exposes for PWAs on Android are simply missing when it comes to Safari on iOS.
For an example: on iOS backgrounding a PWA at any point will reset it entirely, meaning you’ll have to figure out a way to save the user’s state and restore it yourself if you want to do things that require leaving the app, like two-factor authentication, or sending an email.
That’s far from the only problem, in fact the list of missing iOS features for PWAs is quite long. The following is a non-exhaustive list of either things native iOS apps or Android PWAs can that iOS PWAs can not:
- Store more than 50mb of files for offline content
- Display install banners to invite installation to the homescreen
- Access each app separately in settings, they’re all under “Safari”
- Access the native sharing context menu
- Use native social capabilities
- Open the locally installed PWA context when opening a link
- Background code execution
- No in-app payments
- Use Bluetooth
- Access the Altimeter
- Access Battery Information
- Lock the screen orientation
- No push notifications
Any one of these individually could be a dealbreaker for PWAs depending on the app. But that last one, a lack of push notifications, is especially egregious, and our team Topflight has had first hand experience with it. As of right now a PWA we built for one of our clients – an AI who helps people meet their mental health goals – is unable to send notifications to its iOS users.
For our clients, and indeed for any app that seeks to make timely recommendations to its users, this is a particularly thorny restriction to have to deal with. With iOS’ share of the mobile market hovering around 50%, it’s hard to imagine abandoning a huge swath of your audience by building a PWA that needs any of these features to work on Android and not iOS.
Having Cake and Eating it Too: The Case for Native Apps
With somewhere around half the mobile market not being able to make full use of PWAs, it seems that the only way forward is to build a native app.
But drinking the PWA kool-aid means believing that native development is devoid of efficiency, and committing to native development is a development death sentence, right? Must we continue to deal with multiple codebases, disparate deployments, teams needing to have iOS and Android knowledge to develop effectively, and being tied to the whims of the app store admins? Must we truly resign our fate and sacrifice our programmers and their productivity at the altar of hardware API access?
Well, not necessarily.
Cross Platform Native Codebases Are Still Possible
Now, compared to the prospect of developing a web app and allowing any mobile device with a modern browser to install and use your app seamlessly, you’ll still be writing a comparatively large amount of platform specific code with React Native.
The good news is: React Native takes this necessity and places it front and center in the development process. Providing ways of structuring your code that make platform specific code easy to understand and a breeze to write. React Native also allows you to include your own native C++, Java, or Swift libraries where appropriate with a simple import statement, and so things like background jobs, complex multi-threaded image processing, or database access code are not outside your reach just because you chose a high-level framework.
With React Native, in exchange for having to deploy our app to the app stores, and having to do a little bit of extra work to get cross-platform deployments ready, you can buy yourself the best parts of the PWA development process and the native capabilities you need. In essence, React Native allows you to mitigate many of the problems with native development that PWAs attempt to solve while still requiring half the effort of traditional native development.
So Which is Better? Which Should I Choose?
PWAs have a number of clear benefits: they don’t require downloading, they’re easy to develop, and they use web technologies that are ubiquitous and which enable any phone with a browser to use your app. They also come with caveats that mean complicated use cases still might not be possible to pull off uniformly across all devices.
Native Apps enable better raw performance, API access, and features like code injection and background jobs, but can require more in-depth development and larger (or duplicate) code bases to get cross-platform adoption up and running.
PWAs may be the obvious go-to for companies who don’t require mobile-specific capabilities, and have an existing web presence that will allow for visibility in search rankings.
Meanwhile Native apps are a solid choice for a business with a mobile app that needs the features of modern mobile devices.
Thanks to React Native and an aggressive development schedule, we built Helpkin a fully functional MVP for both app stores in 5 short months. As a social network for trading babysitting, playdates, and other services between friends, Helpkin’s use case requires complex UI views, calendar integrations, navigation capabilities, and app analytics for user tracking. We were able to seamlessly deploy Helpkin to the Play Store and the Apple App Store from Day 1, and now both version of the app are rated 5 stars!
Helpkin’s case and aggressive timeline really pushed us to our limits, but even deeper than that, it drove home for us that cross platform native development needn’t be as difficult as it used to be. Check out the case study for yourself and see what’s possible with React Native for yourself.
PWAs might be the future, but they have a long way to mature before they’re ready to completely conquer the mobile app world. Until then there’s still a need for the tried and true native app. Ultimately, however, the choice of which style of app to write is up to you and your business’ needs.
Regardless, our team is here to help you with either case, so whether you need help with a progressive or a native app, or even if you still need help deciding between the two, don’t hesitate to reach out.