Many businesses are dealing with this quandary at the moment, and there a number of factors to keep in mind when deciding how to cater for users on mobile devices. These factors can be broadly broken down into 2 categories: User Experience (UX) and technical considerations.
Firstly, however, lets discuss what these 2 options actually are.
Responsive Web App
This is a website that shows up differently depending on the screen size you’re viewing it on. For example:
- When shown on a PC’s web browser (i.e. a large amount of real estate), it will show everything.
- When shown on an iPad’s web browser (i.e. a medium amount of real estate), it repositions some things and potentially removes some parts.
- When shown on an mobile phone’s web browser (i.e. a small amount of real estate), it shows a cut down and optimised view, often removing whole sections if necessary.
Responsive Web App – Decision Factors
The UX benefits of this option include:
- Familiar experience – users who use multiple platforms will see a similar experience.
- No install – one barrier for use can sometimes be that users may not want to install an app on their mobile from a company that they don’t trust yet.
- Some access to phone features – Web apps have recently been given access to many device specific features via the API, meaning that you can now use the phone’s GPS, camera, accelerometer, etc from the browser.
- SEO friendly – customers will be able to Google your web app easily… Native apps are not SEO friendly.
- Mobile First – if your users are primarily going to be using your web app via their mobiles, you can build the UI with that in mind, and optimise for their experience. In extreme cases, you may not even worry about desktop users at all.
The Technical benefits of Responsive Web Apps include:
- Price – it’s generally cheaper to build and maintain 1 application that can be used on any device that has a web browser (PC, Mac, iOS, Android, etc.).
- Web Wrapper – If your web app is a Single Page Application (SPA) then by using technologies such as Cordova or Electron, you can wrap them in a native app “shell” that allows them to be installed directly onto a mobile device, and removing the header of the web browser… giving some of the stickiness of a real native app.
Native Mobile App
This is an application that is installed directly onto your mobile device via the App Store (for iOS) or Google Play (for Android).
Native Mobile App – Decision Factors
The UX benefits of this option include:
- Stickiness – You have a button on your phone to open it directly. You don’t need to open the web browser and navigate to the URL.
- Full access to phone features – almost anything the phone can do, you now have access to, including multi threading, Augmented Reality libraries, etc.
- Offline access – although technically possible to some extent with some web apps, this is much easier for native apps.
The Technical factors of Native Mobile Apps include:
- Hybrid – you used to have to build 1 app for iOS, and another completely separate app for Android, but now with technologies such as .NET MAUI, Flutter, Electron, etc, you can build 1 app that will work on both.
- Expensive price – if you need a web app anyway, then you’re still doubling up as you’ll need to build and maintain a web app and a mobile app separately.
- Code reuse – if you choose your stack carefully, you can get a lot of code reuse across mobile and web platforms. For example, you could have a .NET API, Blazor web UI, and .NET MAUI mobile app, (which can reuse a lot of the Blazor components).
This question can really only be answered by each organisation specifically, but at the risk of oversimplifying:
- If you need to keep your costs down, most of your users are on the web app on their desktops anyway, and you don’t need heavy offline access or other phone features, go with a Responsive Web App
- If you need to be accessible via the App Store or Google Play, need the experience optimised for mobile users, need phone specific features like offline access, and don’t care about desktop users, go with a Native Mobile App, preferably Hybrid so you only have to build and maintain 1 mobile app