Should your business build a web app or a mobile app?

This article is for a business that already knows it needs software — a booking system, a customer portal, an ordering app, a tool for field staff — and is deciding what shape it should take. If you are still deciding whether you need an app at all or a better website, read does my business need an app or a website first.

The choice is rarely either-or: almost all business software ends up with a web part, because somebody runs it from a desk. The question is whether the people on phones need an installed app, and when.

What each option actually is

A web app

Software that runs in the browser at an address. One codebase serves phones, tablets and desktops, updates are live the moment they are deployed, and there is nothing to install. It is also the only option that works comfortably on a desktop, where managers and admin staff spend their day.

A progressive web app (PWA)

A web app that can also be installed to the home screen, open in its own window, keep working on loaded screens when the connection drops, and send push notifications. Still one codebase, still updated instantly.

A cross-platform mobile app

An installed app for Android and iOS, written once in a framework such as React Native or Flutter. It reaches the phone's hardware properly, is listed on Google Play and the App Store, and avoids building the app twice.

A fully native app

Separate apps in each platform's own languages, Kotlin for Android and Swift for iOS. Worth it for heavy graphics or platform features a framework does not yet support; otherwise it means building everything twice.

The decision, factor by factor

Seven things settle it. Read across each row and notice which column you keep landing in.

What a progressive web app can do now

The PWA is the option most often dismissed on old information. On Android, Chrome offers to install a well-built PWA, and offline screens and push notifications work. Since iOS 16.4, Safari on iPhone also supports web push for web apps added to the home screen, but the iPhone limits are real:

• Installing is manual. iPhone shows no install prompt. The user has to open the Share menu and choose Add to Home Screen, so you have to show them how, and many will not bother.
• Notifications need the install first. Web push on iPhone works only for a web app on the home screen, after the user agrees from inside it. A customer using you in a browser tab cannot receive them.
• Some hardware is out of reach. Bluetooth and NFC from a web page work in Chrome on Android and not on iPhone, and background work such as tracking location while the app is closed is unavailable to a web app on either platform.

None of that matters for a staff tool or a customer portal opened once a month; it matters a great deal if timely notifications to iPhone users are the point.

What a mobile app adds, and what it asks of you

When an installed app is the right answer, nothing substitutes for it: a store listing, proper hardware access, consistent notifications, and an icon the customer chose to keep. What it asks in return is said less often.

• Store review on every release. Apple and Google review apps and updates before they go live, usually quickly and occasionally not, and a rejection means a fix and a resubmission.
• Fees and commission. Both stores charge developer account fees and take a commission on digital goods and subscriptions sold in the app. Payment for physical goods and real-world services, such as an order or a booking, normally goes through your own gateway.
• Two update channels. The web side changes when you deploy; the app changes only when each user updates, which some will not do for months, so the server must keep serving older versions or the app must be able to force an update.
• Accounts that must be yours. The Google Play and App Store developer accounts should be in your organisation's name from the start. Moving a published app between accounts later is possible, but it is paperwork.
• Yearly upkeep. Android and iOS each ship a major version every year, and both stores expect apps to keep pace.

The common path: web first, the app when usage proves it

1. Build the web app, with admin and staff screens designed for a desktop and customer screens designed for a phone first.
2. Make it a PWA: installable, quick to reopen, usable through short gaps in signal. Planned from the start, this adds little to the build.
3. Send the notifications that matter on WhatsApp or email, which reach customers whether or not they have installed anything.
4. Watch who comes back, how often and to which screens.
5. Build the mobile app for that group, around those screens, on the same backend. It is a second front end on a working system, not a second system.

Done in that order, the mobile app is specified by evidence, and every step before it was useful on its own. When Android, iOS and the web are all needed from day one, MyFloww builds them from one codebase as part of custom app and web application development; when they are not, this is the order we recommend, and it is how a first version stays small on an MVP build.

When you need neither

If what you need is a standard CRM, calendar or accounting tool, an off-the-shelf product with its own web and mobile apps may do the job today, and you do not need anyone to build anything. Custom CRM or off-the-shelf works through that test.