Adobe Commerce development
Storefront design
Performance & SEO
AI & agentic commerce
Release tracker
For most Magento stores, a fast mobile website or progressive web app (PWA) should come before a native app. Build a native app when you have a loyal base of frequent buyers who would install it, a feature that needs the device (rich push campaigns, barcode scanning, offline catalogs, in-store features), and a team that can run two release cycles. Ecommerce mobile app development makes sense as a retention channel on top of a strong mobile site, not as a replacement for one.
Below is a decision matrix across the factors that usually decide the question, and the realistic Adobe Commerce routes for each option.
What each option actually is
- Mobile website: your normal storefront (Luma, Hyvä, Breeze or headless) designed for small screens. Every visitor gets it without installing anything.
- PWA: a website that adds a web app manifest and a service worker, so it can be installed to the home screen, cache assets, work with poor connectivity and, with limits, send push notifications. A PWA is still served from the web.
- Native or cross-platform app: an app built for iOS and Android (natively, or with React Native or Flutter), distributed through the App Store and Google Play, talking to Magento through its APIs.
Decision matrix: mobile app vs PWA
| Factor | PWA or mobile web | Native or cross-platform app |
|---|---|---|
| Reach | Anyone with a browser; indexed by search engines | Only people who install it |
| Push notifications | Supported on Android and desktop browsers; on iOS and iPadOS 16.4 and later, only for web apps added to the Home Screen, after a user gesture | Full push on both platforms, with richer targeting and higher visibility |
| Offline use | Service worker caching of pages and assets; checkout still needs a connection | Full control over local data, such as saved catalogs or order drafts |
| App store presence | Not required; discovery through search and links | Required; subject to store review and guidelines |
| Update speed | Deploy any time, users get it on next visit | Store review for each release; users may run old versions |
| Device features | Camera, location, payments via the browser; some APIs are limited on iOS | Full access to device APIs, biometrics, background tasks |
| Build and run effort | One codebase; part of the storefront work | Separate codebase, two store listings, separate QA and release process |
| Best for | Acquisition, SEO, most shoppers | Frequent repeat buyers, loyalty, in-store or field use |
How to read the matrix
Score each row for your business. If push and device features matter little, a well-built mobile site or PWA wins on reach and cost. If your best customers order weekly and respond to push, an app can earn its keep. Many stores do both: the website for everyone, and an app for the loyal segment.
Two facts that change the decision
iOS supports web push, with conditions
WebKit added Web Push for Home Screen web apps in iOS and iPadOS 16.4. The permission request must come from a direct user interaction, such as tapping a subscribe button, and the site must first be added to the Home Screen. In practice, far fewer iPhone users will opt in to web push than to app notifications, so treat PWA push on iOS as a bonus rather than a channel you plan around.
App stores reject thin wrappers
Apple's App Store Review Guideline 4.2 (Minimum Functionality) says an app should offer features, content and UI that go beyond a repackaged website. Wrapping your mobile site in a web view is a risky shortcut. If you build an app, it needs app-specific value: saved lists, scanning, account features, offers or in-store tools.
Adobe Commerce routes for each option
| Option | Typical Adobe Commerce route | Notes |
|---|---|---|
| Fast mobile site | Hyvä or Breeze theme, or an optimized Luma theme | Lowest effort; keeps extension compatibility; add a manifest and service worker if you want installability |
| Headless PWA | Custom Next.js or similar front end, Alokai, ScandiPWA, or PWA Studio on existing projects | Uses GraphQL; you own the front end and its upkeep |
| Adobe Storefront | Adobe Commerce Storefront on Edge Delivery Services with drop-in components | Adobe's own route; licence and backend requirements apply |
| Native or cross-platform app | React Native, Flutter, Swift or Kotlin app calling Magento GraphQL and REST APIs | Needs app-specific features, push service and store accounts |
The app and the headless PWA both depend on Magento's APIs. GraphQL is usually the better fit for storefront and app screens, and REST for back-office and integration tasks; our guide to Magento GraphQL vs REST explains the difference. For the architecture behind a decoupled front end, see headless ecommerce explained.
If you are considering Adobe's PWA Studio specifically, read our review of PWA Studio in 2026 and its alternatives before committing, because Adobe now points new storefront projects to Edge Delivery Services.
What an app needs beyond screens
Teams often budget for the screens and forget the plumbing. A store app usually needs:
- Customer authentication that shares accounts and carts with the website
- A push service (Apple Push Notification service and Firebase Cloud Messaging) plus a way for marketing to segment and schedule messages
- Deep links so emails and ads open the right screen
- Payment through the same gateway as the site, with Apple Pay and Google Pay where available
- Analytics that match web tracking, so app revenue is not double counted
- A release process, crash reporting and support for older app versions still in use
- Store listing, privacy labels and review compliance for both stores
Each of these is ongoing work. That is the real cost difference between an app and a PWA: not the first build, but the second codebase you maintain for years.
A sensible order of work
- Fix mobile web first. Meet Core Web Vitals "good" thresholds (LCP 2.5 s or less, INP 200 ms or less, CLS 0.1 or less) and simplify the mobile checkout.
- Add PWA features where they help. Installability and offline fallback pages are low effort on a modern theme.
- Measure repeat behavior. If a meaningful group of customers orders often from mobile, test whether they would install an app, for example with a short survey or a waiting list.
- Build the app around app-only value. Start with the features the website cannot do well, not a copy of every page.
Frequently asked questions
Is a PWA cheaper than a native app?
Usually, because it is one codebase delivered through the web. The bigger saving is ongoing: no store releases and no separate app QA.
Can a PWA be listed in app stores?
Google documents how to publish a PWA on Google Play by packaging it as a Trusted Web Activity, and the app then goes through Play's normal review and policies. Apple's App Store Review Guidelines (section 4.2, Minimum Functionality) ask for features and UI that go beyond a repackaged website, so a simple wrapper risks rejection.
Does Magento have an official mobile app builder?
No. Apps are built with standard mobile frameworks against Magento's GraphQL and REST APIs, or with third-party app builder services.
Next step
If the matrix points to a better mobile web experience, Mistri's headless and PWA storefront design service covers that work. If it points to an app or a companion tool for staff or trade customers, our web application development team builds the API layer and front ends to support it.
Sources
Web Push for Web Apps on iOS and iPadOS (WebKit blog); App Store Review Guidelines (Apple Developer); Backend options for Commerce Storefront (Adobe Experience League); Web Vitals (web.dev); Adding your Progressive Web App to Google Play (Google for Developers).
