How to build a Magento 2 mobile app from Adobe Commerce

Your Adobe Commerce storefront already contains the expensive parts of a commerce app: catalog rules, customer accounts, search, promotions, inventory, tax, shipping, and checkout. A Magento mobile app does not have to duplicate all of that work. You can use the storefront you already operate as the interface of an iOS and Android app, then add the native features that give customers a reason to install it.

The choice matters because Adobe Commerce is rarely a plain storefront. It usually carries a custom theme, payment modules, analytics tags, consent tools, and extensions that took years to fit together. A mobile approach that starts from the live website preserves more of that investment than one that builds a separate frontend against the Commerce APIs.

Try it for free

Build an app from your Adobe Commerce URL

Can Adobe Commerce or Magento become a mobile app?

Yes. Adobe Commerce, formerly Magento Commerce, and Magento Open Source both deliver shopper experiences through a web storefront. That storefront can become an app in three ways:

1. Wrap the live storefront: Median displays your production store inside a native iOS and Android shell. Catalog, account, cart, checkout, and extension behavior continue to come from the website. Median adds native features through the Median JavaScript Bridge and Native Plugin Library.

2. Build a headless or PWA storefront: Adobe PWA Studio provides React tools and libraries for a storefront powered by Adobe Commerce or Magento Open Source. It communicates with Commerce through GraphQL and REST, so your team develops, hosts, and maintains a second frontend before deciding how to distribute it as an app.

3. Build a custom native app: An iOS and Android team can recreate the shopper experience against Adobe Commerce GraphQL and REST APIs. This gives you control over every screen, but it also makes your app team responsible for authentication, product types, carts, checkout, payments, and every custom feature that the web storefront already handles.

Adobe Developer App Builder causes some naming confusion here. It is a framework for web applications, microservices, events, and integrations that extend Adobe products. Adobe documents App Builder as an extensibility option for Commerce, not a consumer mobile app builder that packages a storefront for the Apple App Store and Google Play.

A storefront wrapper, PWA, and custom native app solve different problems

Choose a live storefront wrapper when your mobile website already completes the shopping journey and you want app store distribution, native features, and a shorter maintenance list. This web to app approach keeps the browser storefront as the source of truth. Product, price, promotion, theme, and extension updates reach the app when they reach the website, without rebuilding a parallel catalog interface.

Choose PWA Studio when you are already planning a headless storefront or need to replace the existing theme across web and mobile. Adobe's PWA Studio architecture treats the storefront and Commerce backend as separate applications, with GraphQL preferred for store behavior and REST used where API coverage is missing. That separation can be useful, but it is still a software project. Adobe's own Commerce feature coverage shows that some product types, B2B features, and frontend extensions need API work or custom implementation.

Choose a custom native build when native screens, substantial offline behavior, or device-level workflows define the product. Adobe Commerce can support that architecture. Its GraphQL APIs cover products, customer data, anonymous carts, signed-in carts, store configuration, and checkout operations. Your mobile team still has to turn those APIs into two complete, secure shopping experiences and keep them compatible with backend changes.

A Magento mobile app builder extension sits between wrapping the live storefront and building a custom native app. These products commonly install a Commerce module and feed a vendor's mobile template. They can work when the template covers your store and the vendor supports your extensions. Ask how custom product types, promotions, payment methods, B2B features, and future Commerce upgrades reach the app. A low setup price loses its appeal if each storefront customization becomes a separate mobile change request.

Get your Adobe Commerce storefront ready for a mobile app

The production URL is the starting point, but a responsive page is only the first check. Commerce stores have several places where a flow that works in Safari or Chrome can behave differently inside an app.

Test the storefront, not just the home page

Run the complete purchase journey on narrow screens before creating builds. Include search, category filters, configurable products, bundled products, custom options, cart edits, coupons, shipping estimates, tax, checkout, order confirmation, and the customer account area. Give B2B a separate pass that covers company accounts, requisition lists, shared catalogs, negotiable quotes, purchase orders, roles, and approval states.

