Does your online store need an app, or a better mobile website?
An ecommerce app earns its place when it makes a recurring customer task easier and creates more value than it costs to build and run. A high share of mobile traffic, or a competitor with an app, is not enough. This guide compares mobile websites, PWAs and store-distributed apps, with practical examples from repeat purchasing and B2B ordering. It also shows how to calculate a return without treating every order placed in the app as a new sale.
Consider two stores. One sells garden buildings: customers research their purchase for weeks and may not buy another for years. The other supplies packaging to cafés that reorder similar items every week. Both might receive most of their traffic from phones. Their case for investing in an app is nevertheless very different.
This guide focuses on physical goods. Choosing the underlying commerce platform is a separate decision, covered in our hosted platform versus custom ecommerce guide. We checked platform documentation and distribution policies on October 23, 2026. The business examples and financial model below are illustrative, not reported client results.
01Start with a reason to come back
An app asks something of the customer. They have to discover it, install it, possibly sign in and work out why it deserves a place on their phone. That effort is a cost even when the download is free. “Our store is now available as an app” does little to repay it.
A stronger promise describes a useful task: repeat a weekly order, scan an empty packet to find a replacement, or bring up a collection code at the counter. Value comes from fewer steps, fewer mistakes or better information. Sometimes a mobile website can deliver that value just as well. Finding that out is a successful outcome of discovery.
Choose a recurring customer situation, rather than a catalog size. Ten frequently reordered products may provide a better reason to install than ten thousand products bought once every few years. An expensive, infrequent purchase can still support an app through aftercare, replacement parts and maintenance bookings. In that case, the investment is in a customer service tool rather than a second storefront.
02Use order data to identify the audience
Begin with customers who already return. How long is the gap between their first and second purchase? Which groups order regularly, and what do they repeat? Separate business buyers from consumers and seasonal purchasing from routine replenishment. A single store-wide average can hide both a promising audience and a much larger group that has little need for an app.
Look at contribution after variable costs as well as order frequency. A frequent buyer who only purchases at a steep discount and returns much of the order may not fund a new channel. Support requests are useful evidence too: forgotten passwords, missing invoices and repeated searches for a compatible part point to tasks you can test in a prototype.
Define a small, specific audience. For example, café managers who replenish the same supplies every week while also serving customers. Observe the current process. If most of the delay comes from obtaining a supervisor’s approval, a more attractive catalog will not solve it. Your proposal needs to improve the whole job, including the steps outside the screen.
03Compare the routes before choosing the technology
A mobile website opens from search, an advertisement or a shared link. A progressive web app, or PWA, can add an installed experience and selected capabilities on supported devices. An app distributed through the App Store or Google Play has a separate release and version-management process. None of these labels guarantees a good checkout.
| Option | A useful starting point for | What to validate |
|---|---|---|
| Mobile website | Discovery, first purchases and occasional visits | Navigation, checkout, speed and buying without an account |
| PWA | Repeat web use with a home-screen entry point | Installation and required capabilities on actual devices |
| Store-distributed app | A recurring task with a compelling customer benefit | Distribution, integrations, maintenance and active adoption |
Apple lets customers add a website to the iPhone Home Screen as a web app. Home Screen web apps have supported Web Push since iOS 16.4, with permission requested following a direct user action. Notifications are therefore not exclusive to store-distributed apps. See Apple’s instructions and the WebKit documentation.
Our PWA versus native app guide examines capability limits in more detail. Translate those limits into a purchase journey: can a customer recover a basket, open the right order from a notification and recognize information that is no longer current? A polished prototype can look complete while leaving those questions unanswered.
Ask for a demonstration on the phones your customers use. A generic “PWAs support this” checklist is insufficient. Operating system, browser, permission settings and usage conditions all matter. If the proposal depends on specialist hardware or demanding background behavior, a working proof of capability is more useful than another slide comparing frameworks.
04Repeat ordering and B2B can offer a stronger case
A consumables supplier might offer saved lists for each branch. A manager opens the list, adjusts quantities and checks current prices and availability. Business purchasing adds negotiated price lists, invoice terms, approval steps, permissions and budgets. An app may also reduce the work required to retype orders received by email.
This is where much of the complexity lives. A displayed price must match the customer’s contract, availability must reflect stock, and permissions must match the person’s role. Changing an identifier in a request must not let someone order for an unrelated branch. If those rules are missing from the existing commerce API, mobile development cannot make the gap disappear.
Choose one complete journey for the first release, such as reordering with sensible alternatives for unavailable items. Fifty screens are not necessarily more useful than five that remove a frustrating weekly task. Decide between native and shared-code development after that journey is clear. Our native versus cross-platform guide covers that later decision.
05Give loyalty a purpose beyond another discount
Points, vouchers and a digital membership card are easy to put on a feature list. Demonstrating additional profit is harder. If the people installing already intended to buy, the incentive may simply reduce your margin. Part of the budget then rewards the movement of an existing order from the website into another interface.
Look for benefits that solve a real problem: accessible receipts, fast reordering, a service history or an alert when a collection is ready. Design messages around usefulness and an appropriate frequency. A collection update serves a different purpose from a daily sale reminder. Customers should understand what they are enabling and be able to change their preferences.
Download count is a weak primary objective. Track how many invited customers complete a useful first task and return at their next relevant buying opportunity. Daily activity may be irrelevant for a store where supplies are replenished monthly. Our guide to push notifications and customer retention explains how to think about those return visits.
06Fix mobile purchasing before adding another channel
If customers cannot find delivery costs, lose their baskets or fail to complete payment on the mobile site, begin there. An app does not repair poor product information or unreliable stock data. New customers also need a working website before they have any reason to consider an installation.
Walk through a purchase as someone who has never heard of the business: find a product, choose a variant, check availability, understand the final amount, choose delivery and confirm the order. Test a less powerful phone and an interrupted journey. Customers may only discover whether guest checkout is available once they reach the basket. Removing that obstacle can be a smaller investment than opening a new channel.
Treat the improved website as the alternative use of the budget. The same investment might shorten the journey for everyone or provide a more convenient route for a smaller recurring audience. Compare both expected benefits. Mobile-first design helps with the experience; the app proposal also needs a business case.
07Share the commerce system, not just the product pictures
Before commissioning work, map the source of products, prices, stock, orders and customer accounts. The app should use shared business rules. Two independently implemented discount engines will eventually disagree, leaving a customer to ask why the phone charged more than the desktop website.
The interface must handle failures too. A request may arrive twice, a payment response may be delayed, or stock may change during checkout. Retrying must not create a second order. When a connection returns, the customer needs to know whether the purchase already succeeded. Treat these scenarios as core acceptance tests, not finishing touches.
Offline access does not mean that an app can promise a current price or reserve the last item without contacting the server. MDN describes caching selected resources through a service worker. A commerce design must distinguish a saved list from a confirmed order and verify current information before completing the transaction.
08Budget for releases, maintenance and support
The initial scope includes design, integrations, device testing, store-listing preparation and the first release. Ongoing work includes operating-system changes, dependency and payment-component updates, bug fixes, monitoring, customer support and content. A change to the store API may require support for older app versions that customers have not updated.
Apple’s minimum-functionality policy expects value beyond a repackaged website. Putting the store inside an app shell does not guarantee approval. Establish ownership of distribution accounts, signing credentials and the release process before the project begins.
For physical goods, Apple requires payment methods other than In-App Purchase, while Google Play Billing must not be used for those payments. Digital goods follow different rules. Do not add a universal app-store commission to every ecommerce order in the forecast. Check the Apple policy and Google Play policy against the actual offering.
09Calculate the return from additional business
The app earns a return only from value it adds beyond what would happen without it. The following example is not a development quote or a forecast. A business assumes a monthly cost of €2,000, including an allocation of its upfront investment and ongoing operation. Each additional completed order contributes €10 after variable costs.
| Model assumption | Amount | Meaning |
|---|---|---|
| Monthly cost | €2,000 | Illustrative allocation of upfront investment plus operation |
| Contribution per additional order | €10 | After goods, payment costs, delivery subsidies and expected returns |
| Orders needed to cover the cost | 200 | 2,000 / 10, before other demonstrated savings |
| Active app customers | 2,000 | An assumption, not a forecast of installations |
With two thousand active customers, the model needs one additional monthly order for every ten customers on average. Suppose the app processes one thousand orders, but nine hundred and fifty would otherwise have arrived through the website. The increment is only fifty orders, contributing €500. That does not cover the assumed cost.
Add demonstrated labor savings separately, and subtract discounts given specifically to encourage installation. Time saved has a different value when it removes an expense than when it frees capacity for other work. Our software investment ROI guide explains this distinction. Keep the assumptions visible so finance can change them without rebuilding the entire argument.
10Validate demand before committing to the full build
Show customers a concrete task in a prototype. Ask them to repeat an order, adjust a quantity and check the price. “Would you like an app?” often produces polite answers. Watching a real task reveals hesitation, misunderstandings and whether the proposed route is actually better.
Then run a limited pilot with an explicit success condition. Measure invitations, activation, task completion and return use over a suitable buying cycle. Where practical, compare similar customer groups with and without access to the pilot. Simply comparing app users with everyone else introduces selection bias: people who already like the brand are more likely to install.
Write down the stopping conditions before launch as well. Perhaps the improvement over a better website is too small, or the integration requires repairs to the underlying system first. A pilot is not a ceremonial step on an inevitable journey to full development. It is a way to decide whether development deserves to continue.
11Give the supplier a task and an acceptance test
Start the brief with the customer and the job you want to improve. Add the current process, expected benefit, data sources, supported devices and measurement plan. A screen list comes later. The supplier needs to know what determines acceptance: for example, a repeat order must respect the customer’s pricing, permissions and current availability.
Agree responsibility for updates, incident response, access, documentation and handover to another team. Identify who handles a failed payment or an account problem. Downloading the app is not the end of the service. It becomes another part of the experience customers associate with your business.
If you do not yet have a recurring scenario, reliable interfaces and a way to measure incremental value, improve the mobile website. If you have all three, give the first release a narrow, measurable job. An app can become an advantage, but the investment should still make sense when you remove the App Store logo from the presentation.
12Frequently asked questions
At what revenue level does a store need an app?
There is no universal threshold. The relevant inputs are the size of a suitable repeat audience, order contribution, the specific customer benefit and the full cost. A large store with infrequent purchases may have a weaker case than a smaller B2B supplier with regular replenishment.
Can we just wrap the mobile website in an app?
A technical wrapper does not create a reason to use it. Apple also assesses usefulness beyond a repackaged site. Define the customer benefit first, then choose implementation and distribution.
Can a PWA send notifications on an iPhone?
Home Screen web apps have supported Web Push since iOS 16.4, with user permission. Validate the conditions on supported devices. Notifications alone do not automatically justify a separate App Store app.
Can the app replace our mobile website?
Requiring installation at a first visit is usually a poor starting point. The site still supports search, advertising, shared links and customers without the app. Both routes need consistent business rules and shared commerce data.
Do app stores charge a commission on physical goods?
Do not use a universal In-App Purchase percentage in the budget. Apple and Google apply different payment rules to physical goods and digital content. Account separately for the payment provider and the actual operating costs of your setup.
How can we tell whether the app created new sales?
Compare overall buying behavior across suitable customer groups rather than looking only at app revenue. Include all channels, discounts, returns and support. A pilot with comparable groups provides stronger evidence than comparing self-selected installers with everyone else.
13Sources
- Apple: open a website as an iPhone web app
- WebKit: Web Push for iOS and iPadOS
- MDN: offline and background operation
- Apple: App Review Guidelines
- Google Play: payments policy
Documentation checked on October 23, 2026. The decision framework and financial example are editorial analysis. Capability support depends on devices and implementation.