Mobile app or mobile website?

Whether to build a mobile app or a mobile website is answered by the needs list of a single surface: if a web browser delivers every item, no app is warranted. That surface is one screen where a named person does a named job, so a company-level answer has nothing behind it. On the KGM SsangYong showroom kiosk the screen belongs to the business, so the visitor never faces a download step.

The question is what the surface needs

An agency saying “let us build you a mobile app” has said nothing until it names the item. Ask which entry on the surface’s needs list the app satisfies, and why a web browser cannot satisfy that same entry. If the answer names an appearance rather than a capability, the decision has not been made yet, only the budget. We build mobile apps, and for most surfaces the answer this article arrives at is no.

Separating surfaces shortens the list first. A publishing surface takes over the job of paper: a catalogue, a menu, a business card. There the device belongs to the reader, the screen opens for a different person each time, and no installation step exists at all. An operating surface behaves differently. People sign in, records get written, and the same screen is opened by the same person every working day. This article is about the second kind.

It is worth saying why the unit is a screen and not a company. “Do we need an app?” cannot be answered, because a business runs several surfaces and their needs lists have little in common. The screen a visitor sees, the screen a field worker opens and the panel someone uses at a desk all carry different entries. Asked at screen level, the question has evidence behind it. Asked at company level, it only has a mood behind it.

The far ends of our portfolio answer the same question in contrary ways. On the showroom kiosk the app never reaches a visitor’s device at all; it runs on hardware the business installed. On the construction-site entry and exit app, the device is one the worker already carries and nothing is mounted on site. Both are installed applications, and their justifications come from different places entirely.

Which gives us the first rule. An operating surface is not by itself a reason to build an app. Even a screen opened by the same person every day needs no app if its list is satisfied by a web browser. If the reason sits on the list, an app is warranted; if it sits in a competitor’s storefront, it is not. A rival’s app does not change what your surface needs.

What a web browser hands a page in the foreground

On location the evidence can be quoted directly. Platform documentation states that location information is reachable only in secure contexts, and that the user must grant explicit permission through a prompt when a page asks for a position. Both conditions are required together: a secure connection, and a permission granted at that moment. The same documentation marks the interface as widely available across web browsers, which is to say this is not an emerging capability anyone is waiting on.

The camera follows the same shape. The page receives the feed with the user’s permission and the feed stays inside the page. Decoding a QR code from that feed is work the page’s own code does, on the page’s own account. Reading a code out of a camera image is a computation, and computations do not require a store download.

The “make it feel like an app” request usually surfaces here too, and its answer is not flat. On the web side, a manifest file declares an icon and asks for the page to open without web browser chrome. But the display field that governs this carries a plain assessment in the platform’s own documentation: it does not work in some of the most widely used web browsers. Whether an install prompt appears on its own also varies by platform. So the appearance request is met partly on the web, and the partial part is invisible in a demo. It shows up in the share of users whose platform behaves differently.

The most useful sentence in this section concerns permission rather than capability. The same documentation defines the lifetime of a granted permission this way: it depends on the web browser in use, and it may be time based, session based, or even permanent. That does not change whether the capability exists. It changes how much friction using it carries. On a screen opened several times a day, a permission prompt that returns on every visit is a cost attached to nothing the screen actually does. On a screen opened once a month, the same prompt is unnoticeable.

Our own portfolio holds a clear example of this. The capabilities the construction-site entry and exit app depends on sit squarely in this foreground class: reading a code with the camera, and writing the location into the record at the moment of entry. We described how identity comes from the QR code and the site comes from the location in a single record in a separate article. The conclusion that matters here is deliberate: on that project the capability list did not decide anything. The app was not built because a web browser could not do the work. The reason sits on a different axis, and we open it below, where the question becomes who holds the device.

What it withholds varies by platform as well

For items in this class the answer is not “no”, it is “it depends on the platform”. The sentence you find on the first page of search results, that a progressive web app works offline and sends notifications, breaks here. Not because it is false, but because it is answered as though a single answer existed.

Start with notifications. The mechanism is documented: for an app to receive push messages it has to have an active service worker, and that service worker is started as needed to handle an incoming message. So the page does not have to be open at the moment of delivery. Delivery itself, though, runs through the platform’s own notification service, and the extent of support differs from one platform to the next. When reliability is a requirement, that variance is a risk line of its own. Nobody tells you when a notification failed to arrive; the missing thing is invisible by construction.

The Tahlil.com patient app was built for a need in exactly this class: calling a patient back once the interpretation has been approved. We opened the queue mechanism that decides when an interpretation counts as ready in a separate article. The job here is only to place the need in its class, and the placement is the whole point. Reliable recall was a requirement, so it went on the list as one.

Location while the app is not open belongs on the same list, written more narrowly than we would like. What we can verify is the positive condition: while the page is in the foreground and permission has been granted, location is delivered. What happens once the page moves to the background is not defined by the sources this article rests on, and we do not write sentences we cannot source. No work in our portfolio rests on that need either, so its case cell in the table below stays empty.

A record waiting on the device without getting lost belongs here too. How a record captured without a connection gets sent later is a separate design job, and it appears as a single row in the table rather than as a paragraph here.

None of these items says “you need an app” on its own. If the item is not on your surface’s list, this entire section is about somebody else’s problem. If it is on the list, the decision comes down to one question: is that variance acceptable in your operation?