Fix mobile web problems at the storefront layer. Wrapping a slow category page or an inaccessible checkout does not make it faster or easier to use. It gives the same problem an app icon.

Decide which domains stay inside the app

Same-domain links normally remain in the main WebView. Payment providers, identity providers, help centers, shipment tracking sites, and social links may need an in-app browser or the device browser. Median's Link Behavior rules let you choose internal, in-app browser, or external handling for each pattern.

Map this before testing payments. A checkout can leave your store for 3-D Secure, PayPal, Klarna, Afterpay, or another provider and then return to a success or failure URL. Confirm that the return lands in the app with the same cart and customer session. If the return opens in the device browser instead, the shopper pays at the provider and comes back to an app that never saw the order complete.

Check Content Security Policy on checkout pages

Adobe Commerce and Magento Open Source 2.4.7 and later use restrictive Content Security Policy on payment pages by default. Adobe's CSP documentation explains how to whitelist exact script, connection, frame, and form sources through a custom module.

Do not disable CSP to make an app-only script or payment integration run. Test with the browser console open, identify the blocked source, and whitelist only the policy and domain the feature needs. Repeat this check after Commerce and payment extension upgrades because checkout is where CSP differences become visible first.

Separate app-specific UI without confusing your cache

The Median app can append a custom value to its user agent, and your storefront can use it to hide a desktop header, show an app-only promotion, or reserve space for native navigation. Median also supports custom JavaScript that runs only inside the app.

If you render different server-side HTML for the app, include that variation in your Fastly or Varnish cache strategy. Otherwise, an app request can warm the cache with an app-only page that a mobile browser receives later. Client-side changes based on the injected bridge or a carefully configured cache key avoid that collision. Test logged-out pages, logged-in pages, and every store view after the change.

Audit sign-in and account management

Test customer login, password reset, social login, passkeys, multi-factor authentication, and session expiry on both platforms. OAuth providers may reject embedded browsers or require mobile redirect URLs. Route those providers through the appropriate browser mode, then verify that the authenticated session returns to the main app.

Apple also requires in-app account deletion when an app supports account creation. Add a clear deletion entry to the customer account area before review. If your store offers Google, Facebook, Amazon, or another third-party login for the primary account, check Apple's current login-service requirements as part of the same audit.

How to build a Magento mobile app with Median

The conversion uses your storefront URL, so it works with a traditional Luma or Hyvä theme, a custom responsive theme, or a deployed PWA storefront. Compatibility depends on the actual shopper flows, not the name of the frontend.

Step 1. Create the app from the production storefront

Open the Median App Studio, enter the public production URL, and set the app name. This website to app conversion should use the exact domain customers use to shop, including the correct store view if your deployment uses separate domains. Avoid an Admin preview, staging site, or URL protected by a developer password.

The browser preview is useful for initial layout work. Treat it as a preview, not proof that checkout, camera access, push notifications, or authentication will work on a phone.

Step 2. Make the storefront aware of the app

Use Median's app detection options to distinguish app traffic from ordinary mobile browser traffic. The custom user agent works on the server and client. The JavaScript Bridge is better when a browser should render the same page until native controls are ready.

Keep the changes small at first. Hide duplicate browser navigation, account for the iPhone safe area, prevent unsupported popups, and make the back button predictable on Android. Preserve normal web behavior for customers who never install the app.

Step 3. Configure checkout and link handling

Keep storefront, cart, account, and checkout routes in the main WebView. Add specific rules for each external payment or identity domain. Use the in-app browser when the shopper needs a visible browser context and an easy return to the app. Use the external browser when the provider requires it or when another installed app should handle the link.

Some payment libraries need a constrained web context. Median's Secure Modal provides a WKWebView with external scripting blocked and an optional return path, including for Apple Pay JS flows. Choose it because the payment integration requires that context, then test the provider's complete authorization and cancellation behavior.

Step 4. Add native features tied to repeat shopping

