Today I would like to introduce one of my former UX students – Christian Eigl. My students in CareerFoundry’s Certified UX Designer Course create one Native and one Web app design, therefore, we always have the discussion about which is better and for whom. I found Christian’s approach to explaining the difference interesting and am happy to share it here.
Christian, the blog is yours…
Let me tell you a story
In this post, I’ll talk about the distinction between Web Apps and Native Apps. But before we start, let me take you someplace else. ‘Where’, you ask? Well, I live in a European city that has a rich history of over 1000 years. One day, a friend of mine came to visit me. We took a stroll around the old town. Actually, she did. I just wanted to get from point A to point B. I solely had our destination in mind. “It is very beautiful here”, she said. “ Ah … it is?”, I replied eloquently. I had forgotten about the beautiful architecture surrounding me because I turned on autopilot going after my daily routines.
There is always more to see than one can perceive at once. With UX, it is the same. When you are native to the web, you may lose the beauty of detail. Now, I realize, that there had always been more to perceive in an App than my eyes had seen before. I know, that sounds a bit paranormal and creepy 😉, I get it, but I hope I got my point across. After reading the following, you will have one more distinction to lay your focus on. You will know the difference between a Web App and a Native App. Ready for the revelation?
The Native App
You may not have noticed, but it is VERY likely, that you have used Native Apps before. They are the little pieces of software on your smartphone one can download from Google Play or iTunes. These platforms provide you with information on the App itself and also give you access to user reviews. Native Apps are tied to your device and are able to use technical features of your phone, i.e. camera, microphone and gps tracker. Think of them as Apps that ‘live’ on your smartphone, using the resources surrounding them. That’s why you can call them native to your phone. They usually have a splash screen, some kind of onboarding, a registration and pop-up tutorials. Some of them send reminders to your device’s screen. All in all, the information flow can be described as a guide, taking you by the hand screen by screen.
The Web App
Opposed to the Native App, the Web App is not downloaded onto your device. The software is stored on a server and accessed via the Internet Browser. It most likely has free navigation out of a centralized site. Why is that? One reason is, that the Web App is approached via a Browser. That also means that a Web App user may access the App with his desktop PC, tablet or smartphone etc. Today almost every Website and Web App has a responsive design (adapting to the device’s format). The screens often are structurally derived from a website. Most commonly, it has a home screen as a landing page, on which the App introduces itself and one gets additional information about the latest news etc. Features are often accessed by central navigation, which is organized in some kind of tree-structure.
However, earlier mentioned distinctions are just an approximation. Some Apps have overlapping properties. Especially some newer Web Apps do have features similar to Native Apps. They are called Progressive Web Apps. In a way, they are built upon the distinction between the Native and Web App. So in order to understand their upcoming you need to understand the problems they are trying to solve, or in other words the features, they are trying to merge together. That is why they shall not be discussed here.
A closer look
Interestingly dry? If you struggle to choose the right technical ‘platform’ for your app, don’t worry. You are not alone. I know at least three people who are indecisive as well. Greg, Linda and Alwin. To determine what App might fit our needs best, we will create three Micron-Personas (sorry, that is not a thing 😉). Empathy is (hopefully) a UX Designer’s asset. So why don’t we practice a little empathy for our stakeholders? There is:
- Greg the business guy: “Money, money, money.” (Sorry Greg 😉)
- Linda the development lead: “Keep it simple and flexible.”
- Alwin the user: “I want it all … for free. Muahaha.”
Let’s take a closer look!
I am Greg (Business Guy)
Hi, I am Greg. I have a product concept, but I don’t know what technical platform to choose.
A big PRO for the Native App is easier access to user information. I can collect the user’s data which can be sold to 3rd party organizations. They in return will use the data for marketing purposes or resell the data again. This way I can offer my app’s services for free and therefore increase the number of users which will provide me with more user data. This will add to the revenue streams of my company. Big thumbs up 😉 And in case the internet connection is disrupted, the Native App is able to collect data offline for later data transfer. Offline usage is also an asset for the product itself. The user is not bound to the internet reception, which makes the App more flexible than competitor (Web) Apps. A good argument, isn’t it?
I ‘d say yes if the Native Apps weren’t so cost-intensive. That is a big CON. It has to be developed for different smartphone operating systems (i.e. Android and/or iOS). Also, the maintenance of the software and the adoption of the latest standards create a lot of additional costs. That adds up for every operating system the App shall run on. Oh, and talking about operating systems, the marketing of the App is restricted to the providing marketing platform of Google Play for Android, and iTunes for iOS. In business, being dependable on a second party’s terms and conditions is considered a risk factor.
But is the Web App a better solution? If I compare the Web App with the Native App, it is very budget-friendly. That is a PRO for the Web App. Why? Well, the development team only has to code for one publishing platform, the World Wide Web. Also, the maintenance is relatively easy, because there is only the latest version of the App online. No older software versions, users still might have installed on their devices, have to be taken into account. Every time the user refreshes the browser, the latest version will automatically pop up on their screens. That is why updates can be facilitated independently of devices. This independence of devices and platforms also means that Web Apps have a high marketing range. I can market anywhere in the WWW on any device. Additionally, I can publish my product very fast, due to Web Apps are not bound to any confirmation process of a platform like Google Play. This hopefully gives me a competitive advantage.
But as always, there are also some CONS. The App has to be developed for and adapted to multiple browsers. That will add to the costs. Also, Web Apps don’t collect steady usage patterns and user data without explicit consent, like Native Apps. I can’t sell as much data to 3rd party organizations. Therefore, I have to think about other revenue streams. Another point I have to consider is the point of sale. Where to market? I don’t have the comforts of Google Play or iTunes marketing services. My Web App needs an individualized marketing strategy. Alone the SEO (Search Engine Optimization) and SEA (Search Engine Advertisement) drain resources.
What would you choose? Maybe I should ask Linda of the development team for additional insights.
“Hey Linda, can you help me choose the right publishing platform?”
Hi, I am Linda (Development Lead)
Sure, I can give you some ideas about the up- and downsides of these two App types out of a development perspective.
Although there are a lot of tech templates, which simplifies the development process (PRO), Native Apps still are very maintenance-intensive (CONS). Not only do we have to take care of different operating systems, but also different versions of them on the user’s devices. Not all users have the latest iOS or Android running on their phone. This is why the development itself is more vulnerable to external influencing factors, like changing devices, and technical progress etc. Furthermore, Native Apps need the approval of the hosting platforms, i.e. iTunes, App Store, or Play store which can slow down or interrupt the workflow. We need to include these factors while scheduling for the release of the App.
In contrast to that, Web Apps are relatively easy to maintain and no platform approval for launching the App is required (PROS). But it sounds too good to be true. The crux is, that we have to take a pass on Native App features, like GPS or the device’s camera (CON). Although, with the development of the Progressive Web Apps this downside gets smaller and smaller. Maybe that is why there is a hype for these now.
But maybe you should also take our users’ needs into account, too. Our UX Researcher Sheila (Sorry Sheila, no Micron-Persona for you 😉) has already made a Micron-Persona (still, not a thing) for us. His name … ähm. Oh yeah, his name was …
This is Alwin (User)
To be able to use the features of his smartphone device (camera, microphone, GPS, …) is a PRO for the Native App. Alwin has access to features a Web App cannot offer. Secondly, Native Apps have better performance results, due to they are customized to one operating system. This makes the App run faster on his phone. And Alwin is notoriously impatient 😉 Another, benefit for Alwin is the free marketplace support of Google Play or iTunes. Play Protect of Google Play is a good example. It constantly scans the installed Apps for malware making additional anti-virus software on your smartphone almost obsolete. One worry less. Also, being stored on Alwin’s phone and having access to the storage of the device, the App is able to run independently from the internet connection.
But the latter point also carries a CON with it. The App requires additional storage space. In addition, Alwin has concerns about his data privacy. Especially free versions of Native Apps use his data as a ‘quid pro quo’ to trade for 3rd party interests. He knows, nothing is for free 😉
A PRO for Alwin using a Web App is, that he does not have to worry about device compatibility. Having a browser is enough. Also, he doesn’t have to mind about any version updates, due to a Web App is always updated to the latest version. Pretty comfortable, ey?
And the CONS? Of course, Web Apps don’t have access to most of his device’s features. Also, in opposition to Native Apps, there aren’t any safety guarantees. Alwin relies on his own internet security software.
“Oh boy, my license runs out, too …” 😉
Last but not least
Well, I hope you found this little article informative. What App to choose best, highly depends on your project objectives and the product itself. Do you want to publish fast? What is your budget? What features are essential for the service you are trying to provide? If you are interested in wrapping your head around this distinction any further, feel invited to find a solution for the following three example exercises.
Have fun and see you somewhere, somewhen! 😉
Exercise – What App type is best suited?
– Imagine being in a small company. The App itself doesn’t represent the core business of your organization. It is merely a part of the marketing strategy for your company’s services. It shall inform, be fun and create trust on the user’s side. The App will be advertised on the company’s homepage. Most likely, the users wouldn’t have searched for the App
– The Software Company you are working in gets an assignment to build a learning App for a 10.000+ organization in the automobile industry. This shall be the learning process: A worker gets to a machine station. The Learning App on her or his mobile phone gets a signal via a Low Energy Bluetooth Beacon that is installed on the machine itself. The App then opens up a step by step instruction on how to use the machine in front of the worker.
– You are working for a 10.000+ company. The App shall be designed for onboarding and team administration purposes helping employees to find their way into the company or a new team. Next to other features, the app shall include information on the team members, addresses of contact persons, team objectives, a search bar, a help desk, as well as a planning tool for scheduling meetings with your future team members.