Every quarter, a retail board asks the same question: “Should we have our own app?” The honest answer in 2026 is that most brands should not, and the ones that should can usually name the reason in a single sentence. A shopping app is no longer a status symbol or a checkbox for being taken seriously. It is a recurring cost center with a specific job, and if that job is not worth roughly six figures a year in build plus maintenance, the app is a distraction from the work that actually moves revenue.
This piece treats the app decision the way a CFO treats any capital request: what does it cost, what does it return, and what is the cheaper alternative that captures 80 percent of the upside. The short version is that d2c mobile commerce has split into two camps, and the dividing line is repeat-purchase frequency, not brand size. We will work through the build and maintenance economics, the retention math that justifies a native build, the progressive web app alternative that now does most of the same work, and a decision framework you can run in an afternoon. None of it lives in isolation; channel choice sits inside a wider strategy, and our guide to selling on global e-commerce marketplaces is the map for how an app fits alongside every other surface a brand sells through.
The framing matters because the app question is usually asked backward. Teams start with “what should our app do” when the prior question is “does an app earn a place in the budget at all.” In 2026 the default answer has flipped: a decade ago a serious retailer was expected to ship one, and today a serious retailer is expected to justify one. That shift tracks the maturation of mobile web, the rising cost of app-store visibility, and the hard data showing that install friction quietly caps how much value any app can return. Treat the app as the conclusion of an analysis, not the premise of one.
- Most brands do not need an app. If a customer buys from you fewer than three times a year, a fast mobile site captures nearly all the value an app would.
- Apps win on frequency and loyalty. Grocery, beauty replenishment, quick-service, and subscription retail see real lift from push notifications and saved payment friction.
- The real cost is maintenance, not build. Expect 30 to 50 percent of the original build budget every year just to keep an app alive across iOS and Android updates.
- Install friction kills the funnel. Asking a first-time visitor to download an app before buying loses most of them; the app should serve customers you already won.
- Progressive web apps close much of the gap. A well-built PWA delivers home-screen install, offline browsing, and push on Android without app-store gatekeeping.
What does a shopping app actually cost to run?
Start with the number most vendors bury: an app is a subscription you pay yourself, forever. A competent native build for iOS and Android lands between $80,000 and $250,000 depending on whether you reuse a framework like React Native or build twice in Swift and Kotlin. That figure is the cheap part. The expensive part is the years that follow, because Apple and Google ship breaking platform changes on their schedule, not yours.
Budget realistically for ongoing spend. A retailer running a mid-complexity app should plan for the line items below, and these recur whether or not you ship a single new feature.
| Cost line | Typical annual range | What drives it |
|---|---|---|
| Maintenance and OS compatibility | $30,000 to $90,000 | iOS and Android version churn, SDK deprecations, crash fixes |
| Hosting and push infrastructure | $6,000 to $40,000 | API traffic, notification volume, analytics events |
| App-store fees on in-app sales | 15 to 30 percent of digital goods | Apple and Google commission (physical goods are exempt) |
| Feature roadmap and QA | $40,000 to $150,000 | New flows, A/B tests, regression testing on real devices |
| ASO and install marketing | $10,000 to $100,000+ | Cost per install, store listing optimization, retargeting |
One detail trips up first-timers: Apple and Google take a commission only on digital goods sold inside the app. Physical retail orders processed through a normal payment provider are exempt, which is why a clothing brand can sell freely in-app while a digital-content brand cannot. If your catalog is physical product, the commission fear is mostly misplaced. If you sell subscriptions or unlockable content, model the cut carefully before you commit.
The maintenance line is the one that destroys budgets, so it deserves a concrete picture. Apple ships a major iOS version every September and deprecates older APIs on a rolling basis; Google does the same with Android, and both raise the minimum SDK target apps must hit to stay in their stores. An app left untouched for a year will start throwing crashes on new devices, lose access to payment-sheet APIs, and eventually fail a store-compliance review. That is why a credible budget pairs every build dollar with a multi-year run commitment, and why “we will maintain it in-house” only works if you actually keep a mobile engineer on payroll rather than borrowing one between other projects.
There is also a hidden cost that never appears on a vendor quote: the opportunity cost of attention. Every hour an engineering team spends keeping two native codebases compliant is an hour not spent on the storefront that serves your entire audience. For a brand whose app reaches the most loyal 5 percent of customers, pouring senior engineering time into it can starve the experience the other 95 percent actually use. The honest comparison is not app versus nothing; it is app versus the best alternative use of the same money and the same people.
When does an app actually earn its keep?
The app pays off when it changes behavior you can measure, and the single strongest predictor is purchase frequency. A customer who buys monthly has a reason to keep an icon on their home screen. A customer who buys a mattress once every eight years does not, and no amount of design polish changes that math.
Here is the order of operations a retail team should run before approving a build, from cheapest signal to most expensive commitment.
- Measure existing mobile-web repeat rate. Pull the share of revenue from customers buying three or more times a year. Under 20 percent, an app rarely clears its cost.
- Estimate push-driven incremental revenue. Apps live or die on notifications; if you have nothing timely and personal to send, you have no engine.
- Price the build and three years of maintenance together. Never approve a build budget without the multi-year run cost attached.
- Pilot with a PWA first. Ship installable mobile web, turn on web push, and watch whether engaged users opt in before you fund a native app.
- Commit only if the pilot shows lift. Let real opt-in and repeat-purchase data, not boardroom intuition, trigger the native investment.
The brands that win with apps share a profile: high frequency, a loyalty program with real stakes, and saved-payment convenience that removes friction on every reorder. Low-price, high-velocity players have pushed this hardest, and the playbook is visible in how Temu rewrote the rules of low-price e-commerce by treating the app as a daily-engagement surface rather than a storefront. That model assumes you have something worth opening daily. Most specialty retailers do not, and pretending otherwise produces an app nobody launches twice.
It helps to put the segments side by side, because the answer is rarely uniform across a catalog. A useful exercise is to score each product line on frequency and emotional engagement, then ask whether the app changes anything for that line specifically.
| Retail segment | Typical app fit | Why |
|---|---|---|
| Grocery and replenishment | Strong | Weekly reorders, saved lists, and push on restock drive real frequency |
| Beauty and personal care | Strong | Subscription refills, loyalty tiers, and routine reminders fit push well |
| Quick-service and food | Strong | Order-ahead, rewards, and location features genuinely speed the visit |
| Apparel and accessories | Mixed | Works for high-frequency fast fashion, weak for occasional premium buys |
| Furniture and big-ticket | Weak | Multi-year purchase cycles give no reason to keep the app installed |
| Specialty and considered goods | Weak | Low frequency means the install never earns back its acquisition cost |
Where does the real revenue lift come from?
When an app does pay back, the return almost always traces to three mechanisms, and a board should be able to point at which one applies before funding anything. The first is push notifications, which are the only owned, free, instant channel that lands on a customer’s lock screen without an algorithm or an ad auction in the way. A retailer with timely, personal triggers (a restock, a price drop on a saved item, an order ready for pickup) can drive incremental sessions that email and SMS cannot match on immediacy. A retailer with nothing better to send than “we miss you” will train customers to mute and then uninstall.
The second mechanism is saved-payment friction removal. An app that keeps a customer logged in with a stored card and a biometric confirmation turns a five-step checkout into a two-tap reorder, and on a high-frequency catalog that compression is worth real money over a year. The third is first-party data and loyalty: an app gives a clean, persistent identity that survives cookie loss and browser changes, which lets a loyalty program actually track behavior across sessions. In a privacy-tightened landscape, that durability is a genuine advantage, but only for a brand whose loyalty program has stakes worth tracking.
Notice what is missing from that list: “customers expect it” and “it looks professional.” Neither shows up in revenue. The discipline here is the same one that separates a real cost analysis from a vanity project, and it rewards teams who insist on naming the mechanism before approving the spend. If you cannot point to push, payment friction, or loyalty data as the specific lever, the app does not have a job.
What can mobile web do that closes the gap?
The case against most apps rests on a simple fact: the modern mobile web does almost everything an app does, without the app store standing between you and the customer. A progressive web app installs to the home screen, runs full screen, caches content for offline browsing, and supports push notifications on Android. For a brand whose differentiator is product and price rather than a real-time logistics feed, that is enough.
Speed is the lever that matters most, and it is the one apps were historically built to solve. A checkout that loads in under two seconds on a mid-range Android phone converts dramatically better than one that stalls, and that improvement is available to anyone willing to fix images, scripts, and payment-sheet friction. The discipline mirrors fulfillment planning, where small per-order frictions compound into real cost; the same attention to documentation and edge cases that defines good shipping incoterms for retail buyers applies to a checkout flow, where every unnecessary tap is a leak.
For platform teams, the calculus often favors strengthening the existing storefront over forking effort into a second codebase. A mature stack already handles payments, tax, and inventory, and bolting on PWA behavior is a configuration project rather than a rebuild. Teams running on open platforms find this especially clean, as covered in our look at why WooCommerce remains a serious option for SMB stores in 2026, where PWA layers ship as plugins instead of multi-quarter native projects. Independent UX research from the Nielsen Norman Group has consistently found that mobile users abandon flows over friction, not over the absence of a native wrapper, which is the entire argument in one sentence.
Common mistakes retailers make with shopping apps
The pattern of failed retail apps is remarkably consistent, and almost every one is a strategy error rather than a technical one. Avoiding these saves both the budget and the post-mortem.
- Building an app to acquire customers. Apps retain existing customers; they are a terrible top-of-funnel tool because the install step filters out first-time buyers.
- Treating the app as a clone of the website. If the app offers nothing the mobile site lacks, customers default to the browser and the app rots unused.
- Ignoring the maintenance cliff. Funding the build but not the multi-year run cost produces a crashing, outdated app within 18 months.
- Spamming push notifications. Over-notifying triggers uninstalls and OS-level muting; one irrelevant blast can erase a quarter of engagement.
- Skipping the PWA test. Committing to native before validating opt-in demand on web wastes the cheapest learning available.
- Misjudging the commission. Assuming Apple and Google take a cut of physical-goods sales, then over-engineering around a fee that does not apply.
Frequently asked questions
Does a shopping app improve SEO or organic discovery?
No, and this is a frequent misunderstanding. App content lives inside the app store, not on the open web, so it does not contribute to your search ranking the way a fast, crawlable mobile site does. Discovery for apps happens through app-store optimization and paid installs, which is a separate marketing channel with its own cost. If organic growth is the goal, every dollar belongs in your mobile web experience and content, not in a native build that search engines cannot index.
How many of my customers will actually install the app?
Plan for a small fraction of your most loyal buyers, not your general audience. Typical retail apps see install rates in the low single digits of total visitors, and even among repeat customers, opt-in rarely exceeds 20 to 30 percent without an aggressive incentive. This is exactly why an app should target retention: it concentrates investment on the customers who already buy often, rather than chasing the much larger group who will never download anything to make a purchase.
What is the difference between a PWA and a native app for retail?
A progressive web app runs in the browser engine but installs to the home screen, works offline, and supports push on Android, with no app-store approval needed. A native app is a separate program built specifically for iOS or Android, with full access to device hardware and smoother performance for heavy interactions. For most retail, where the job is browsing and checkout, a PWA captures the bulk of the experience at a fraction of the build and maintenance cost.
Do Apple and Google take a cut of my retail sales in the app?
Not for physical goods. Apple and Google charge their 15 to 30 percent commission only on digital goods and in-app subscriptions, and physical products shipped to a customer are explicitly exempt when processed through a standard payment provider. A clothing, food, or homewares brand can sell freely in its app without surrendering a platform cut. The commission only becomes a real factor if your catalog includes downloadable content, memberships, or other digital items.
How long before an unmaintained app stops working?
Faster than most teams expect, usually inside 12 to 18 months. Apple and Google ship operating-system updates and SDK deprecations on a regular cadence, and an app that is not actively maintained will start crashing, fail store-compliance checks, and eventually get pulled from the store entirely. This is why the maintenance budget is not optional: skipping it does not save money, it just delays the cost while degrading the customer experience and your brand in the process.
Should a new D2C brand build an app at launch?
Almost never. A brand at launch has no repeat-purchase data, no loyal base to retain, and no proof that customers want a daily touchpoint, which means an app would be funded on hope rather than evidence. The right sequence is to grow on a fast mobile site, watch which customers return, and only consider an app once a meaningful repeat-purchase cohort exists. Building before that point spends scarce early capital on infrastructure the business has not yet earned.
What is next
The practical move for 2026 is to stop asking whether you need an app and start measuring whether your repeat-purchase cohort is large enough to fund one; if it is not, redirect that budget into mobile-web speed and a PWA pilot that you can ship this quarter. Track web-push opt-in and three-times-a-year buyers for two quarters before any native commitment, and let that data make the call. For the wider context on where channels and frequency intersect, our global e-commerce marketplace guide maps how the same discipline applies across every selling surface a retail brand operates.