How to Turn a WooCommerce Store into an iOS & Android App

Also in: German · Spanish

You run a WooCommerce shop, your customers buy on their phones, and you want an app icon on their home screen. Most "convert your store in minutes" pages don't tell you which approach fits your store, or what breaks once your checkout runs inside an app.

This guide compares the four realistic options, then goes through what to check in WordPress and WooCommerce before you build: payment gateways inside a web view, login and cart sessions, caching plugins, cookie banners, account deletion and the App Store rules for shops.

Prices and policies were checked on the vendors' and stores' own pages in October 2026 and can change. Apple quotes are from the App Review Guidelines, last updated June 8, 2026. Nobody can guarantee an App Store approval: App Review decides case by case.

First: the official WooCommerce app is for you, not your customers

Search the App Store for "WooCommerce" and you'll find the official WooCommerce mobile app. It's a tool for store owners and managers: create products, process orders, check sales, take in-person payments with Tap to Pay or a card reader. Your customers can't browse or buy in it.

There's no switch in WooCommerce that publishes your shop as a customer app. You need one of the approaches below.

Four ways to get your store into the app stores

PWA Web-to-app shell Plugin-based app builder Custom native / React Native
What runs in the app Your site, added to the home screen from the browser Your live site in a native container Native screens filled via the WooCommerce REST API Your own app on the REST API / Store API
In App Store / Google Play No Yes Yes Yes
Your theme, plugins, checkout Unchanged Unchanged (same pages as mobile web) Only what the builder supports Only what you build
Shop changes Visible instantly Visible instantly Products sync; layout lives in the builder UI changes need a new release
Main risk Customers must find and install it Guideline 4.2 if it feels like a website Plugins and payment methods the app doesn't support Cost and maintenance
Best for Testing demand Shops whose mobile site already works well Standard catalog, standard checkout Large stores with a dev team

1. Progressive Web App (PWA)

Your site plus a web app manifest and a service worker. Customers add it to their home screen themselves; since iOS 16.4, such home-screen web apps can receive Web Push. There's no store listing, so nobody finds it by searching the App Store. A cheap way to test whether people want an app at all.

2. Web-to-app shell around the live store

A native container (WKWebView on iOS, WebView on Android) loads your real store. Theme, product add-ons, shipping rules, coupons and checkout keep working, and shop changes appear without a new release. The trade-off: the app is only as good as your mobile site, Apple will judge whether it's more than a "repackaged website", and payment popups and wallet buttons need testing, because a web view isn't Safari.

3. Plugin-based app builders on the WooCommerce REST API

These tools connect with WooCommerce REST API keys and render products, categories and cart in their own native screens. Three examples, as listed in October 2026:

  • AppMySite connects via WooCommerce REST API keys. Its WooCommerce plans are per app: the free plan and Starter ($69/month) are Android-only; iOS starts with Pro at $129/month ($99/month billed yearly).
  • Mobikul WooCommerce Mobile App Builder (Webkul) is a one-time purchase, $129 on sale, regularly $249, for Flutter-based Android and iOS apps synced via the REST API. Source code costs $129 extra, publishing from your accounts $75; three months of support are included.
  • Mobile App Builder for WooCommerce (FmeAddons) is sold on the WooCommerce Marketplace for €133 per year and links the app to your store with a REST API consumer key and secret.

Screens feel native, but anything your theme or plugins render only on the website (product configurators, custom checkout fields, B2B price rules) appears in the app only if the builder supports it. Ask the vendor about each plugin you rely on before you pay.

4. Custom native or React Native app

You build your own app. The WooCommerce REST API (/wp-json/wc/v3) authenticates with a consumer key and secret and can write store data, so those keys belong on your server, never in an app binary. For customer-facing features there's the Store API (/wp-json/wc/store/v1): unauthenticated endpoints for products, cart and checkout, with cart tokens (Cart-Token header) instead of cookie sessions. Full control, most native feel — and you rebuild every checkout extension, gateway and shipping rule, then maintain two front ends.

How to choose

  • Mobile site converts well, many plugins: shell.
  • Standard catalog and gateways, native screens without a developer: plugin-based builder.
  • Developers on hand and features the web can't do well: custom app.
  • Not sure customers want an app: PWA first.