Shipping through a store is a distribution decision

An app store is not a capability. It is a distribution channel, and the price of the channel is charged on the release side rather than the capability side. Nobody draws that distinction at the decision table, because the first release is where the cost is least visible.

On the web, publishing has a single point. A new version goes to the server, and the user sees it the next time the page loads. Because no copy stays on the device, the question of who is running what never comes up. That is the zero point of the comparison.

In a store app the version lands on the device and stays there. Everything else follows from that sentence. First, the version you published and the version a user is running are separate things, and the distance between them is not yours alone to set. Second, every version still in use keeps calling your server. The contract on the server side has to keep carrying versions in use, which means the maintenance accumulates on your side rather than in the channel. Third, if you want everyone converged on the current version, you build that check inside the app itself. That is a development line item, and it stays alive on every release afterwards.

The same difference grows teeth when something breaks. On the web a broken release is rolled back on the server and nobody meets it again after the next load. With a version already on devices, rolling back does not retrieve the copy that shipped: the broken build stays on people’s phones and your server has to keep feeding it. Which is why testing in a store app sits earlier and heavier than the same work on the web.

The portfolio counterpart is concrete. The Tahlil.com patient app ships from a single codebase to two stores. A single codebase makes the development side single; it does not make the distribution side single. The same fix passes through each channel separately on every release, and that cost is paid for as long as the product lives.

None of this is an argument against stores. A distribution channel is worth its price when a capability comes back in return, and at Tahlil.com one did. The problem is never the cost itself. It is paying the cost and getting nothing back.

Who places the device, the business or the employee

When the capability list refuses to decide, change the question. Whose device is it?

The showroom kiosk answers most clearly. The business places the device. A visitor downloads nothing, types no address, meets no permission dialogue; the screen is already there and already open. The visitor’s web browser and the app store are both outside the equation. We argued why the download step is a threshold when printed catalogues move into software in a separate article, and on a kiosk that threshold never comes into being. Distribution turns into a device-management job instead. Which channel put the software onto the business’s own hardware is not written in our project record, so we make no claim about it.

The opposite end is the construction site. The employee carries the device, and nothing is installed on site.

Which brings the real question. If both capabilities sit in the foreground class, why an installed app rather than a page in a web browser? The answer is persistence, not capability. On the web side the lifetime of a permission depends on the web browser and can be limited to a session, which for someone opening the same screen every working day is a step that may return each time. Session and identity live in the web browser’s own data area; clear that area and the session goes with it. The entry point differs as well: an icon on an installed app, an address on the web. For a person standing on a site in work gloves, typing an address is the first friction of the day.

We are not presenting this as the recorded justification for that project. No such comparison is written in the project record. It stands as reasoning for somebody asking the same question today.

The rule comes out of those ends together. If the device belongs to the business, distribution is a device-management job and the visitor’s app store is not in the equation. If the device belongs to the employee, maintenance is paid on every release whatever the channel, and the app is warranted when the persistence gain covers that payment. If the device belongs to the visitor, the publishing surface stays in a web browser, because installation is the most expensive step there is.

The counter-case is real too. When the employee carries the device but the surface is opened rarely, the persistence gain shrinks towards nothing. For a screen opened a few times a month, a page reached by address is enough, and no distribution cycle gets bought.

The surface’s needs, line by line

Hold the table against your own surface and tick the rows. Its real information sits in the cells we left empty.

Where we left cells empty, we have no work resting on that need, and we are not inventing a case to fill a row. A table with a project in every row is a table bent to fit its projects.

How the table reads matters as much as what it holds. A row saying “yes” in the second column closes the app conversation. A row saying “varies by platform” opens it without closing it: the decision then turns on whether that variance is acceptable on your surface. The row saying “partly” is the most misleading of them, because it looks correct in a demo and behaves differently, quietly, for some share of the people using it.

Moving work a web browser already does into an app costs on every release

Taking a surface whose needs a web browser already meets and rebuilding it as a store app buys the following, with no capability coming back: a distribution cycle, a gap between the version published and the version running, a server obligation to keep carrying older versions, and an installation step in front of the user. An app is not an upgrade. It is a list of obligations.

Tahlil.com did not do that. Values are still entered on the website; the calculator opens a second way into the platform that needs no appointment, and that way is reached by address and by search, with nothing to install. We describe how a surface of that kind is built on the web side on the service page. The patient app was built for the single need a web browser could not guarantee, and it took over nothing the site was already doing.

There is an architectural counterpart to that restraint. The website, the physician panel and the patient app all sit on the same core. We covered why the number of surfaces listening to one core is a decision made before any code in a separate article. The consequence here is narrow: adding a surface is not the same as retiring one. As long as the surfaces read from the same core, each keeps doing its own job.

The cost runs in the other direction too. If your surface’s need belongs to the class that varies by platform, insisting on the web will not meet it. Where notification reliability is a requirement, “varies by platform” is a risk rather than an answer. In that case the app gets built and the distribution cycle gets bought on purpose, with the price known in advance.

So the closing question is yours. Is there an item on your surface’s needs list that a web browser does not deliver, and which one is it? If your answer names an item, the page describing field apps that keep recording when the connection drops covers that class of work. If your answer is that there is no such item, the site you already own is doing the surface’s job, and the thing worth discussing is not an app but whatever that site still leaves undone.