BigCommerce Mobile App for Customers: 4 Routes Compared

A BigCommerce mobile app for customers is a separate iOS and Android app under your store's name that shoppers install to browse, sign in and buy. BigCommerce doesn't provide one, so you get it one of four ways: an app builder from the BigCommerce App Marketplace, a website to app converter that loads your live storefront, a managed app service, or a custom build on the BigCommerce APIs. The right route depends mostly on how much of your store's value sits behind a customer login.

This guide helps you choose a route and prove it on your own store before you spend money. For the short version, see the BigCommerce to app page.

Is the BigCommerce mobile app for customers?

No. The app called BigCommerce in the App Store and Google Play is a store management app. BigCommerce's own mobile app page is headed "Manage BigCommerce from your mobile device." You check revenue, orders and visitors, update order statuses and look up customers. Shoppers can't buy anything in it, and it doesn't carry your brand. Every BigCommerce store with a customer app got it from a third party or built it.

Should a BigCommerce store have an app at all?

An app earns its place when the same people buy from you repeatedly. Check your store against these questions before comparing routes.

• Do buyers reorder? Parts, packaging, janitorial supplies, salon stock, supplements and pet food are bought on a cycle. A home-screen icon and a saved login shorten every repeat order.
• Do buyers sign in to get their deal? Trade accounts with a price list, members in a discounted customer group and companies with payment terms all have a reason to be logged in every time.
• Is the mobile storefront already good? An app built on a checkout that phone buyers struggle with inherits the struggle.

If most orders come from first-time visitors arriving through search or ads, put the effort into the mobile site instead.

What makes BigCommerce different when you add an app?

Three things about the platform shape the decision.

A lot of the store is decided by who is signed in. On plans that include them, customer groups control which categories a customer can see and which discounts apply. Price lists, on plans that include them, override prices at the variant level for a group. Stores on B2B Edition add a Buyer Portal with company accounts and user roles, a quick order pad that takes SKUs or a CSV, shopping lists, quotes and an invoice portal. On a trade or wholesale store, that logged-in layer is most of what buyers touch.

Checkout is BigCommerce's. On a Stencil storefront the Optimized One-Page Checkout is the default and runs on your store domain.

The front end may be headless. A Catalyst or custom headless storefront usually hands the shopper to BigCommerce's hosted checkout at the last step, which adds one more journey to test.

So the question to put to every route is this: does the app show what a signed-in buyer sees on my storefront, or only what the public catalog contains?

What are the four ways to get a BigCommerce customer app?

Route 1: An app builder from the BigCommerce App Marketplace

The BigCommerce App Marketplace lists a small number of mobile app builders. They connect to your store through the BigCommerce APIs, pull in products, categories and customers, and draw them as their own native screens. You design the app in the vendor's dashboard and, in most cases, pay monthly.

Good at: native product lists and pages, and a home screen you can lay out differently from your website.

Check carefully: the selection is small. Before a demo, write down everything on your storefront that depends on login and ask the vendor about each item by name: customer-group category access, price-list prices, B2B Edition company accounts, quick order, shopping lists, quotes, invoices, purchase-order payment. Then ask how checkout works, because some API-based apps show the web checkout in a WebView at the final step anyway.

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 Safari and Chrome use.

Good at: fidelity. Whatever BigCommerce renders for a signed-in buyer on a phone is what the app shows, because it's the same page from the same store. Group pricing, gated categories and the Buyer Portal come along without integration work, and there's no second catalog to keep in step.

Check carefully: you don't get natively redrawn product screens. The app is as fast and as usable as your mobile storefront. A few things behave differently in an embedded browser, 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 such as MobiLoud typically uses the same WebView approach for your pages and adds a team. They configure the app, build custom native screens, submit to the stores and maintain it for a monthly fee.

Good at: taking the launch off your desk. Because your pages still load from the live storefront, logged-in pricing and the Buyer Portal behave as they do in Route 2.

Check carefully: the fee continues for as long as the app is live, so compare it with what the app is likely to earn. Our SiteTo.App vs MobiLoud comparison looks at one such service in detail.

