The market keeps telling you that you need an app. The question you actually have to answer is different: is there something your customers need that a good website on a phone cannot do? If the answer is no, an app at this stage is a line of spending added to your business rather than to your customers.

This guide gives you a test you can run on your own situation, built on published rules you can check yourself: what the app stores accept and reject, when they take a cut of your sales and when they are forbidden from taking one, and what a phone browser can genuinely do in 2026. At the end you will find the signals that say the time for an app has come, and where to go once the decision is settled.

The question that comes before "which app?"

Our blog already answers the questions that come after the decision: which type of website fits your business if you choose the web, and native or cross-platform and PWA or native app on cost if you choose an app. This page sits before all of them, at a single question: do you need an app at all?

Confusing the two questions is expensive. An owner who starts at "Flutter or React Native?" has paid for an answer before confirming that the question applies to him.

What actually separates a website from an app

A website is a link. Anyone can open it instantly on any device, and someone who has never heard your name can reach it through search. You publish a change today and every visitor sees it within minutes.

An app is a file installed on a device, and it only reaches a user by their decision: open the store, search your name, agree to the download, wait. After installation it lives under a third party's terms. Apple and Google review every release, set conditions for acceptance, and impose annual obligations we will come to.

What has changed in recent years is that the list of "things a website cannot do" is far shorter than most people advising you assume. Push notifications, for instance, have been widely available across browsers since March 2023 according to MDN. Working without a connection is possible through a service worker that intercepts network requests and serves them from a stored copy. Location has been available in browsers since July 2015.

So the sentence "an app does things a website can't" is true, but the things in question are fewer and far more specific than they look in a quotation.

Five cases where an app is the right call

1. The same people use it again and again

An app is an icon someone taps without thinking. That advantage is worth nothing unless they open it on a regular rhythm: a sales rep logging visits daily, a subscription customer checking a balance weekly, a patient recording readings. Someone who deals with you once every few months will have deleted your app before the next visit, and will search for you on Google exactly as they do today.

Put a number on it. How many times a month does one customer need to open the thing you are building? If the answer is under two, the icon will not be used.

2. The notification is part of the service itself

There is a difference between a marketing notification that could just as well arrive on WhatsApp or by email, and a notification without which the service loses its meaning: alerting a driver to a new order, telling a pharmacy a prescription has arrived, calling a technician to an urgent fault.

The web sends notifications, with one detail that matters for iPhone users. Apple's WebKit documentation states that a web app added to the Home Screen is the one that can request notification permission, and that the request must come in response to direct user interaction. In practice: an extra step your customer performs before the first notification ever arrives, and a share of your audience will not perform it.

If every single user must receive the alert for the service to function, that is a point for the app. If the notification is a reminder about an offer, a cheaper channel does the job.

3. Work continues where the network does not

Reading data offline works on the web. The difference shows up in another kind of work: the device continuing to send what it collected after the screen is locked or the session ends. The Background Synchronization API is still of limited availability, and MDN is blunt about why: several of the browsers your customers actually use give it no support at all.

Stocktaking in a basement warehouse, a rep recording dozens of orders while moving through areas with weak coverage, a field team on a construction site: here the app buys you reliability the web cannot sell you today.

4. You need hardware beyond the ordinary

Camera and location are available in the browser. The problem starts after them: connecting to a receipt printer or a measuring device over Bluetooth relies on the Web Bluetooth API, which MDN marks as experimental and of limited availability. Continuous barcode scanning through a full shift, working with device sensors, and running in the background all sit in the same territory.

The practical rule: write down every device the software will touch, then ask your developer about the support status of each one on the web before you decide.

5. The app is the product

If what you sell is the phone experience itself (a game, a digital subscription product, a tool built on daily use), you are not choosing a delivery channel, you are building the product. There is no question here.

What you needDoes a website do it today?Basis
Instant notificationsYes, with the Home Screen step on iPhoneWebKit documentation
Opening content offlineYes, via a service workerMDN documentation
Syncing collected data after the session endsLimited, unsupported in some browsersMDN documentation
Camera and locationYesMDN documentation
Bluetooth devices and receipt printersExperimental and limitedMDN documentation
Being found by people who don't know your nameYes, through search indexingGoogle documentation

Who the app is really for: your customers or your team

In half the cases that start with "should we build a customer app?", the real need sits with the people who work for you rather than the people who buy from you.

Take the five cases above and apply them to your staff. The rep opens the software ten times a day, gets a notification about an urgent order, works on roads where coverage drops, and may need a receipt printer in the car. That is four yes answers from one person. The customer who orders once every two months answers no to all of them.

The ordering that comes out of this reading differs from the quotation you probably received: a website or store for the customer, and a focused app for the field team. It is also cheaper, because a team app is distributed to a known number of devices and needs none of the polish, marketing and ratings management that a public app demands.

Four reasons the website is the smarter call

Your new customers arrive through search. Google's documentation explains that the search engine discovers pages by crawling and indexes them automatically, while noting that indexing is not guaranteed. That channel works for you continuously once you have pages worth showing, and how to work on it is covered in our SEO guide for companies in Egypt and the Gulf. An app has no equivalent: whoever has not chosen to install it will never see it.

A change reaches everyone immediately. You adjust a price or add a branch and every visitor sees it. In an app, each release passes through store review, and users who have not updated stay on the old version, which leaves you supporting two versions at once.

Planning to build or scale a digital project?

Snaabble provides a tailored technical assessment to define the right stack & exact budget.

Chat on WhatsAppExplore Services

