A WooCommerce mobile app for customers is a separate iOS and Android app under your store's name that shoppers install to browse and buy. You can get one four ways: an app plugin that redraws your catalog from the WooCommerce API, a website to app converter that loads your live store, a managed service, or a custom build. The right one depends mostly on how much of your store lives in plugins.
This guide helps you choose a route and then prove it works on your own store before you spend money. For the short version, see the WooCommerce to app page. For a wider comparison that covers WordPress content sites too, read WordPress to app plugins vs converters.
Is the official WooCommerce app for customers?
No. The WooCommerce app in the App Store and Google Play is a store management app for merchants. WooCommerce's mobile app documentation describes it in those terms: you process orders, create and manage products, and take in-person payments. Your customers can't shop in it, and it doesn't carry your brand.
A customer app is a different thing. It has your store name and icon, sits on a shopper's home screen, and opens your catalog, cart and account area. WooCommerce doesn't ship one, so every store gets it from a third party or builds it.
Should a WooCommerce store have an app at all?
An app earns its place when the same people buy from you again and again. Before comparing routes, check your store against these questions.
- Do customers reorder? Coffee, pet food, supplements, skincare, print supplies and trade parts are bought on a cycle. A home-screen icon and a saved login shorten every repeat order.
- Do customers log in to do something? Subscriptions to pause or skip, bookings to manage, wholesale price lists, order tracking and downloads all give people a reason to open an account area regularly.
- Do you have news worth a notification? Drops, restocks, seasonal ranges and sales suit push. A store that changes twice a year has little to send.
- Is the mobile site already good? If phone shoppers abandon your checkout today, an app built on that checkout inherits the problem.
If most of your orders come from first-time visitors arriving through search or ads, put the effort into the mobile site instead. Nobody installs an app to buy once.
What makes WooCommerce different from a hosted store?
WooCommerce gives you WordPress and lets you assemble the rest. A typical store runs a theme, a payment gateway or three, a shipping calculator, and then the plugins that make it yours: WooCommerce Subscriptions, Bookings, Product Add-Ons, a wholesale pricing plugin, a loyalty scheme, a custom checkout field for delivery notes.
So ask one question of every route below: does the app show what my plugins add, or only what core WooCommerce knows about?
What are the four ways to get a WooCommerce customer app?
Route 1: An app plugin that rebuilds the store from the API
Several services connect to your store through the WooCommerce REST API, usually with a companion WordPress plugin, and draw products, categories, the cart and orders as their own native screens. You design the app in the vendor's dashboard and pay a subscription.
Good at: native product lists and product pages that scroll and animate like any shopping app, and a home screen you can lay out differently from your website.
Check carefully: the API describes products, variations, customers and orders. It doesn't describe what a third-party plugin renders on the page. An add-ons form, a booking calendar, role-based prices or a custom checkout step each need the vendor to have built support for that specific plugin. Some of these services show your website checkout in a WebView for this reason. Ask the vendor for a list of supported extensions and gateways, then compare it with your own plugin list line by line.
Route 2: A website to app converter
A converter builds a native shell around your live website. The shell supplies the app icon, launch screen, a native header, menus and bottom tabs, and optional push notifications. Your storefront loads inside it in a WebView, the same browser engine that Safari and Chrome use.
Good at: fidelity. Whatever your theme and plugins render on a phone is what the app shows, because it's the same page from the same server. Nothing has to sync, and you don't maintain a second catalog or design.
Check carefully: you don't get natively redrawn product screens. The app is as fast and as tidy as your mobile site and no better. A few things behave differently in an embedded browser than in Safari or Chrome, which is what the test plan below is for.
SiteTo.App takes this route. You paste your store URL, set the name, icon and tabs, and preview the app on your own phone for free. A build costs $29 for Android, $79 for iOS or $99 for both, paid once.
Route 3: A managed app service
A managed service typically uses the same WebView approach for your pages and adds a team: they configure the app, build custom native screens where you want them, submit to the stores and maintain it for a monthly fee. Our SiteTo.App vs MobiLoud comparison looks at one such service in detail.
Route 4: A custom app
A developer or agency builds an app against the REST API and the Store API, with every screen designed for your store. This is the route for things a website can't do, such as working fully offline. It's priced as a project and then needs maintenance, including rework when you change a plugin the app depends on.
How do the routes compare?
| API-based app plugin | Website to app converter | Managed service | Custom app | |
|---|---|---|---|---|
| Product and cart screens | Native, drawn by the vendor | Your mobile site | Your mobile site, plus custom native screens | Native, built for you |
| Third-party plugins | Only those the vendor supports | Whatever works on your mobile site | Whatever works on your mobile site | Each one integrated by hand |
| Checkout | Vendor's flow or your site in a WebView | Your website checkout | Your website checkout | Built or embedded |
| Pricing model | Subscription | One-time build fee | Monthly fee | Project plus maintenance |
| Who submits to the stores | Varies by vendor | You | The service | You or your agency |
| Work when you change the store | Re-check plugin support | Usually none | Usually none | Developer time |
Apple's developer membership ($99 a year) and Google Play's registration ($25 once) apply to every route. The website app cost guide covers the full budget.
Which route fits which WooCommerce store?
Choose an API-based app plugin if your store is close to stock WooCommerce, with simple and variable products and a mainstream gateway, and a native browsing feel matters more to you than a low fixed cost.
Choose a converter if your mobile store already works well and a meaningful part of it comes from plugins. That includes subscription boxes, bookings, product configurators, wholesale stores with logged-in pricing, and stores with a customized checkout.
Choose a managed service if you want a team to own the launch and upkeep, or you need custom native screens on top of your site and the monthly fee makes sense against your app revenue.
Choose a custom build if the app has to do something a browser can't: work properly offline, talk to Bluetooth hardware, use augmented reality or keep working in the background.
When is SiteTo.App the wrong choice?
- Your mobile site is the problem. A slow theme or a checkout that's awkward on a phone will be just as slow and awkward in the app. Fix the site first.
- You need lifecycle push. SiteTo.App sends a title, text, image and link to everyone who opted in, through your own Firebase project. It doesn't send automated abandoned-cart or order-status notifications, and it has no segments or scheduling yet.
- You sell digital content on iOS. The app uses your website checkout and doesn't add Apple's in-app purchase. See the publishing notes below.
It also isn't a fit for Bluetooth, AR, heavy offline use or background processing.
How do you test a WooCommerce store as an app?
Use a real iPhone and a real Android phone if you plan to ship both, and work through these steps in order. Write down the page URL wherever something fails.
Step 1: Prepare the store
Put each payment gateway into its test or sandbox mode, or create a low-priced hidden product and a 100% coupon you can refund. Create a fresh customer account for testing.
Step 2: Browse and build a cart
Open a category, use filters and search, then open a variable product. Pick its options, fill in any add-on fields, and add it to the cart. Watch the mini-cart or cart count. If it stays at zero, a page cache is probably serving stored content. WooCommerce's caching guidance says to exclude the Cart, Checkout and My Account pages and its session and cart cookies from caching.
Step 3: Check totals
Apply a coupon, enter a real shipping address and compare the shipping rates and tax with the same cart on your website. They should match exactly, because the same server is doing the arithmetic.
Step 4: Pay with every gateway
Payment is where an in-app WebView is most likely to differ from a phone browser, so give this step the most time.
- On-page card fields, such as those from WooPayments or Stripe, normally behave as they do on the mobile web. Use a test card that triggers 3-D Secure and confirm the challenge appears and completes.
- Redirect gateways send the customer to a bank, a wallet or a PayPal window. Follow the whole path and confirm you land on your order-received page inside the app, not in the phone's browser with the app left behind showing a stale checkout.
- Apple Pay and Google Pay buttons show only when the gateway's script decides the environment supports them, and an in-app WebView isn't the same environment as Safari or Chrome. Google documents specific requirements for Google Pay in Android WebView, and WooPayments publishes its own express checkout compatibility notes. Treat wallet buttons as a bonus. Card payment must always be available beside them.
Afterwards, check that the order appears in wp-admin with the right status and that the confirmation email arrived.
Step 5: Test accounts and sessions
Register or sign in, open My Account, and view an order. Then close the app completely and reopen it. You should still be signed in with your cart intact. Request a password reset and follow the email link to see where it opens and whether the journey back to the app makes sense.
If you use a social login plugin, try each button. Google blocks its sign-in screen in embedded WebViews, so a "Continue with Google" button may show an error there. Email and password login is the dependable path, so make sure it's offered.
Step 6: Run each plugin's journey
List the customer-facing plugins that make your store yours and run one complete journey for each.
- Subscriptions: buy one, then suspend it, change the payment method and cancel it from My Account.
- Bookings: choose a date and time on the phone-sized calendar and complete the booking.
- Wholesale or B2B: sign in with a trade account, confirm the trade prices show, and place a reorder.
Step 7: Tidy the frame
Dismiss the cookie banner and any newsletter pop-up. Check that your theme's sticky header, bottom bar or floating chat button doesn't double up with the native header and tabs. SiteTo.App can run scripts that hide your site's own header and pop-ups inside the app, so note anything you'd like removed. If a firewall or CAPTCHA challenges you during login, make sure a real customer could pass it on a phone.
What should the results tell you?
| Result | What to do |
|---|---|
| Everything passes | Choose your tabs, build, and move on to publishing |
| A wallet button is missing but cards work | Launch with cards and treat wallets as a later improvement |
| A redirect gateway doesn't return to the app | Talk to the gateway about an on-page option, or offer a different gateway |
| A plugin's page breaks at phone width | Fix it on the website; the fix helps mobile web shoppers too |
| Checkout is slow or confusing | Improve the mobile checkout before building any app |
What should you set up in the app itself?
Use the native parts of the app to make repeat buying quicker.
- Bottom tabs: Home, Shop or your strongest category, Cart, and My Account work for most stores. A reorder-heavy store can point a tab straight at
/my-account/orders/. - Cart badge: with a developer's help, the SiteTo.App JS SDK can watch a URL on your site and show the number it returns as a badge on a tab. WooCommerce's Store API cart endpoint returns an
items_countfor the current cart, which a developer can use as the badge value. - Push: connect Firebase using the Firebase guide and decide in advance what you'll send.
Product, price and stock changes in wp-admin show up in the app without a new build. Changing the icon, the app name or other native settings needs a rebuild, and later rebuilds are quoted separately.
What do WooCommerce stores need to know before publishing?
You submit the app from your own Apple and Google accounts. SiteTo.App signs the iOS build and uploads it to TestFlight in your Apple account, so you don't need a Mac or Xcode, and gives you an AAB for Google Play, or an APK. The create and publish guide walks through each step. Apple and Google decide what gets approved, and nobody can promise the outcome. These points come up for WooCommerce stores in particular.
Physical goods use your own checkout. Apple's App Review Guidelines say that goods and services consumed outside the app are paid for with methods other than in-app purchase (section 3.1.3(e)). A store that ships products is on solid ground.
Digital goods are different. Content used inside the app, such as a paid course, a video library or a members-only area, falls under Apple's in-app purchase rules in section 3.1. Google Play has its own payments policy for in-app digital goods. Read both before you build if digital products or paid memberships are a real part of your sales.
Offer account deletion. Apple expects any app that supports account creation to let people start deleting their account from inside the app. A default WooCommerce My Account page has no such option. Add one with a plugin or a clearly labeled request form.
Give reviewers a way in. If prices or products sit behind a login, as in many wholesale stores, supply a working test account in the review notes.
Show more than a website. Apple's Guideline 4.2 asks apps to offer more than a repackaged site. Native tabs, a native header and push notifications help, and so does a store with real functionality behind a login. The Guideline 4.2 guide explains how to prepare, and the publishing guide covers listings, screenshots and privacy answers.
Common questions
Do I need to install a WordPress plugin?
Not with a converter. SiteTo.App works from your public store URL, so you don't add a plugin to WordPress or create a REST API key. API-based app services usually do need a companion plugin and API access, because they read your catalog directly.
What happens to the app when I update WooCommerce or a plugin?
The app shows the updated store the next time it's opened, with no new build. That also means a plugin update that breaks your mobile checkout breaks it in the app at the same moment. Run a quick test order on a phone after significant updates, as you would for the website.
Can I launch on Android first?
Yes. An Android build is $29 and Google Play registration is $25 once. Buying the iOS build later costs its own $79, so the two bought separately come to $108 against $99 for both together.
Next step
Open your store on your phone and place a test order. If that goes well, preview your WooCommerce store as an app for free, run the seven steps above, and check pricing once you know it works.
See your website as an app
Customize the experience and preview it before choosing a platform.
Build your preview


