Year by year, people are consistently spending more time on mobile devices to access the internet.
In fact, people consume 2x the amount of content on mobile than they do on desktop.
Needless to say, website owners should be excited about this prospect in 2018 as the opportunity to reach these mobile users has widened.
There’s, of course, responsive web design, which allows them to connect with users via their website.
Then, there are native mobile apps, which users can download from an app store and add to the home screen of their mobile devices.
Now, we’re looking at the entry of Progressive Web Apps (PWAs) to the arena, which takes an approach midway between mobile websites and mobile apps.
So what is a Progressive Web App?
Progressive Web Apps take an approach that is midway between mobile websites and mobile apps.
And this leads us to today’s discussion as well as answers for entrepreneurs and business owners trying to decide what’s best for their company:
Do progressive web apps really compare to native apps?
Progressive Web Apps and Native Apps: What’s the Difference?
It seems like a simple enough question to answer: Is there a difference between progressive web apps (PWAs) and native apps? (Yes.) If so, what are those differences and how do you choose which one to create for your company’s mobile device presence? (That depends.)
Below, I’m going to break out the key differentiators between PWAs and native apps. While each platform indeed has its strengths and weaknesses, there are clear use cases for each:
The superficial difference between PWAs and native apps has to do with the way the end user accesses them.
Native apps are found and installed through an app store, such as Google Play or Apple’s iOS App Store. Here is an example of how the Flair app appears in the iOS store.
Once installed, the app will appear on the user’s home screen with a recognizable icon and text label that calls attention to its presence.
That said, this means that when you develop a native app you have to submit it for consideration to one (or more) of the device app stores you want it to appear on. It’s then up to the users to find the app, read the description and reviews, and determine if it’s worth downloading and saving to their mobile device’s screen.
PWAs, on the other hand, help you avoid dealing with administrative headaches in app stores. Instead, these web apps run right from within the mobile device’s browser. Twitter Lite is a good example of this:
As you can see in this example, mobile.twitter.com has a login screen much like what you’d find in a native app.
Users access a PWA by searching for it in the mobile browser. If users aren’t aware that the PWA even exists, it may be surprising to encounter a truncated version of the website when they expected an experience that mirrors the one from the regular website. However, once they do discover it, it’s easy enough to save the PWA to the home screen just as they would a native app.
The only obstacle your users may run into is knowing how to add it to the home screen:
Once they do, however, there’s very little difference between their native apps and PWAs; superficially, at least.
- Both the native app and the PWA require some digging on the part of the user to initially find. In terms of installation, however, the PWA is easier for users to get going with as access is granted the second they land on the web app. This also means less work for you as you don’t have to submit your native app to an app store and create a completely new description and profile for it.
2. Cross-Browser Compatibility
Because native apps are built specifically for iOS or Android devices, this can limit how many users have access to them. Granted, developers do have the option to develop native apps for both operating systems, but that typically requires a dual development track that costs small brands time and resources they don’t have. Which is why it often comes down to a choice.
There are benefits to this limitation however. Since developers design an app specifically for iOS or Android users, this ensures that the experience within the native app is tailor-made to their platform. Developers have to worry less about cross-browser or -platform compatibility and more on shaping their app for one specific mobile device.
Progressive web apps, on the other hand, take a different approach.
Utilized by many big brands like Twitter, Forbes, and Flipboard, they’ve evolved out of mobile technology that’s been in play for years. (However, the phrase itself “progressive web app” was only just coined by designer Frances Berriman and Google Chrome engineer Alex Russell in 2015.)
Because PWAs are built using mobile technology that’s already deployed widely, there’s no need for separate distribution. Developers create the responsive instance of the PWA, publish it, and then leave it to the user’s browser to display it correctly within the screen’s parameters. It’s just one app to develop and users across a wide range of mobile browsers can engage with the app.
The one point worthy of note here, however, is that the interface of the PWA typically attempts to strike a balance between what you’d find with a responsive website and what you’d encounter in a native app. Here is an example from Twitter Lite:
While the top navigation and feed are most definitely optimized for a mobile app interface, users may encounter some friction as native app features and ease of use are missing from the experience. Some of the elements from the regular website are missing as well, which may lead to confusion or frustration for users who don’t understand the purpose of the PWA.
- Each platform has its strengths when it comes to cross-browser compatibility. And although native apps are typically only designed for one device over the other (usually due to the cost restraint), developers have the opportunity to create a more user-friendly experience as the app is designed specifically for the structure of a mobile app.
One of the great things mobile apps do for the end user is giving them the ability to access the information they want without having to be connected to the Internet. So, if your users find themselves in a location without connectivity, but still want to read up on news, log into their account, send someone a message, and so on, they can still do so by using their mobile device’s data.
For progressive web apps, connectivity is not required either. A PWA essentially turns your website into a web-based app that gets installed on your system and, where possible, works offline utilizing cached data. In this sense, it purports to bring the native app experience to mobile web browser apps.
There is a tradeoff with this option, as you might imagine. A PWA can serve certain parts of the app to users when their device is unable to connect to a network. However, a PWA cannot serve all parts of the app to them; specifically, anything that isn’t part of the page’s natural caching system will be offline until connectivity is restored. So, if a user wanted to submit a contact form to Forbes or make a reservation on Trivago, they’d be unable to do so without a native app.
- Native apps definitely win in this category. While it’s great that the technology of PWAs is catching up and allowing users to access cached content, they’re just not quite at the point of being able to tap into a mobile device to stay connected no matter what.
4. Storage, Data, and Power
When a native app is installed to the desktop of a mobile device, it’s going to pull directly from the device’s resources.
For more resource-heavy apps, ones that users interact with frequently, or those they forget to close out of altogether, this can be problematic for the end users who watch their:
That’s, of course, not to say that PWAs don’t cause similar drainage issues. As you can see from the screenshots above, the Safari app causes nearly as much of a burden as the most commonly used apps on this phone. Really, what it boils down to is:
- How well-coded the app is
- How many resources the app calls on
- The user’s actual usage of it
- If you’re trying to reach an audience that lives in a region where data networks tend to be more expensive and users unable to pay for it, then a PWA is going to be the best option. That said, some native apps can work and store content for offline use, too. The quality of build will ultimately determine how much “damage” an app does to a user’s resources, so keep that in mind, in general, with any kind of app you build and you should be fine regardless of which route you take.
There are two sides to view updates from when it comes to apps: the user’s point of view and the developer’s.
For the most part, there’s really nothing for users to do when it comes to updating native or progressive web apps. There may come a time when a native app requires a manual update, but, for the most part, the process is automated and users will barely detect when an update has gone through.
On the other side of this, however, is the point of view of the web developer. For PWAs, there’s no need to download core or update files from an app store when you want to issue an update. With native apps, though, there’s a bit more work involved.
- For your end users, this one isn’t going to make much of a difference as most updates will go unnoticed. However, when it comes to the developer’s side of the equation, updating a native app is definitely more labor-intensive (and can oftentimes be frustrating) than updating a PWA.
For native apps, there are two chances for them to show up in search results.
- Within the App Stores
- In search engines
However, both of these depend on a number of superficial factors since the pages of the app itself cannot be indexed and listed in search. Instead, you have to do what’s known as app store optimization (ASO). This involves app search optimization tactics like:
- Identify a commonly searched-for keyword (in the app store) that aptly applies to your mobile app.
- Use a strong title/headline that includes your selected keyword.
- Develop snappy and yet thoughtful descriptions of your app. You want to quickly appeal to app store users, but also make sure they understand what they get from the app experience. Make sure the keyword is included here, too.
- Customer ratings play a huge part in a native app’s overall success, which means they’re going to factor in with SEO as well. Don’t be afraid to reach out and ask current users to leave you a review.
- You will also want to see that downloads number go up as well. Pitted against competitive apps that don’t have as many downloads or aren’t as well-reviewed, this form of social proof will help you attract new users.
The app store will also be a big help in driving traffic to your new app if you utilize the categorization feature well. The more niche and specifically labelled your app is, the more relevant app store search results it will appear in.
While that will help your mobile app perform well in app stores, do keep in mind that the way search results display native apps isn’t always ideal. Take, for example, this search for “dating apps”:
Yes, there is a highlight bar at the top that shows off logos from the most popular dating mobile apps. However, clicking on those logos doesn’t actually take the user to the app. Instead, it opens up a knowledge panel on the right side of the screen.
In order to find the links to those apps in the mobile store, users have to scroll down and try to dig through the usual search results in order to find them.
Granted, they are there; however, there’s no way to mark these up with structured data in order to make the listings more attractive with ratings, links to pages, expanded information, and so on.
Now, a progressive web app, on the other hand, will do well in terms of SEO as it works like any other website you’d encounter online.
As you can see in this example, the Starbucks PWA looks just like any other search listing you’d see. They’ve even optimized it well enough so that it has a custom meta description (that makes sense for what the PWA allows users to do) and also gives links to relevant pages on the app.
- I would say that, if your brand’s online presence is brand new (in other words, you’re not taking a highly established web brand to app form), it would be a smarter choice to move to a PWA to start. With PWAs, you have the benefit of attracting users from search to your app, so long as you’ve taken the time to thoroughly optimize it. With a native app, it’ll be a bit more work to build up clout in the app store and to get attention from search.
7. Push Notifications
Push notifications are one of the key reasons why many site owners and businesses are focusing on their mobile presence.
They attract significantly more engagement than traditional methods such as email. Reports show that Push Notifications in certain industries can get up to 40% click through rates (CTRs), whereas emails typically generate around 20-25% open rates, with CTRs of around 3-6%.
To summarise, push notifications will result in more engagement with your content and mobile app!
Native apps provide the functionality for app owners to use push notifications. You can build the functionality needed for push notifications from the ground up, or easily integrate existing push notification solutions into a native app using a third party such as Google Firebase, PushBots, or OneSignal.
You can also use push notifications in Progressive Web Apps, thanks to Service Workers.
However, their functionality is more limited and certain key engagement features are limited to Android, leaving iOS PWAs to function more like the website
- PWAs are beginning to make progress when it comes to push notifications, however, Native Apps are the clear leaders in this category. Native apps can support push notifications on both iOS and Android devices making them the right choice for any website owner who wants to engage their audience using this powerful kind of notification.
Security and privacy are key in 2018, and companies need their mobile apps to be secure too.
Native apps have the capability to be a secure solution for both the app owner and users. It’s easier to use Multi-Factor Authentication in a native app, than in a PWA which is useful if an app has login functionality. Multi-factor authentication adds a large layer of security to native apps.
Native Apps can also use certificate pinning to prevent certain kinds of attacks, which in-browser apps such as PWAs can’t emulate. Despite this advantage for Native Apps, PWAs are still served over HTTPS which does allow for browser-to-server encryption. As long as the website owner has created a secure environment for the PWA, it can be just as secure as any website.
If people access a native app over an unsecured network, vulnerabilities can be introduced, which is a disadvantage. Some PWAs will warn a user when a web page is accessed over an unsecured network, which can help avoid security issues.
However, to get your native app published on the iOS and Android Google Play and iOS App Stores, they have to be authorized by either Apple or Google first. Apps that present clear security issues for users are highly unlikely to get accepted, so in the majority of cases an app downloaded from these sources will be trustworthy.
- Although there may be more work to build the security features for native apps, it has the potential to be more secure than PWAs, thanks to the ability to build in security features. However, security is always a delicate subject when building anything for the web. You can’t afford to be the cause for compromised data, so this one is going to lie on your shoulders, native app or PWA.
9. Device Features
One of the best things about building your application for placement on a user’s mobile device is its ability to sync with other device apps and telephone features. For example, native apps can use the:
- Geofencing (for marketing purposes)
- Contact list
- SMS and push notifications
- Near-field communication and mobile payments
The DeeperBlue native app asks users for permission to send push notifications to their mobile devices.
And, unlike browser windows that can only request that information once before being blocked entirely, apps like Deeper Blue can offer users the choice to opt-in at a later point by accessing their Settings.
Progressive web apps are relegated to the same kinds of restrictions as standard websites, which means access to mobile device features is off-limits. Granted, there are some connections that can be made through APIs (like social media logins) to improve the user experience, the limitations exist.
- For quicker and more personalized communications with your end users, there’s no better choice than the native app. And when your app would benefit from tapping into device features like the calendar, GPS, or contacts, there’s really no contest. API integrations may open up functionality to other software for users on a PWA, but it won’t give them the ability to sync their app to their phone the way a native app does.
Finally, we come to the matter of cost and the time to launch.
A native app — if truly native — is generally built with the Android and iOS SDK in Java, Swift, or Objective-C.
The downside of this approach is that it necessitates a long, sometimes drawn-out development process. Additionally, there’s a high cost of maintenance for native apps.
There are developer tools such as the React Native framework, which can help offset these drawbacks by making a large portion of the code reusable between iOS and Android.
At the same time, if your audience consists of users on both platforms, you’ll have to either ignore one subset of users entirely or shoulder the additional burden of dual development.
That burden isn’t just the additional time it takes for development. You’re looking at additional financial expenditures and staff time spent commenting and testing, at a minimum. You might also have to consider the cost of outsourcing development if your team isn’t capable of handling it on their own.
The progressive web app, at its core, is basically a web app built in any one of a number of ways (although React.js and other similar frameworks are certainly popular), with the addition of service workers. As such, developers need to replicate a lot of what the native and mobile SDKs already provide, so it still means investing in research and development, the same as you would with native app development.
Let’s not forget, however, that the cost of something like this isn’t just the amount of money paid to someone to build an app as well as the amount of time put into it. You are investing in a tool that aims at boosting business growth and audience engagement–whether that be from new readers, returning customers, or ad revenues. You’re building this for the purpose of bringing more money into your business, which will ultimately offset the upfront costs of the app.
- A native app could end up costing you more than a progressive web app and also take longer to build–depending on which route you take. Building a native app from scratch with the assistance of a developer or agency would indeed be costly. However, building a native app with a WordPress-specific app builder like MobiLoud would give you similar results, but at a fraction of the cost and time. And, ongoing maintenance and support would be included, making the return on your investment huge.
Regardless, if your users will lose out on an experience that’s critical to the native app (like push notifications or geofencing) because of the perceived high costs of building one, then you may need to reconsider your budget as the money spent on a PWA could end up being a waste.
Note: There are other factors to consider when deciding between native app and progressive web app–like performance, quality of design, etc. But much of what that boils down to is the quality of coding; not whether the app is native or exists in a web browser. So, when it comes time to make a decision, be sure that your choice of development path (as well as developer) can match up with each of those expectations.
In sum, we don’t think progressive web apps are all that bad. In fact, they can be a vast improvement from mobile websites, when done well.
As the technology improves, there have definitely arisen some good use cases for them. For instance, social media is a good example of something that would do well as a PWA. Twitter Lite and Pinterest both demonstrate how a truncated version of the website’s essentials would suffice in web app form.
Another good use case for a PWA would be for startups. Basically, if you don’t need your app to hook into the native features of a smartphone, and if your goal is more to present an improved experience on mobile devices, a PWA would be a cheaper and quicker way to get one out.
That said, a native app allows you to deliver an always-on and truly personalized experience to users. This is especially great for news publishers, blog sites, and e-commerce companies that want to deliver timely updates and native functionality to customers and followers.
Of course, with a native app, you’ll have to take into consider the costs, time to launch, as well as the choice between iOS and Android stores if you decide to build a native app…
Or do you?
Using Canvas, MobiLoud can publish your web app or website as a fully native app. With this approach, you get the benefits one would normally find solely with a native app — for example, app store distribution and push notifications — but you avoid the expense and effort of developing an app experience from scratch.
If you have an existing web community, web application or content site, a solution like Canvas gives you a way to experience all the benefits of an app without extra development. You can satisfy mobile users who prefer the web experience, whether they’re Android or iOS users, without incurring the necessary additional maintenance expenses for the two operating systems.
If you’re ready to develop your own mobile app, why not check out our free demo page?