An app needs a reason to occupy space on a customer's phone. For a commerce store, the useful features are usually close to an order or an in-store visit:

• Send push notifications for back-in-stock alerts, order updates, abandoned carts, and loyalty offers through OneSignal, Klaviyo, Braze, or another provider in Median's Native Plugin Library.

• Open the relevant product, cart, or order directly when a customer taps a notification. Median's push handling supports a target URL for in-app navigation.

• Configure universal links and Android App Links so product URLs from email, SMS, and search open the matching page in the installed app.

• Add QR or barcode scanning for product lookup, loyalty cards, click-and-collect, or warehouse workflows where the use case warrants camera access.

• Connect in-store retail hardware, including point-of-sale terminals, handheld Bluetooth barcode scanners, payment card terminals, receipt printers, and iBeacons. The Median Solutions team scopes, delivers, and supports these integrations beyond the self-serve Native Plugin Library.

• Add native analytics for installs, sessions, campaign attribution, and crashes while keeping your storefront analytics for product and checkout behavior.

Push notifications alone do not justify an app for every store. The stronger case is a combination of repeat purchase, useful account or order information, loyalty, and a native feature that shortens something customers already do.

Step 5. Test a Commerce-specific device matrix

Test release-candidate builds on at least one current iPhone and one current Android phone. Cover these flows with guest and signed-in customers:

• Simple, configurable, grouped, bundled, virtual, downloadable, and custom-option products that your catalog actually sells

• Search, filters, wish lists, recently viewed items, product recommendations, and stock messages

• Store views, currencies, languages, tax regions, shipping destinations, and customer groups

• Coupons, gift cards, store credit, reward points, and loyalty extensions

• Every payment method, including authentication challenges, cancellation, failure, and return to the order confirmation page

• Login, logout, password reset, social login, account deletion, and session expiry

• Notification permission, notification tap, product deep link, and order deep link

• Camera, location, file upload, and biometric prompts, including what happens when the customer declines permission

Watch server timing and CDN behavior during the same run. If a checkout feels slower in the app, compare the same URL on the same device in the app and browser. That check helps separate website or CDN delays from native-shell behavior.

Step 6. Build and submit under your company accounts

Create signed iOS and Android builds after the purchase journey is stable. Median can provide the build files for your team or manage submission through its Publishing Service.

For Apple review, provide a working account that can reach catalog, cart, and checkout features. Apple says apps should offer features and UI beyond a repackaged website, so make the native navigation, push behavior, deep links, scanner, or other app-specific utility visible to the reviewer. Complete App Privacy answers for the storefront and every native SDK, and make account deletion easy to find.

For Google Play, complete the Data safety form, content declarations, and store listing, then use an internal testing track before production. Google requires a stable, responsive app with meaningful utility. A storefront that crashes on checkout or adds no useful app behavior is a review and retention problem, regardless of how quickly the build was created.

Keep the existing checkout for physical goods

Most Adobe Commerce stores sell physical goods. Apple's App Review Guidelines say apps selling physical goods or services consumed outside the app must use payment methods other than In-App Purchase, such as Apple Pay or card entry. Google Play's Payments policy likewise excludes physical goods and physical services from Play Billing.

That means a retail app can usually keep the same Adobe Commerce payment gateway and checkout used on the website. The technical work is making the gateway, authentication challenge, cookies, and return URL behave correctly inside the app.

Digital products need a separate review. Downloadable media, paid app features, and subscriptions consumed inside the app may fall under Apple In-App Purchase or Google Play Billing, with rules and regional programs that change over time. Classify each product type before development, and confirm the current policy for every storefront where the app will be distributed.

Frequently asked questions

Is Adobe Commerce the same as Magento?

Adobe Commerce is Adobe's commercial commerce product. Magento Open Source is the separate open-source codebase. Both can power a Magento mobile app, but licensing, B2B features, cloud services, and extension support differ. Name the exact edition and version when asking a mobile vendor about compatibility.

Does Adobe have an official mobile app builder?

