Commerce mobile app development guide 2026
Commerce mobile app development in 2026 is not a “store in a phone”; it is an owned revenue channel with the same catalogue, pricing, cart and inventory truth as the web store. GMI builds these apps with React Native + headless API (Medusa, NestJS or an existing backend): MVP EUR 35,000 - 55,000, typically 4-6 months to App Store and Google Play. SFD case: 100k+ downloads, 4.9 App Store rating, Mobile Trends Awards Commerce nomination.
First business decision: should the app sell, or merely exist?
A good e-commerce app is not a copy of the mobile web in a container. It has a reason the browser usually cannot match: faster customer return through push, smoother cart, loyalty at hand, saved payment methods, barcode scanning, personalisation and lower reach cost for active customers.
A weak project starts with “how much does an app cost?”. A strong project starts with “which revenue or retention problem should the app improve?”. For D2C it can be repeat purchase and LTV; for omnichannel retail - store pickup, local stock and loyalty; for B2B - quick reorder and a sales-rep panel.
At GMI, we treat a commerce app as part of the sales architecture: web, backend, ERP/PIM/WMS, CRM, loyalty, push and analytics must work together. An iOS/Android frontend without a clean API contract does not solve the problem; it creates a second channel of chaos.
Reference architecture: React Native + headless commerce
The safest 2026 model is React Native/Expo as the experience layer and one headless backend for web and app. The backend can be Medusa, NestJS, a custom API or an existing commerce engine with a BFF layer. The critical rule: the app must not have its own truth for prices, promotions and stock.
The app frontend handles PDP, search, cart, checkout shell, account, loyalty, push inbox and deep links. The backend owns catalogue, pricing, promotions, cart, payments, orders, returns and integrations. ERP/PIM/WMS remain sources of truth for operational data.
Expo EAS speeds up release and OTA updates for JS/UI changes, but it does not replace App Store review when you change native code, permissions or behaviour governed by store policies. This belongs in the release process, not as a surprise after the first rejection.
- App: React Native, Expo, native payment/push SDKs, deep links, offline cache for catalogue and account.
- Commerce API: Medusa, NestJS or BFF over an existing store; one contract for web + app.
- Operations: ERP/PIM/WMS/CRM, pricing, inventory, fulfilment, returns, invoices and order statuses.
- Growth: Firebase/GA4/Mixpanel, CRM/CDP, push automation, A/B tests, app vs web dashboard.
MVP scope vs full store app
A commerce app MVP should deliver the full purchase path, not a “nice catalogue without money”. Minimum scope: home/PDP/search, login, cart, checkout, payment, order history, status push, basic loyalty and event analytics. At GMI this usually lands at EUR 35,000 - 55,000 and 4-6 months to stores.
The full app starts where mobile becomes better than web: wishlist, recommendations, barcode scanner, offline cache, campaign deep links, segmented push, coupon wallet, advanced loyalty, POS integration or B2B quick reorder. Scope typically grows to EUR 55,000 - 90,000+.
Separate native iOS+Android fits extreme GPU/AR requirements, deep native hardware or corporate policy blocking RN. For most commerce, GMI recommends React Native because one team ships and maintains iOS/Android parity faster.
Checkout, payments and store compliance
For physical e-commerce, Apple and Google do not require classic IAP. Apple 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 similarly excludes payments for physical goods such as groceries, clothing and electronics from Play Billing.
That does not make checkout easy. WebView checkout shortens time-to-market and reduces PCI scope, but it can be worse for UX, deep links and analytics. Native Stripe/Adyen/PayU SDKs create a smoother flow, but need more integration, testing and ownership of edge cases.
App Store review: prepare an active demo account, accessible backends, clear reviewer notes, privacy policy, loyalty explanation and full account deletion support. Apple explicitly expects a complete app, working URLs, no crashes and access to account features during review.
Analytics: events you need to manage the app channel
A commerce app without analytics is an expensive experiment without a steering wheel. Minimum events should follow GA4 ecommerce: `view_item`, `add_to_cart`, `begin_checkout`, `purchase`, plus app-specific events: push_open, coupon_apply, loyalty_redeem, search_no_results, payment_failed and reorder.
From sprint one, we design event taxonomy and parameters for SKU, category, value, currency, coupon, source, campaign and user segment. After launch you can tell whether the app increases repeat purchase, AOV, retention and LTV, or merely moves orders from web into a more expensive channel to maintain.
The dashboard should compare app vs mobile web: conversion rate, checkout completion, logged-in user share, push opt-in, purchase frequency, revenue per active user, crash-free sessions and latency of critical endpoints. This speaks to CMO, CTO and CFO at the same time.
Push, loyalty and personalisation: where app beats mobile web
The biggest app advantage is not that an icon sits on the home screen. It is that the brand can return to the customer without buying another ad click. Push must be consent-based, segmented and intent-aware; otherwise it quickly lowers opt-in and damages app ratings.
Good scenarios: order status, back-in-stock, price drop, coupon expiring in 24 hours, loyalty birthday, refill reminder, abandoned cart after login, post-purchase recommendation and a campaign for high-LTV customers. Weak scenario: a daily promo broadcast to everyone.
Loyalty in the app works when the customer sees real value: point balance, tiers, coupons, benefit history, card scanning in store, personalised offers and clear rules. If the programme is only a PDF policy, the app will not fix it.
Operational integrations: where commerce app projects usually break
The biggest risk is not on the product screen. It is whether price, promotion and availability match across app, web, POS and ERP. If the app shows an item as available but WMS cannot confirm it, the problem hits customer support and damages trust in the channel.
In discovery we map sources of truth: PIM for product data, ERP for pricing/commercial terms, WMS for stock, OMS for statuses, CRM/CDP for segments, payment provider for charge/refund and loyalty system for points. Each system needs an owner, SLA, retry and manual replay plan.
For B2B, add quick reorder, credit limits, contract price lists, approval flow, invoices, multiple delivery addresses and company accounts with roles. This usually needs a headless API or BFF; adding an app to a legacy store without a stable API is a short path to expensive rewriting.
SFD case and what to learn from it
SFD app (React Native + headless backend): 100k+ downloads, 4.9 App Store rating, Mobile Trends Awards Commerce nomination. This is production proof for a large catalogue, checkout, loyalty and real user scale, not a portfolio PoC.
The key lesson: a commerce app works when it is not a separate universe. One API contract for web and app, analytics events from sprint one, close backend cooperation and a post-launch retainer are less flashy than animations, but they decide channel stability.
Second lesson: a 4.9 rating does not come from design alone. It comes from speed, reliable cart, no crashes, clear payment messages, sensible push and fast reaction to iOS/Android changes after publication.
Delivery model and pricing
Typical GMI flow: DDT (1-2 weeks) -> fixed price -> 2-week sprints with demos -> TestFlight/Internal Testing -> App Store and Google Play submission -> 6-12 month retainer. During DDT we close scope, store risks, integrations, event taxonomy and post-go-live ownership.
Before RFP prepare: link to web/API, mockups of key flows (home, PDP, cart, checkout), integration list (ERP, PIM/WMS, CRM, loyalty, payments), push requirements, privacy policy, launch countries and KPIs: conversion, AOV, retention, LTV, crash-free sessions.
Fixed price makes sense only after discovery because the same UI can cost very differently depending on backend, checkout, catalogue quality, number of markets, payment variants and whether the client already has a commerce-side team.
Pre-kickoff checklist for a commerce app
This list is useful before talking to GMI, but also before talking to any agency. If you get an estimate without these answers, someone is probably estimating screens rather than a sales channel.
- Should the app increase repeat purchase, AOV, retention, LTV, logged-in customer share or B2B order handling?
- Which system is the source of truth for product, price, promotion, stock, order, return, loyalty and invoice?
- Can the existing API serve app and web through one contract, or do you need a BFF/headless layer?
- What does checkout look like: WebView, hosted checkout, native SDK, Apple Pay/Google Pay, card saving, refunds and fraud?
- Which analytics events, dashboards and push segments must work from version one?
- Who maintains the app after release: iOS/Android updates, SDKs, crash monitoring, review, hotfixes and sales peaks?
Next step: commerce app estimate
Have a headless backend, Medusa, Shopify/BigCommerce/Magento or a custom API and want an app that actually increases sales? Contact GMI - initial MVP scope and ranges within 48h. Full fixed-price offer after DDT.
Mobile apps: https://gmi.software/services/mobile-apps | Commerce mobile analytics: https://gmi.software/services/ecommerce-mobile-analytics
Sources and references
Apple App Review Guidelines - payments, app completeness and review access: https://developer.apple.com/app-store/review/guidelines/
Google Play payments policy - physical goods and Play Billing exceptions: https://support.google.com/googleplay/android-developer/answer/9858738
Google Analytics ecommerce events for GA4: https://developers.google.com/analytics/devguides/collection/ga4/ecommerce
Expo EAS Update documentation: https://docs.expo.dev/eas-update/introduction/
GMI commerce mobile analytics: https://gmi.software/services/ecommerce-mobile-analytics
SFD loyalty mobile app case: https://gmi.software/case-study/sfd-loyalty-mobile-app
GMI mobile apps service: https://gmi.software/services/mobile-apps
React Native at GMI: https://gmi.software/technologies/react-native
Frequently asked questions
- Native or React Native for a store app?
- For most commerce, choose React Native: one team, faster MVP, iOS/Android parity and lower TCO. Native Swift/Kotlin fits extreme hardware, AR/GPU or corporate policy. The SFD case shows 100k+ downloads on React Native.
- How much does an e-commerce app MVP cost?
- At GMI: EUR 35,000 - 55,000 fixed price after DDT, usually 4-6 months to App Store and Google Play. Scope: catalogue, search, cart, checkout, payment, account, status push, basic loyalty and analytics.
- Do I need a separate backend for the app?
- Usually no. The best model is one headless API for web and app: Medusa, NestJS, existing REST/GraphQL or a BFF over legacy. A separate app backend only makes sense as a transition when the current store has no stable API.
- How to measure conversion in a store app?
- From sprint one: GA4 ecommerce events (`view_item`, `add_to_cart`, `begin_checkout`, `purchase`) plus push_open, coupon_apply, loyalty_redeem and payment_failed. The dashboard should compare app vs mobile web.
- Must an e-commerce app use Apple IAP or Google Play Billing?
- Not for physical goods and services consumed outside the app. Apple and Google allow other payment methods such as Apple Pay, Google Pay, Stripe, Adyen or PayU. IAP/Play Billing mainly applies to digital goods, subscriptions and in-app functionality.
- When does a commerce app not make sense?
- It does not make sense when mobile web already converts well, you have no push/loyalty plan, the backend has no API, the catalogue is unstable and the team does not want to maintain the app after launch. Fix web, backend and analytics first.
Content updated: July 11, 2026