Every store option needs the Apple Developer Program (99 USD per membership year, local prices vary) and a Google Play developer account (US$25 one-time).

Prepare your store before you build

This applies fully to a shell and partly to builders that hand checkout off to your website. Test on a real phone in a test build, not in desktop Safari.

Mobile theme and start screen

  • Check every template customers hit: shop archive, product, cart, checkout, My Account, order received. Page-builder themes often have a polished home page and a cramped checkout.
  • No element wider than the screen; no pinch-zoom needed to read anything.
  • Use a start URL that shows products (shop or a category), not a homepage built for ads and newsletter popups.
  • Remove "download our app" banners from the in-app experience.

Checkout and payment gateways inside a web view

This is where most WooCommerce apps need work.

  • Redirect flows. Gateways that send customers to an external page (PayPal, many bank and buy-now-pay-later methods, hosted payment pages) must bring them back into the app. Check that the return lands on your order-received page inside the app, not in the phone's browser.
  • Popups. PayPal's checkout can open a popup window, which web views handle poorly. That's why Braintree (a PayPal company) maintains PopupBridge, a library that opens such popups in a secure browser sheet and passes the result back. Test PayPal end to end, including cancel.
  • 3-D Secure. For most card payments in the EEA and UK, Strong Customer Authentication adds a step, usually 3-D Secure. Test a card that triggers a challenge and one where the bank app asks for approval, then check you return to the confirmation.
  • Apple Pay. WebKit brought Apple Pay to WKWebView in iOS 13, but it "cannot be used alongside of script injection APIs" such as WKUserScript. Many shells inject scripts to connect web and native code; Ionic's documentation lists the web view of a Capacitor or Cordova app as a place where Apple Pay doesn't work without a plugin. Don't make it your only express option, and check that card and PayPal still show when it's missing.
  • Google Pay. On Android, Google Pay on a web page inside a WebView requires the app to enable the Payment Request API and declare payment intents, plus a recent WebView. Ask your builder and test it.

Login, session cookies and cart persistence

  • "Remember me". WordPress keeps a login for 14 days with "Remember me", otherwise as a session cookie that ends after two days or when the browser closes. Force-quit the app, reopen it the next day, see if you're still logged in.
  • Cart lifetime. In current WooCommerce code, a session lasts two days for guests and a week for logged-in customers by default (filter: wc_session_expiration). Logged-in customers also get a persistent cart stored with their account.
  • Separate cookie store. Being logged in on Safari doesn't log customers in inside your app, and vice versa.
  • Social login plugins. Google's OAuth policy says developers must not send sign-in requests to an embedded user-agent, so "Sign in with Google" in a web view can fail. Apple's guideline 4.8 also requires an equivalent privacy-friendly login option whenever a third-party login sets up the customer's account. Hiding social login buttons in the app is often the simplest fix.
  • Demo account. Guideline 2.1 asks for "demo account info" if your app has a login. Create a customer account for App Review.

Caching plugins that break logged-in sessions

WooCommerce's guide to configuring caching plugins is the reference. Check:

  • Cart, Checkout and My Account are excluded from page caching.
  • Requests with woocommerce_cart_hash, woocommerce_items_in_cart or wp_woocommerce_session_ cookies bypass the cache.
  • With database or object caching, _wc_session_ is excluded.
  • CDN or hosting rules that cache all HTML respect these exclusions.
  • Per-user caching (WP Rocket's User Cache, LiteSpeed's Cache Logged-in Users) is tested with two different customer accounts.

Typical symptoms in an app: someone else's mini cart, an empty cart after login, or a checkout that rejects the session.

  • The consent banner appears on first launch, because the app's cookie store starts empty. It must fit a phone screen and not cover the checkout button.
  • Apple treats web views used for app functionality like native code: "If tracking occurs within a webview inside an app", the App Tracking Transparency prompt is required. Ad and retargeting pixels on your shop pages count. Remove them from the app experience or plan for ATT, and reflect it in your App Privacy details.

Performance

  • Since WooCommerce 7.8, the cart fragments script only loads where the Cart widget is rendered. If an old theme or plugin still loads it everywhere, every app screen pays for an extra request.
  • Test on mobile data, not office Wi-Fi, and optimise product images.

Account deletion (guideline 5.1.1(v))

