5 min read

Mobile app or web app: which does your business need?

Thinking about an app? How to decide between a native mobile app and a web app, what each costs you over time, and the questions that settle it.
Mobile app versus web app

“We need an app” is one of the most common things a developer hears. Sometimes it’s exactly right. Often, what the business actually needs is something people can use on their phones, which isn’t quite the same thing. Before commissioning a mobile app, it’s worth checking which one you actually need.

The choice between a mobile app and a web app affects cost, timescales, how customers find you and how much ongoing work you’re signing up for. It’s worth getting right before anyone starts building.

The difference in plain English

A native mobile app is downloaded from the Apple App Store or Google Play and installed on the phone. It has an icon on the home screen and can make fuller use of the phone’s features.

A web app runs in a web browser. You visit it through a link, like a website, but it behaves more like software: people log in, fill in details, see their own information and get things done. A well-built web app works on phones, tablets and computers from a single build.

There’s a middle ground too. Progressive web apps can be added to a home screen and offer some app-like features, and some development approaches let one codebase produce apps for both iPhone and Android. What each of these can do varies by device and changes over time, so it’s worth checking the specifics for your use case with your developer.

When a web app is usually the better choice

  • People will use it occasionally. Customers checking an order, booking an appointment or viewing a quote don’t want to download anything for that.
  • It needs to work on desktops too. Office staff, customers at work and anyone who prefers a bigger screen can all use the same thing.
  • You want to reach people through a link. Emails, texts and search engines can send people straight to a web app. An app store listing is an extra step.
  • You want to change it often. Updates to a web app go live for everyone straight away. There’s no waiting for app store review or for users to update.
  • Budget matters. One build that runs everywhere is generally cheaper than separate apps for each platform, both to build and to maintain.

When a native mobile app earns its place

  • People will use it daily. A tool your staff open many times a day, or a service your customers rely on regularly, benefits from sitting on the home screen.
  • It needs to work offline. Engineers on sites with poor signal, for instance, may need to record work and sync later. Native apps tend to handle this more comfortably.
  • It relies on phone hardware. Heavy use of the camera, location in the background, Bluetooth devices or other sensors can point towards native.
  • Push notifications are central. Web apps can send some notifications, but native apps have historically been more dependable here.

Ask how often people will use it and where they’ll be when they do. Those two answers usually decide it.

The ongoing costs people forget

Building is only the start. With native apps in particular, budget for:

  • Developer accounts with Apple and Google
  • Updates when new versions of iOS and Android are released
  • App store review each time you publish a change
  • Maintaining separate versions if you’ve built separately for each platform
  • Hosting and maintaining the server side, which almost every app has

Web apps have running costs as well, like hosting, security updates and support. But there’s typically one thing to maintain rather than two or three.

Questions to settle before you brief anyone

  1. Who will use it: staff, customers or both?
  2. How often will they use it, and for how long each time?
  3. Where will they be, and will they have a good signal?
  4. Which phone features does it truly need?
  5. How will people find it in the first place?
  6. How often do you expect to change it?

If most of your answers point to occasional use, mixed devices and frequent changes, start with a web app. You can always build a native app later once you’ve proved people use the thing.

A sensible path for most businesses

For many small businesses, the lowest-risk route is to build the core as a web app first, make sure it works beautifully on phones, and watch how people use it. If usage is frequent and you’re hitting the limits of the browser, that’s real evidence for a native app, and much of the server-side work will already be done.

Talking through your idea

If you’ve got an app idea and aren’t sure which route fits, we’ll help you work through these questions honestly, including whether you need an app at all. Our mobile app development team handles native builds, and web-based systems sit within our custom development work.

Share this article
Written by the Ignite Creative team

We’re a web design, branding and marketing agency in Liverpool. These articles come from the questions clients ask us every week. If this one raised a question about your own business, send it over.

In this article
In this article
Got a question about this?

Tell us what you're working on and we'll give you a straight answer.

More on this topic

Need help with the real thing?

If an article has raised a question about your own website, brand or marketing, send us the context and we’ll take a look.