Route 4: A custom app on the BigCommerce APIs

An agency builds the app against BigCommerce's storefront and management APIs, with every screen designed for your buyers. This is the only route that can do what a website can't, such as ordering from a catalog fully offline. It's priced as a project and then needs maintenance, including rework when your B2B setup or checkout changes.

How do the routes compare?

Apple's developer membership ($99 a year) and Google Play's registration ($25 once) apply on every route. The website app cost guide covers the full budget.

Which route fits which BigCommerce store?

Choose a marketplace app builder if you run a consumer store with a simple catalog, most buyers check out as guests or with plain accounts, and a native browsing feel matters more to you than a low fixed cost.

Choose a converter if your mobile storefront already works and the logged-in experience is the point: trade pricing, customer groups, company accounts, quick reorders.

Choose a managed service if you want a team to own the launch and upkeep, or you need custom native screens and the monthly fee makes sense against app revenue.

Choose a custom build if the app must do something a browser can't and you have the budget to maintain it for years.

When is SiteTo.App the wrong choice?

• Your mobile storefront is the problem. A slow theme or an account area that needs pinching and zooming will be exactly as awkward in the app. Fix the site first.
• You need targeted push. SiteTo.App sends a title, text, image and link to everyone who opted in, through your own Firebase project. It can't notify one company, one customer group or one sales rep's accounts, and it has no scheduling, abandoned-cart or order-status messages yet.
• Your buyers work without signal. The app loads your live storefront and needs a connection. Warehouses and job sites with no coverage need a custom app with real offline ordering.
• You need hardware features. Bluetooth scanners, AR and background processing are outside what it does.
• You want someone else to handle Apple and Google. You submit from your own developer accounts.

How do you test a BigCommerce store as an app?

Use a real iPhone and a real Android phone if you plan to ship both, and note the page URL wherever something fails.

Step 1: Prepare accounts and payments

Create one test customer for each customer group that matters, plus a company user if you run B2B Edition. Put your payment gateway in test mode or set up a low-priced product you can refund. The storefront must be publicly reachable, so a store still behind a pre-launch preview code has to open first.

Step 2: Sign in and check what each account sees

Sign in as each test customer and compare with the same account on your website. Categories hidden from a group should stay hidden. Group discounts and price-list prices should match to the cent, because BigCommerce works them out on its servers either way. If your sign-up or password-reset form uses reCAPTCHA, which BigCommerce lets you switch on under its security and privacy settings, make sure the challenge appears and can be passed on a phone.

Step 3: Find products the way buyers do

Search by SKU and by name, apply filters on a large category, and open a product with options. Add it to the cart and watch the cart count.

Step 4: Run the B2B journeys

Skip this step if you don't use B2B Edition. Otherwise open the Buyer Portal and do what your buyers do most.

• Quick order: type three or four SKUs with quantities and add them to the cart. Try picking from previously purchased products.
• CSV upload: attempt a bulk upload. It depends on choosing a file stored on the phone, so decide whether it belongs in the app or stays a desktop task.
• Shopping lists: open a saved list and add it to the cart.
• Reorder: open a past company order and reorder it.
• Quotes and invoices: request a quote, then open one invoice.

Judge comfort as well as function. A table that needs sideways scrolling to reach the quantity field will not get used.

Step 5: Check out with every payment method

This step decides whether you can launch.

• Card fields in BigCommerce's checkout render in the page and 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.
• PayPal and pay-later providers open their own window or page. Follow the whole path and confirm you land on your order confirmation inside the app.
• Purchase order or pay on account, if you offer it to companies, should complete like any other method.
• Apple Pay and Google Pay buttons show only when the gateway's script decides the environment supports them. An in-app WebView isn't Safari or Chrome, so a button you see on the mobile web may be missing in the app. BigCommerce lists which gateways support Apple Pay in browsers other than Safari, and Google documents the requirements for Google Pay in Android WebView. Check both phones, and keep card payment available beside any wallet button.