Adobe provides PWA Studio for building web storefronts and Adobe Developer App Builder for Commerce extensions, integrations, and custom web applications. Neither is a service that takes a storefront URL and submits branded consumer apps to the Apple App Store and Google Play. You still need a native build, a wrapper platform, or a mobile development team for app store distribution.

Is a Magento PWA the same as a native mobile app?

No. A PWA is a web application with capabilities such as a service worker, responsive layout, offline caching, and home-screen installation. A native app is a signed iOS or Android binary distributed through an app store or private channel. You can package a deployed PWA storefront with Median, but building the PWA and publishing the native app remain separate steps.

Will existing Magento extensions work in a Magento 2 mobile app?

Extensions that render and work correctly in your mobile storefront usually continue to work in a live-site wrapper because the app loads that storefront. Test anything that opens a popup, calls another domain, uses camera or location access, injects checkout scripts, or identifies the browser by user agent. A headless or custom native frontend may need new API and UI work for each extension because its original storefront code is not present.

Can I use Median as an Adobe Commerce mobile app builder?

Yes. Median takes the live storefront URL, builds the iOS and Android native shells, and exposes native features to the storefront through the Median JavaScript Bridge. It does not replace the Commerce catalog or Admin. Your existing storefront remains responsible for shopping and account behavior, while Median handles the app-specific layer and can manage app store publishing.

How much does a Magento mobile app cost?

Cost follows the approach. A custom native build from a Magento mobile app development company usually starts in the tens of thousands of dollars and adds two codebases to maintain. Mobile app builder extensions charge a license fee plus the development time to fit your theme and extensions, and free tiers usually limit branding or features. Median prices the app as a per-app license: building and previewing in the App Studio is free, and Median's pricing covers white-labeled builds, native plugins, and publishing support. Compare each option against the storefront work it reuses, not just the entry price.

Can a Magento mobile app use the existing payment gateway?

Yes, when the store sells physical goods or qualifying real-world services. Test every redirect, 3-D Secure challenge, wallet, saved card flow, and failure state on physical devices. Digital goods consumed in the app may need the app stores' billing systems instead of the web gateway.

Do Commerce changes require a new app store submission?

Changes to products, pricing, promotions, content, and the web storefront appear in a Median app when the website serves them. Native changes such as the app icon, permissions, SDK plugins, or certain navigation settings require a new build and usually an app store update. PWA service-worker caching can also delay a storefront release, so include installed apps in release verification.

Do I need iOS and Android developers?

You do not need an in-house native team to wrap a working storefront with Median. You may still need your Adobe Commerce developer for theme changes, CSP rules, payment troubleshooting, or custom events that connect Commerce activity to push notifications. A custom native build needs dedicated iOS and Android or cross-platform engineering.

Is a Magento mobile app worth it?

An app is easier to justify when customers buy repeatedly, track orders, use loyalty benefits, respond to back-in-stock messages, or need in-store tools. A store with mostly one-time purchases and a weak mobile checkout should fix the website first. Set a target for repeat revenue, opt-in rate, purchase frequency, or loyalty use before building, then measure the installed app against it.

Can Apple approve a web-based Adobe Commerce app?

Yes, if it works like a useful app. Apple rejects apps that amount to a repackaged website with little lasting utility. Give reviewers complete access, make native behavior visible, provide account deletion where customers can create accounts, and keep checkout stable. Median's guide to Apple review for webview apps covers the broader submission standard.

Keep Commerce as the source of truth and add the app stores

Your storefront already knows how to sell your catalog. A live-site conversion keeps that system in charge and adds the native shell around it, which is the lowest-maintenance option when the mobile website already works. PWA Studio fits a broader headless rebuild. Custom native development fits a product whose defining experience cannot live on the web.

Start with the production store URL in the App Studio form above. Then test the difficult parts first: login, your most customized product, your highest-volume payment method, and the return from its authentication challenge. Those four checks will tell you more about the real project than a polished home-screen preview.