So you’ve decided that mobile is important for your product but now you’re faced with the choice between whether to build a native app, build a mobile web app or make your existing web app more responsive.
Sometimes it’s a straightforward decision, sometimes you have the luxury of just doing both in parallel, and other times it’s important to carefully evaluate the different factors that push you one way or the other.
The factors at play are largely driven by your customer, how you acquire them, and how they want or need to interact with your product as well as technical factors. That is, you need to understand your customer to really make the right decision here.
To be clear, in this post we’ve specifically focused on tech products and experiences that are looking to meet the needs of customers and users on mobile devices. We aren’t concerned with content or marketing websites for mobile users.
Broad Options: Responsive Web App, Mobile Web App or Native Mobile App
Broadly speaking you have three options to choose between to get your product into the hands of your customers that want to use their mobiles.
In no particular order, you can:
- Make your web app more responsive
- Build a mobile web app
- Build a native mobile app
You may only need one of these in some situations. While in other situations, you may need them all or you may find each one is best for a subset of the features or needs your customer has.
Let’s briefly cover what each of these options means.
1. Make your web app more responsive
One way to deliver a mobile product for your customers is to make your existing web app (assuming you have one) more responsive.
How you can do this? You use the same code base and apply techniques like responsive web design to get your existing features to function correctly and look pleasing on your users’ mobile web browser as well as browsers on larger devices (like desktops and laptops)
2. Build a mobile web app
Another way to deliver a mobile product to your customers is to develop a web application specifically for mobile users.
How this works is that the web application sits on your infrastructure (e.g. servers, cloud) and your users interact with your app through their mobile device’s web browser.
In this case, the key difference between this and making a web app more responsive is that you are developing a web app with the sole purpose of serving mobile users rather than having a web app that serves both desktop and mobile.
3. Build a native mobile app
Last but not least, the other way to deliver a mobile product to your customers is through a native mobile app.
A native mobile app is installed on the user’s mobile device and may (or may not) interact with your infrastructure.
Decision Factors
Before jumping to a solution, you need to spend some time mapping out the factors at play. These factors will help you determine which mobile option(s) to proceed with before you make a decision.
Again, you may pursue just one of the options. Or you may pursue them all. And you might even find yourself staging them. You can even take a more nuanced approach to build. Let’s say, a native app for one feature set (think Job-to-be-Done) while making your web app more responsive.
But whichever path you end up on, you want to start with a clear set of factors to inform your decision making. The list of factors below is meant to serve as a starting point to help you make your decision. You may be able to do it broadly for your product in general or you may need to iterate on it a few times. Starting with your broad product offering and then refining it to have multiple decision models for different subsets of features.
Let’s take a look at the factors that you need to consider when choosing between these options are:
How does or will your customer use your product (or feature)?
Ideally, you have some data analytics and insights that show how people are accessing your product and from which device. For example: e.g. 60% of views are from mobile devices. Additionally, you may have some qualitative interviews to help you understand where your customers are physically and what they want to achieve when they are on their mobile. And if you don’t have any. Then here are some considerations to think about:
- Where are they when they want to use your product? A big factor into which mobile option you take is where your user will be physically when they want to use your product.
- Can you make the web experience smaller or does it require a redesign for mobile? Does your web app have multiple items or fields? Or does it require a large screen to view the details? Then making the web app more responsive will be difficult. Designing an experience for mobile from the ground up will likely be a better solution, which shifts you towards a mobile web app or a native mobile app.
- How complex is the feature or screen? Some products, like a schedule builder for example, require large amounts of screen real-estate to help the customer get their job done. This is often an essential. So in order to offer a mobile experience, you’ll need to cut the complexity down on mobile and provide a subset of features. For instance, only view a schedule rather than allow to make changes. When there is complexity, this often leads to building specifically for mobile as a native app or web app.
- Does the experience need to differ significantly between iOS and Android users? Android and iOS users expect different user experience patterns. You can’t always develop one experience and expect both user bases to be happy. If a particular user journey needs differ significantly across the different mobile environments then you need to take this into consideration.
- How intensive are the graphics? Graphics, like those found in 3D games, or animations may require that you have a native mobile app.
- How important is load time? 53% of users will leave your mobile web app if it takes too long to load. And research from Amazon shows that every 100ms added in page load time cost them 1% in revenue. A native mobile app or at least a mobile web app may be necessary to get the speed you need for an appropriate user experience.
- Do you need notifications? If your user journey involves notifications then a native mobile app may be more appropriate. For iOS you must have a native app to send notifications. Whilst for Android, you can send notifications from a website to Android devices, however the native app provides better control. Additionally, you need to understand the needs of your users and the trust they place in a website versus an app sending notifications.
- Do you have mobile specific functionality? If you need to interact with GPS, wearables, the accelerometer or other features of a mobile device then you will likely find a mobile web app or native app is the most appropriate option. Many device features can now be accessed from the browser, so a mobile web app solution may just work. But this may not always be a good user experience that a native mobile app will present.
- Do you need to operate offline? If this is the case, this will almost likely require a native mobile app.
How do you want to acquire customers for mobile?
Mobile user acquisition is a key decision factor in which option you will choose. It’s essential to connect your target customers with your product. Some considerations are:
- SEO: Native mobile apps are not SEO friendly. Whereas, a responsive or mobile web app’s contents can be discovered by Google and users can click straight through and begin using your product. Keep in mind that many modern web apps are not built in ways that are SEO friendly, for example, using JavaScript to build content. As a result, your web app contents may not be easily discoverable and may require significant work.
- Native mobile apps require the user to install something. Some first time customers don’t necessarily want to do this until they trust you. While others prefer a mobile app straight away. You need to research your mobile early adopters to see where your focus needs to be initially and then over time. Not just relying on research on your broad customer base.
- App marketplaces. With a native mobile app you have access to the app marketplaces. If you play this the right way and fill a niche, then the app marketplace can become a meaningful channel for you. Where people searching the marketplace can discover your app.
- Just because they installed the app, doesn’t mean they’ll use it. Most apps aren’t used. The average user has 80+ apps installed but only uses about 9 apps per day and 25% of apps are used only once after being downloaded. Consider doing more research on who is your customer.
Who is your customer?
It’s important to understand who your customer is and get to know their needs for something versus their preference to select one thing over the other. This will give you a better understanding of whether your target customer has a strong preference or hard requirement for one of the broad options.
There are situations where a customer may not be able to install an app, for example, because their mobile device is locked down by their employer. Or, the lockdown may mean that a native app is necessary, depending on the nature of the device lockdown.
While other situations may be where your target customer does not generally have access to a desktop/laptop or tablet.
Take these factors into consideration and they may sway you towards one option or away from the others.
How long, difficult, and costly will the development be?
Now that you understand more about the scope and context around your product for mobile, you will also need to consider the implications for its development.
Estimating the time to complete each mobile development option will give you a sense of how long it will take, how much it will cost, and any technical challenges that will arise. You need to set a place of action, know your budget, and keep an eye out for any hiccups. These all factor into development.
Making a Decision
When it’s time to make a decision and in order to do so, you will need to decide which option(s) to proceed with by:
- Building your decision factors, using the lists above as a starting point,
- Going through each factor for each product or feature set you are considering for mobile,
- Determining if there is a clear winner, and
- Repeating these steps, refining your feature set until you have a roadmap and starting point to iterate out from.
More often than not, where a web app already exists, teams arrive at a more nuanced solution. That is, they look to create a mobile app but are focused, at least to start with, on specific slices of functionality from their existing app. For example, users can do approvals from the mobile app but attempt to access other functionality, like a workflow builder, which isn’t accessible. Another example here is, reports may be available via a mobile web app when clicked from an email link but these are in view-only mode. Logging into the web app lets you build the reports.
Mobile first. If you don’t have the baggage of an existing web app to consider, then you have the opportunity to build for mobile first and build for the desktop later. Mobile first is a compelling option for many businesses today. You still need to consider the factors above to work out which option to start with.
Keep in mind, you don’t necessarily need to go mobile. You may already have a strong web app. So the added upfront and ongoing costs and logistics of adding mobile apps may not make sense. With that being said it’s ok to purposefully say no to mobile.
Going mobile. Would you like to discuss the strategy for your mobile growth? Let’s chat today.
Read more about understanding your customer and their behaviour:
- The Complete Checklist To Truly Understand Your Customer
- 12 Behavioural Data Types for Product Management
- How to Run Early Customer Interviews
- 6 Steps to Validate JTBD with Surveys
- User Behaviour: What Nokia’s Demise and Facebook’s Success Tells Us
Scott Middleton
CEO & Founder
Scott has been involved in the launch and growth of 61+ products and has published over 120 articles and videos that have been viewed over 120,000 times. Terem’s product development and strategy arm, builds and takes clients tech products to market, while the joint venture arm focuses on building tech spinouts in partnership with market leaders.
Twitter: @scottmiddleton
LinkedIn: linkedin.com/in/scottmiddleton