When a company decides to move part of its work onto mobile, the first technical question it is asked is whether it wants a native app or a web app. It sounds like something for programmers, but the answer depends on how your people work: where they are, what device they carry, whether they have coverage and what they need to do with the phone. This article explains the differences in plain language and gives you the criteria to choose.
What each type of app is
Native app
This is installed from the app store (Google Play or the App Store) and is built for the phone's operating system, Android or iOS. It has full access to the camera, GPS, NFC reader, Bluetooth and notifications, and it can store data on the device itself to work offline.
Web app
This is an application that opens in the browser on a mobile, tablet or computer. There is nothing to install from a store: all you need is an address and a user account. It is updated on the server, so every user sees the latest version straight away. Modern versions can be added to the home screen and can store some data, but their access to the phone's hardware is more limited and depends on the browser.
Hybrid or cross-platform app
There are options in between: apps that are installed like a native one but are developed just once for Android and iOS. For many business apps they are a balanced solution.
The differences that matter in a business
| Aspect | Native app | Web app |
|---|---|---|
| Installation | From the store or internal distribution | None, it opens in the browser |
| Working without coverage | Full, if designed for it | Limited |
| Camera, GPS, NFC, Bluetooth | Full access | Partial, depending on browser and device |
| Updates | Publish a new version and have it installed | Immediate for everyone |
| Use on a computer | No, unless there is a separate version | Yes, the same application |
| Development cost | Higher if you need both Android and iOS | Usually lower |
| Publication in stores | Must meet their review rules | Not applicable |
Five questions to help you decide
- Is there coverage where the work is done? This is the question that decides most. On a farm, at a building site on the outskirts, in a warehouse with a poor signal or on a route along minor roads, an app that stops working without a connection is useless. You need an app that stores data on the device and syncs it when the signal returns.
- Do you need the phone's hardware? Reading NFC tags, scanning codes quickly, connecting a printer or a Bluetooth reader, or recording position reliably all point towards a native app.
- Who is going to use it? If it is your employees, on devices the company controls, installing an app is not a problem. If it is customers or suppliers who will use it now and then, asking them to install something is a barrier: a web app usually works better.
- Will it also be used from the office? If the same tool is used on mobile and on a computer, a web app avoids maintaining two versions.
- How often does it change? If the screens or rules change frequently, the immediate updating of a web app is an advantage.
Examples of what suits what
A few typical cases, as a guide:
- Work reports from technicians out in the field. Hours, materials, photos and customer e-signature in places where coverage is unreliable: a native or hybrid app with offline working.
- Field logbook on the farm. Entries are made in the plot, often with no signal: an app that works without coverage.
- Customer bookings or orders. People who log in once a week and do not want to install anything: a web app, with a good mobile version.
- Viewing reports for management. Read on a mobile, tablet or computer, with no need for sensors: a web app.
- Reading labels in a warehouse. Continuous scanning and perhaps connected readers: a native app on company terminals.
Some areas have their own regulations, such as the working time record from a mobile, and they have specific solutions; for example, Gesthoras for clocking in and out. For a custom-built business app, the important thing is that it fits in with the rest of your software.
What you should always ask for
Whichever type you choose, there are requirements worth putting in writing from the start:
- Offline operation defined. What can be done without a signal, what happens if two people change the same thing, and how the user is told that there is data waiting to be sent.
- Connection with the management software. What is entered on the mobile has to reach the office without being retyped.
- Users and permissions. Each person should see only their own information and, if someone leaves the company or loses their phone, their access can be removed.
- Screens designed for real use. Large buttons for people working with gloves or in the sun, few steps and as little typing as possible.
- Android and iOS, or just one. If the company provides the phones, one system may be enough. If everyone uses their own, you will need both.
Common mistakes
- Choosing a web app on price and discovering in the first week that there is no signal on the farm.
- Building a native app for customers who log in twice a year and never install it.
- Designing the app as a copy of the computer screens, with twenty fields that nobody fills in out in the field.
- Forgetting that someone has to maintain the app when new versions of Android and iOS come out.
How we do it at Infonet
At Infonet Consultores we have been developing apps for Android and iOS since 2013: consumer apps with thousands of downloads and business apps that keep working without coverage and sync when it returns, which is what farms, building sites and delivery routes ask for. We also build web applications, from an informational website to a complete cloud application, and many of our applications are used from the browser on a mobile or tablet. You can see examples on our page on Android and iOS app development, and if the app is part of a larger project, on our custom software development page.