Contact with your customer is infrequent. A law office, a contracting company, a dental clinic a patient visits twice a year: all of them are better served by a site that books an appointment and answers common questions than by an app that will not be opened.

The idea is still being tested. While the service itself changes every couple of weeks, the web gives you the freedom to change direction without a review cycle each time.

The running bill that never appears in the quotation

An app quotation covers the build. What follows are recurring items that have nothing to do with your developer:

What you pay annually after launch is broken down in our app maintenance cost guide, and the publishing steps themselves in the store publishing guide.

Store commission: the rule most advice gets wrong

"The stores take a cut of every sale" is a line repeated in every discussion about apps, and for most people reading this page it is not true.

The published rules say the opposite for anyone selling goods or services consumed outside the app. In the App Store Review Guidelines, section 3.1.3(e) states that an app enabling the purchase of physical goods or services consumed outside it "must" use a purchase method other than in-app purchase. Google Play's payments policy matches it: the Play billing system must not be used when payment is for physical goods such as groceries and clothing, or physical services such as transport, food delivery and event tickets.

That means a restaurant, a clothing store or a clinic each sells through the payment gateway it contracts with directly, such as Paymob or Fawry, and pays the store no percentage of the order.

Commission territory is narrower than the advice suggests: digital content or subscriptions consumed inside the app. Even there the common figure is not 30%: Apple's Small Business Program reduces the commission to 15% for developers whose proceeds did not exceed one million US dollars in the prior calendar year, and Google Play's service fees are 15% on the first million dollars of annual earnings and 30% above that, with 15% on subscription renewals.

So if you sell a physical good or a real-world service, delete the commission line from your calculations, and stop treating it as a reason either to delay the app or to choose it.

The condition that kills "just wrap my site in an app"

The request owners make most often is to turn the existing site into an app as quickly as possible. The App Store Review Guidelines address that request directly in section 4.2: your app must include features, content and a UI that lift it "beyond a repackaged website", and section 4.2.2 excludes apps that are essentially web clippings or a collection of links.

Read that as an acceptance condition rather than design advice. If your plan is for the app to deliver exactly what the site delivers, you are paying for a build that may be rejected, and then redesigning something that already worked. The full text is in the App Store Review Guidelines.

Six questions before you pay

Answer yes or no, from what you know about your customers rather than what you hope:

  1. Does one customer need to open what you are building at least twice a month?
  2. Does the service lose its meaning if a notification is delayed or missed?
  3. Do your users work where the network drops, with recording and sending that must continue afterwards?
  4. Does the software deal with a device other than the camera and location?
  5. Is your audience already yours (a customer list, employees, subscribers) so nobody needs to discover you through search?
  6. Is the app the product people pay for?

Two or more yes answers: the app is justified, and your next step is deciding which kind. One: it can usually be covered by an improvement to the site or an existing channel before you build a whole app. Zero: the website is the right decision now, not a temporary workaround.

A hypothetical worked example

A clothing store in Mansoura sells online and takes orders on Instagram and WhatsApp. Its answers: the customer buys every two months (no), notifications are offer reminders (no), all work happens in a connected shop (no), no device beyond the camera (no), new customers arrive through search and ads (no), the app is not the product (no). Zero: the decision is an online store that works well on a phone, and the remaining budget goes to product photography, page speed and the payment gateway.

A food distributor in the same city, with six reps visiting shops daily: frequency (yes), urgent order notifications (yes), patchy coverage on the road (yes), receipt printer (yes). Four yes answers from his own team, so he starts with an app for the reps and defers the customer app.

The two businesses are close in size and budget. What separated them was how often the software is opened, and the conditions it is opened in.

Signals that the time has come

You do not need intuition here. The signals show up in your data and your calls:

  • The share of returning mobile visitors is rising, and the same people come back weekly.
  • Customers ask for an app by name, not in a survey you started.
  • The average gap between one order and the next from the same customer has dropped below a month.
  • Your field team complains about losing data when the network weakens.
  • An operational need has appeared in the "limited" or "experimental" row of the capability table above.

Two signals together are enough to start estimating cost. At Snaabble every project begins with a discovery session that defines scope before any code is written, and that session is the natural home for this decision: the need is settled before the technology is.

Once the decision is settled

If the answer is the website, choosing its type is the next step, covered in types of websites for business.

When the answer is the app, the logical order runs: pick the approach in native or cross-platform, compare the cost against the lighter alternative in PWA or native app, then review the steps to build an app and the cost breakdown before signing anything.

For a second opinion on your own case, put it to the Snaabble team through the mobile apps page: you get back an initial plan with a time and cost estimate within 24 hours, free and with no obligation.

Frequently asked questions

Can I start with a website and add the app later without rebuilding?

Yes, if it is agreed from the start that services and data live in a layer independent of the interface, so any new interface can consume them later. Ask for that condition in writing in the scope of work before you sign, because adding it afterwards means rewriting part of what you already paid for.

Does having an app help me show up on Google?

Your visibility in Google Search comes from web pages it crawls and indexes, as Google's documentation explains. An app in the store is a separate discovery channel inside that store, and it does not compensate for the absence of a site that appears in search results.

My client in the Gulf wants an app because a competitor has one. What do I tell him?

Put the six questions above to him about his own business. If every answer comes back no, the competitor's app is information about the competitor's decision rather than about market demand, and he may well be paying annual maintenance on an app nobody opens.

Does an app raise customer trust even if it is rarely used?

The impression of seriousness comes from fast replies, service quality and a site that is clear on a phone, all of which are faster and cheaper than building an app. A published then neglected app, with low ratings and an old release, gives the opposite impression to anyone who opens its store page.

Sources