"If your app supports account creation, you must also offer account deletion within the app." WooCommerce creates customer accounts at checkout or on My Account, but has no "delete my account" button for customers. Per Apple's account deletion guidance, deletion must be initiated in the app, deactivation alone isn't enough, and a manual process is fine if you say how long it takes.

In practice: add a "Delete account" item to the My Account menu that sends a request your team processes with WordPress's Tools → Erase Personal Data. Under WooCommerce → Settings → Accounts & Privacy, decide on "Remove personal data from orders on request", and check with your tax adviser which order data you must keep.

Physical vs. digital goods

Guideline 3.1.3(e): for "physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase". Your normal WooCommerce checkout stays.

Downloadable products, digital memberships and content subscriptions fall under 3.1.1, which requires in-app purchase "if you want to unlock features or functionality within your app". The same applies to digital gift cards redeemable for digital goods; physical gift cards mailed to customers may use other payment methods. If you sell both, consider leaving digital products out of the app.

Store review risks

Guideline 4.2 – Minimum Functionality. Apple wants "features, content, and UI that elevate it beyond a repackaged website". Shops have an advantage, since 4.2.2 exempts catalogs from the "marketing materials" complaint, but a desktop theme, web-only navigation and a blank screen offline still look like a website with an icon. Our article on fixing a Guideline 4.2 rejection covers the fixes.

Guideline 4.2.6 – app generators. Apps from app generation services "will be rejected unless they are submitted directly by the provider of the app's content". Submit from your own Apple Developer account, whichever builder you use.

Google Play. The Minimum Functionality policy asks for "a stable, engaging, responsive user experience". The spam policy targets webviews of a website "without permission from the website owner or administrator" — not an issue for your own shop.

Review notes. Guideline 2.3.1(a) wants features "described with specificity in the Notes for Review". Mention the demo account, where account deletion is, and that you sell physical goods through your normal checkout.

Checklist before you submit

  • Shop, product, cart, checkout and My Account work on a phone; start URL shows products
  • Every payment method tested in the app build: redirect, PayPal popup, 3-D Secure, Apple Pay/Google Pay or a fallback
  • Login survives a force-quit; cart survives a restart
  • Cart, Checkout, My Account and WooCommerce cookies excluded from every caching layer
  • Social login hidden, or a 4.8-compliant alternative offered
  • Consent banner fits the screen; ATT handled or ad pixels removed in the app
  • Account deletion reachable from My Account (5.1.1(v))
  • Digital products via in-app purchase or left out (3.1.1)
  • Demo customer account and specific Notes for Review
  • Submitted from your own Apple Developer account (4.2.6)

Where AppThunder fits

AppThunder is option 2: it builds an iOS and Android app around your live WooCommerce store in the cloud (a Capacitor-based shell), so theme, plugins and checkout stay as they are. You get a native app icon and splash screen, camera and location permission prompts with purpose strings (only if you enable them), a branded offline screen that reloads automatically, a copy-paste bottom tab bar snippet for your site (a web snippet, not a native tab bar) and Thunder Analytics. A Guideline Checker flags common review issues such as a missing privacy page, a login wall or missing account deletion. Builds are signed with your own Apple and Google credentials, iOS builds go to your own App Store Connect (TestFlight), and you get .ipa and .aab files. Plans start at €39/month net for one live app; the free plan lets you set up the app and preview it (builds need a paid plan).

What it doesn't do: fix your mobile theme, configure your caching plugin, add a "Delete account" page to WordPress, or make wallet payments work inside a web view — plan for Apple Pay not being available, as described above. You still need your developer accounts, a privacy policy, a demo account and your store listings. And no tool can guarantee approval.

FAQ

Can I use the official WooCommerce app as my shop app? No. It's for store owners and managers to handle products, orders and in-person payments. Customers can't shop in it.

Will my WooCommerce plugins work in the app? In a web-to-app shell, the app shows the same pages as your mobile site, so plugins that work there generally work in the app; payment popups and wallets are the exception to test. Builders with native screens only support what they've integrated.

Do I have to use Apple's in-app purchase for my products? Not for physical goods (3.1.3(e)). Digital content and subscriptions that unlock something in the app fall under 3.1.1.

Do I need to republish the app when I change products or prices? Not with a shell or a REST API builder; product data comes from your store. You need a new build when the app itself changes, for example its icon or permissions.