Adobe does not ship a ready-made customer app for Magento stores, so every Magento mobile app comes from one of five routes: improve the mobile storefront and stop there, put the live storefront inside an app with a website to app converter, hire a managed app service, install a mobile app extension with its own native screens, or commission a custom native build on Magento's APIs.
The routes differ most in how much of your store has to be built a second time, and on Magento that is expensive. This guide compares the five, says when SiteTo.App is the wrong choice, then gives you a phone test plan and publishing notes. For the short version, see the Magento to app page.
Does your Magento store need an app?
Magento and Adobe Commerce stores tend to have complicated catalogs: distributors, manufacturers selling direct, parts and supplies businesses, and B2B sellers with negotiated prices. Many of their customers are placing the same kind of order again, and an app earns its place when that task is frequent enough to deserve a shortcut. Ask three questions before you compare vendors:
- What will a customer do in the app every week or month? Reorder consumables, check an order, look up a part by SKU. If you cannot name the task, a fast mobile site is enough.
- Does that task already work on your mobile storefront? An app built from the storefront inherits its speed and its checkout.
- Would a notification help the buyer? A restock alert for something they order regularly is useful. A weekly promotion is easy to mute.
If the answers are weak, spend the budget on the mobile storefront first.
What are the five ways to get a Magento mobile app?
| Route | What customers get | What you maintain | How you pay | Who submits to the stores |
|---|---|---|---|---|
| 1. Better mobile storefront or PWA | A faster site, optionally installable from the browser | Your storefront | Development time | Nobody; there is no store listing |
| 2. Website to app converter (SiteTo.App) | An app under your name that loads your live storefront in a native shell | Your storefront | Once per platform: $29 Android, $79 iOS, $99 both | You, from your own accounts |
| 3. Managed app service | A similar app, with a team handling setup, QA and submission | Your storefront | A monthly or annual fee | Usually the service |
| 4. Mobile app extension | A native app with the vendor's catalog, cart and checkout screens | Your storefront, a connector module and the app design | Licence or subscription, plus customization | You or the vendor |
| 5. Custom native build | Whatever you specify | Your storefront and a separate app codebase | Project fee plus ongoing maintenance | You or the agency |
Every route with a store listing also needs developer accounts: the Apple Developer Program at $99 a year and Google Play at $25 once, paid to Apple and Google directly.
1. A better mobile storefront or a PWA
Sometimes the right answer is no app. If the default Luma theme makes your store slow on phones, a lighter front end does more for customers than an icon. Hyvä Theme has been free and open source since November 2025, and for Adobe Commerce merchants Adobe now documents its own Commerce Storefront, which uses ready-made drop-in components. PWA Studio remains available for headless progressive web apps.
A PWA can be added to a home screen from the browser, but it does not appear in the App Store, and web push on iPhone only works after the customer installs it that way. Our guide to PWA vs. native vs. WebView covers the differences.
2. A website to app converter
A converter takes your public storefront URL and places it inside an app. With SiteTo.App the app is a native shell around your live website: your icon and launch screen, a native header with your logo, a side menu, bottom tabs, swipe-back, pull-to-refresh and optional push notifications through your own Firebase project. The pages inside are your Magento pages, loaded in a WebView.
Nothing is installed on your Magento server and no API credentials are involved. Customer group prices, shared catalogs, shipping rules and every extension that renders on your mobile site carry over because they are the same pages. For the same reason, the app is as good as your mobile storefront and no better.
3. A managed app service
Managed services use the same WebView approach for your pages and add a team that configures, tests, submits and maintains the app, often with extras such as custom native screens. You pay a recurring fee for that team. If nobody in your business has time to own an app, this is a legitimate choice. We compare one such service in SiteTo.App vs. MobiLoud.
4. A mobile app extension for Magento
The Adobe Commerce Marketplace and independent vendors sell mobile app extensions for Magento 2. The usual design is a connector module installed on your store plus a pre-built native iOS and Android app that reads your catalog, cart and customer data through it. You get native product lists and product pages.
Before you buy, ask which of your customizations the app supports, who keeps the connector compatible through Magento upgrades, and whose developer accounts hold the listings. Support for custom options, B2B features and third-party payment methods varies by vendor.
5. A custom native build
Magento's GraphQL API is designed for headless storefronts and mobile clients, and an agency can build any app on top of it. This is the only route for features a website cannot provide: barcode scanning in a warehouse, offline ordering for field sales reps, Bluetooth devices, AR or background processing.
It is also a second codebase to retest whenever Magento is patched, so budget for maintenance as well as the build.
Why does customization decide the route on Magento?
On Magento, the logic that matters often sits in PHP modules and theme templates: which customers see which catalog, what a customer group pays, how freight is quoted, which payment methods appear for which basket. A native app cannot read templates. It asks Magento through REST or GraphQL, and an extension that changes the storefront does not always expose the same behavior through the API. Each gap becomes a decision: pay to build API support, accept a difference between app and site, or leave the feature out.
Routes 2 and 3 avoid the question by reusing the storefront. Routes 4 and 5 answer it one customization at a time. Before you ask for quotes, list the extensions and custom modules a customer touches between sign-in and order confirmation. A short list makes a native route realistic. A long one is an argument for reusing what you have.
Which route fits which Magento store?
| Your situation | Route to look at first |
|---|---|
| Your mobile storefront is slow or awkward to use | Fix the storefront first, then decide |
| Your mobile storefront takes orders well, and you want your own listing without a monthly app fee | A website to app converter |
| B2B buyers sign in to reorder at negotiated prices | A converter, since prices and catalogs stay server-side |
| You want an app, but nobody on your team can own setup and store submission | A managed app service |
| Your catalog and checkout are close to standard, and you want native product screens | A mobile app extension |
| You need scanning, offline ordering or other device features | Custom native build |
| You want push campaigns triggered by segments or abandoned carts | A managed service, an extension with that feature, or a custom build |
When is SiteTo.App the wrong choice for a Magento store?
- Your mobile storefront is slow. Fix caching and the theme first, because the app loads the same pages.
- You want screens that do not exist on your website. SiteTo.App adds native navigation around your pages. It does not redesign them.
- You need targeted or automated push. Notifications are sent by hand from the dashboard to everyone who opted in. There are no segments or scheduling yet, and Magento events cannot trigger them.
- Your buyers work offline or scan barcodes. The app needs a connection to load your store, and it does not add device features such as scanning or Bluetooth.
- You want someone else to handle store review. You submit from your own Apple and Google accounts.
How do Magento features behave inside a WebView app?
A WebView uses the same browser engine as Safari or Chrome, so most of a Magento storefront behaves as it does in a phone browser. The exceptions are predictable.
Sessions. Adobe's documentation on customer session lifetime gives the default cookie lifetime as 3,600 seconds, and a customer whose session cookie expires is signed out. App users expect to stay signed in, so this default deserves a deliberate decision. The setting is under Stores > Configuration > General > Web > Default Cookie Settings. The server session is a separate timeout, and Adobe notes there is no Admin setting for it, so your developer changes it in the PHP configuration on the server. A longer session is a security trade-off, so agree it together. The persistent cart keeps the cart available on that device after a session ends when the customer ticks Remember Me.
Cached pages. With full-page caching, Magento fills in the mini cart and customer name after the page loads, using the browser's local storage. This works in a WebView, but check the cart count after an add to cart, after checkout and after signing out.
Payments. Card fields from your gateway are web forms. A 3-D Secure challenge, PayPal, pay-later providers and bank redirects all leave your page and must come back to the order success page. Apple Pay and Google Pay depend on what the device and the embedded browser expose. Test every method on both platforms.
Sign-in. Email and password is the dependable path, and storefront reCAPTCHA normally loads as on mobile web. Google's OAuth policy does not allow its sign-in screen inside embedded web views, so a social login extension's Google button can fail in an app while working in the browser.
B2B pages. Company accounts, shared catalogs, Quick Order, requisition lists and negotiable quotes in Adobe Commerce B2B are storefront pages, so they open in the app like any other. File actions are the part to test: uploading a CSV to Quick Order and downloading an invoice PDF.
Store views. The app opens one URL. If store views use separate domains or store codes in the path, decide where the app starts and keep the store and currency switchers reachable.
How do you test a Magento store as an app, step by step?
Set aside about ninety minutes, an iPhone and an Android phone if you can, and a test account for each customer group. The preview is free and needs no card, so run the whole plan before you pay.
Step 1: Check the storefront on a phone
Open your production store in Safari and in Chrome on a phone. Load the home page, a large category and a product page on mobile data. Anything slow or awkward here will be the same in the app.
Step 2: Create the preview
Paste your storefront address into SiteTo.App. Use the production URL, since a staging site behind a VPN or an IP allowlist will not load on your phone. Set the app name, icon and launch screen, then build the tabs around what returning buyers do. A typical set is Home, Search, Cart, Orders and Account, and a B2B store might swap Home for Quick Order. Copy each link from your live site, because URL rewrites change Magento's default paths. Magento's search results URL expects a search term, so point the Search tab at the advanced search page or at a page where your search box is easy to reach. Scan the code to open the app on your phone.
Step 3: Test sign-in and sessions
Sign in with a retail account and open the account dashboard. Close the preview completely, reopen it and confirm you are still signed in. Then leave it for more than an hour and try again. Request a password reset, since the emailed link opens outside the app. Tap every social login button you offer.
Step 4: Test prices and catalog by customer group
Sign in as a wholesale or company account and compare three or four products against the website for price and tier prices. If you use shared catalogs, confirm a product outside that company's catalog stays hidden.
Step 5: Test product types, search and filters
Add a configurable product, a bundle and any product with custom options to the cart. Search by SKU. On a large category, apply several layered navigation filters, open a product and swipe back to check the filters are still applied.
Step 6: Place real orders
Complete an order with each payment method, including a card that triggers 3-D Secure and every method that redirects. A low-value real order that you refund afterwards is the most reliable test. Confirm you reach the success page inside the app. For B2B, also order on account and reorder from order history.
Step 7: Check overlaps and exits
Look for your site header showing under the native header and a chat bubble or cookie notice covering a tab. SiteTo.App can hide site elements with scripts that run only in the app. Open an external link, a PDF and a phone number, and confirm there is a way back.
Problems in the page are fixed in Magento, and problems with navigation are fixed in the SiteTo.App settings. If a hand-off you depend on fails and has no acceptable fallback, choose another route. You have spent nothing to find out.
What does it cost, and who owns the app?
SiteTo.App charges per platform, once: $29 for Android, $79 for iOS or $99 when you buy both together. There is no SiteTo.App subscription. Later rebuilds, for example to change the icon, are quoted separately. Everyday changes in Magento need no rebuild. The pricing page has the details, and the cost guide compares the wider market.
Because the apps are published from your own developer accounts, the listings, ratings and reviews are yours. For the other routes, ask each vendor for the total over three years, including the work to keep pace with Magento upgrades.
How do you publish a Magento-based app to the App Store and Google Play?
The create and publish guide walks through the full sequence. A few points are specific to Magento stores.
iOS. Your build is signed and uploaded to TestFlight in your own Apple account, so you do not need a Mac or Xcode. Repeat the test plan on the TestFlight build before you submit. See converting a website to an iOS app without Xcode.
Android. You receive an AAB for Google Play, or an APK for direct installs. Google asks new personal developer accounts to run a closed test before production release, so allow time for that.
Reviewer access. If your catalog or prices are hidden from guests, reviewers see a login wall. Create a demo customer in a suitable group and put its credentials in the review notes.
Account deletion. Apple requires apps that support account creation to offer account deletion inside the app. A default Magento customer dashboard has no delete option, so add a request form or an extension and link it from the account area.
Payments for goods. Physical products bought through your Magento checkout are the straightforward case. If you sell downloadable products or digital subscriptions, read section 3.1 of the App Store Review Guidelines first. SiteTo.App uses your checkout and does not add Apple In-App Purchase.
Apple and Google make the approval decision, and nobody can promise the outcome. Apple can reject apps that add little beyond a website under Guideline 4.2. Native navigation, push and a clear repeat task all help, and the publishing guide covers review in more depth.
Frequently asked questions
Does Magento have its own mobile app for customers?
No. Adobe provides APIs and storefront tooling, but not a ready-made customer app for your store. You get one through a website to app converter, a managed service, a mobile app extension or a custom build.
Can I turn a Magento 2 store into an app without installing a module?
Yes. A website to app converter such as SiteTo.App works from your public storefront URL. Nothing is installed on the Magento server, and the REST and GraphQL APIs are not used. Mobile app extensions take the opposite approach and require a connector module.
Do I need a new build when I upgrade Magento or change the theme?
No. The app loads whatever your storefront serves, so upgrades, theme changes and new extensions appear the next time a page loads. Update tab links if URLs moved. Changing the icon or launch screen may need a new build.
Next step
List the extensions and custom modules a customer touches between sign-in and order confirmation. If the list is long and your mobile storefront already takes orders well, preview it as an app for free and run the seven steps above. The Magento to app page has the short checklist to keep beside you while you test.
See your website as an app
Customize the experience and preview it before choosing a platform.
Build your preview