Afterwards, check the order in your BigCommerce control panel: right customer, right group pricing, right status.

Step 6: Test the headless handoff

Skip this step on a Stencil theme. On Catalyst, the storefront sends the shopper to BigCommerce's hosted checkout through a session-sync redirect. BigCommerce's session sync documentation explains that the redirect carries a token, valid for 30 seconds, that transfers the cart and the customer session. Sign in on the storefront, add to cart, tap checkout, and confirm you arrive signed in with the same cart. Custom headless builds that use embedded checkout in an iframe need the same test on both phones.

Step 7: Close, reopen and tidy

Close the app completely and reopen it. You should still be signed in with your cart intact. If you use a social login app, try each button: Google blocks its sign-in screen in embedded WebViews, so email and password should always be offered.

Then dismiss the cookie banner and any newsletter pop-up, and check that your theme's sticky header 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 list anything you'd like removed.

What should the results tell you?

What should you set up in the app itself?

Use the native parts of the app to shorten the repeat order.

• Bottom tabs: a consumer store does well with Home, its strongest category, Cart and Account. A trade store should lead with Quick Order or Search, then Orders, Cart and Account. On a Stencil theme the cart lives at /cart.php and order history at /account.php?action=order_status.
• Cart badge: with a developer's help, the SiteTo.App JS SDK can show a count on the Cart tab by reading a URL on your storefront. On Stencil, BigCommerce's Storefront Cart API returns the current cart as JSON.
• Push: connect Firebase using the Firebase guide. Every opted-in user receives every message, so keep it to news that's relevant to all of them.
• One app per storefront: the app starts on one URL. If you run Multi-Storefront with separate domains for separate brands or regions, each storefront is its own app and its own build. Stores that show a currency based on the visitor's location should check the right one appears.

Product, price and stock changes show up in the app without a new build. Changing the icon, app name or other native settings needs a rebuild, and later rebuilds are quoted separately.

What do BigCommerce stores need to know before publishing?

You submit from your own Apple and Google accounts. SiteTo.App signs the iOS build and uploads it to TestFlight in your Apple account, so you need no Mac or Xcode, and gives you an AAB for Google Play. The create and publish guide walks through each step. Apple and Google decide what gets approved, and nobody can promise the outcome.

Give reviewers a way in. If prices or the whole catalog sit behind a login, supply a working test account in the review notes, in a customer group that shows a realistic catalog. A reviewer who can't get past a login wall can't approve the app.

Think about who the app is for. An app that only approved trade customers can use isn't aimed at the general public. Apple offers unlisted app distribution for apps meant for a limited audience, reached by a direct link and hidden from search. It's worth reading before you submit a wholesale-only app.

Physical goods use your own checkout. Apple's App Review Guidelines say goods and services consumed outside the app are paid for with methods other than in-app purchase (section 3.1.3(e)). Digital content used inside the app falls under different rules, so read section 3.1 if you sell any.

Offer account deletion. Apple expects any app that supports account creation to let people start deleting their account inside the app. If your account pages don't offer that, add a clearly labeled request form.

Show more than a website. Apple's Guideline 4.2 asks apps to offer more than a repackaged site, and native tabs, a native header and push notifications help. The Guideline 4.2 guide explains how to prepare, and the publishing guide covers listings, screenshots and privacy answers.

Common questions

Will sales reps be able to order for customers in the app?

B2B Edition lets a sales rep with the Super Admin role masquerade as a company in the storefront Buyer Portal and place orders for it. If your reps do that on the website today, the same pages load in the app. Test it with a rep account in the preview.

What happens when BigCommerce updates checkout or I change my theme?

The app shows the updated storefront the next time it's opened, with no new build. A theme change that breaks your mobile account area breaks it in the app at the same moment, so place a signed-in test order on a phone after significant changes.

Next step

Open your storefront on your phone, sign in as a trade customer and place a reorder. If that goes well, preview your BigCommerce store as an app for free, run the seven steps above, and check pricing once you know it works.