The best app builder for ecommerce is decided by one question: physical goods or digital goods.
Pick the builder that matches what you sell, because the store rules split exactly there. Ship physical products and both Apple and Google keep their billing systems out of the sale, so no store commission touches the order and almost any builder that can take a card will do. Sell digital goods that get used inside the app and store billing is compulsory on both platforms, which changes your margin before you have compared a single feature. Settle that first and the rest of building an ecommerce app gets much simpler.
The short recommendation, with the reasoning underneath it. If your catalogue already lives on Shopify, a Shopify native app builder is the fastest honest answer, and Tapcart's pricing page lists its entry plan at $500 a month. If you are starting from nothing with a small catalogue, an all in one ecommerce app builder such as GoodBarber gives you the shop, the app and the hosting in one subscription. If the app has to do something your commerce platform cannot do, buy nothing and generate the code instead. Three different answers to one question, and the deciding factors are below.
Find the builder that fits your storeThe short version
Two things decide this, and only one of them is software.
The first is what the customer is buying. Apple's guideline 3.1.3(e) says physical goods and services consumed outside the app must not go through in-app purchase. Google's payments policy lists physical goods and physical services among the purchases its billing system does not support. So a store app that ships parcels runs on your own payment processor, pays that processor's rate, and pays the stores nothing on the order. A digital goods app is the mirror image: store billing is required, and the fee is a line in your margin rather than a negotiation.
The second is how much of the app is not shopping. Browse, cart, checkout and order history are solved problems, and a packaged builder will get you there in days. Anything past that, such as shelf scanning, a driver handoff, trade reordering, or a loyalty scheme your platform does not model, is where packaged builders start charging for developer tooling and where owning the code starts to pay for itself. Be honest about which of those two apps you are building.
What Apple and Google require, and where the wording differs
Start with Apple, because the sentence is unusually clear. Guideline 3.1.3(e), headed Goods and Services Outside of the App, says that if your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry. That is an instruction, not permission. Putting a shipped order through in-app purchase is a rejection waiting to happen, not a clever shortcut.
The other half is guideline 3.1.1. If you want to unlock features or functionality within the app, and Apple's own examples are subscriptions, in-game currencies, game levels, access to premium content and unlocking a full version, you must use in-app purchase, and apps may not use their own mechanisms such as license keys or QR codes instead. The dividing line is consumption. If the customer uses the thing inside your app, Apple's payment system handles it. If it arrives by courier or happens in the world, yours does.
Google gets to a similar place by a different route. Its payments policy opens by saying Google Play's billing system is required for developers offering in-app purchases of digital goods and services, then lists what the billing system does not support: purchases or rentals of physical goods such as groceries, clothing, home appliances or electronics, and purchases of physical services such as transportation, airfare, gym memberships or food delivery. Apple commands, Google excludes, and for a parcel shipping shop the effect is identical. That is also why the commission question has a boring answer. Apple's commission attaches to paid apps and in-app purchases, Google's service fee attaches to transactions made through Play billing, and a physical order goes through neither. The same arithmetic is why a shop and a service business end up on different tools, which is the subject of the best app builder for small business comparison.
Apple, App Review Guidelines, guidelines 3.1.1 and 3.1.3(e), last updated 8 June 2026
Gift cards, bundles and loyalty points break the simple version
A gift card screen is where the two rule books stop agreeing. Apple's guideline 3.1.1 says digital gift cards, certificates, vouchers and coupons which can be redeemed for digital goods or services can only be sold in your app using in-app purchase, while physical gift cards sold within an app and then mailed to customers may use payment methods other than in-app purchase. Google answers the same question in one line: its billing system is not required for the sale of in-app gift cards, regardless of whether the card is an eGift or physically mailed to the user. One feature, two builds.
Bundles are the second trap. Google publishes a test for them. Play billing must be used for the SKUs in your app that include more digital goods or services than physical goods or services, and for the SKUs marketed to users as digital goods or services. Apple publishes no equivalent test in guideline 3.1, so a product that mixes a shipped item with a digital one is a question for App Review rather than a line you can look up before you build. If you plan a bundle like that, design the checkout so the two halves can be split apart, because one of the two stores may make you.
Loyalty points have a rule worth knowing before you promise them. Google says earned or awarded points can be issued in the app, and exchanged in the app for digital goods, without its billing system, but points sold in the app must use it. Steering has limits too. Google says that within an app, developers may not lead users to a payment method other than Play billing unless named sections of the payments policy apply, and Apple's guideline 3.1.3 opens by saying apps in that section cannot encourage users to use a purchasing method other than in-app purchase, with exceptions for the United States storefront and the link entitlements. None of that blocks a shipped goods checkout. All of it blocks the workaround. What it means for your build is in add payments.
Google Play Console Help, Understanding Google Play's Payments policy
Which builder fits which kind of store
If your products, prices, stock and checkout already live on Shopify, the app is a new front end on a system that works, and the fastest route is a builder that does only that. Tapcart's site says it currently supports ecommerce stores built on Shopify, and nothing else. Its pricing page lists Growth at $500 a month, Scale at $1,250 and Enterprise+ at $2,850, and adds that every plan still needs your own Apple and Google developer accounts. That is real money, and it is the honest filter. At $500 a month the app has to produce about six thousand dollars of extra margin a year before it has paid for itself. For a brand with repeat buyers that is easy. For a shop with forty customers it is not.
If you have no commerce platform yet, an all in one builder removes the integration entirely. GoodBarber sells a separate ecommerce plan starting from 40 euros a month billed yearly, with a 30 day free trial and no credit card, and its pricing page says the subscription covers hosting, push notifications, payments and updates with no third party services to add. Adalo is the cheaper general purpose option: its pricing page puts app store publishing from $36 a month, produces native iOS and Android builds, and lists Stripe payments for collecting money inside the app. Both put a working shop in front of customers without anyone writing code.
The third group hands you a codebase. FlutterFlow's pricing page puts source code download and APK download on its Basic plan at $39 a month, and GitHub integration on Growth at $80 for the first seat, so you can start in a visual editor and leave with a Flutter project. AI builders that write the project outright belong in the same group. What you give up is the shop. None of these arrive with a catalogue, a cart or an order admin, so either your commerce platform supplies those through an API or somebody builds them. What you gain is that nothing in the app is a plugin slot.
So take the case against that third group seriously, because for most shops it wins. If what you need is a catalogue, a cart, a checkout and push notifications, a packaged builder does it faster, cheaper and with fewer decisions, and the subscription buys you store submissions that somebody else maintains. Choose a generated project only when you can name the feature the packaged tools cannot do. The chooser below asks the same three questions in a different order.
Narrow it down
Three questions, one shortlist
What you sell
Where the catalogue lives
What the app has to do
A Shopify native app builder
Your catalogue, checkout and orders already work. Tapcart says it supports Shopify only, and its pricing page lists the Growth plan at $500 a month.
When the app is more than a storefront
Most ecommerce apps that earn their place are not shopping apps. They are a shop plus one thing: a scanner that checks stock on the shelf, a pickup flow for click and collect, a driver screen for local delivery, a reorder button for trade customers who buy the same twelve items every month, a loyalty scheme the platform does not model. The shopping half is a commodity. The one thing is the product, and it is the part no builder sells you.
That is also the test for whether to own the code. A packaged builder is a rented set of screens, and the moment your one thing does not fit the available blocks you are either buying developer tooling at the top of the price list or waiting on a roadmap. A generated project has no blocks, it has files. Any developer you hire can read them, and the app does not stop being yours when the subscription stops.
One note on money, because it decides more than the tooling does. Neither store takes a cut of a shipped order, so what you keep is the order value minus your payment processor's rate, and Shopify's pricing page lists online card rates from 2.9 percent plus 30 cents on its Basic plan at $39 a month. Add a digital product, a membership or an in-app upgrade and store billing applies to that item instead. Work the numbers out before you design the pricing, and read selling inside the app if the app will carry more than one kind of product.
What the stores do with each kind of sale
| What the customer is buying | Apple's rule | Google Play's rule | Store cut on that sale | What your builder has to support |
|---|---|---|---|---|
| A physical product shipped to them | 3.1.3(e): must use a method other than in-app purchase | Physical goods listed as not supported by Play billing | None | Card entry or Apple Pay through your own processor |
| A service used outside the app, such as delivery or a class | 3.1.3(e) again, the same instruction | Physical services listed as not supported by Play billing | None | The same checkout as a product order |
| Digital content or a feature unlocked inside the app | 3.1.1: in-app purchase required, no other mechanism | Play billing required for digital items and app functionality | Apple commission on in-app purchase, Play service fee | Real in-app purchase and Play Billing support |
| A gift card | Digital card for digital goods: in-app purchase only. Physical card mailed out: other methods allowed | Not required for in-app gift cards, eGift or mailed | Follows whichever billing path is used | Two paths on iOS, one on Android |
| A bundle of a shipped item and a digital one | No mixed bundle test published in guideline 3.1 | Play billing if the SKU is more digital than physical, or marketed as digital | Depends on the path taken | A checkout that can split the halves apart |
Building the app when the shop is only half of it
Newly is an AI app builder. You describe the app in plain English and it writes a real React Native and TypeScript project that you own, runs it on cloud iOS and Android simulators while it builds, then ships it to TestFlight and to Google Play internal testing. It is $25 a month and there is no free plan. The code leaves as a ZIP from project Settings, through the two way GitHub sync under Deploy, or with the CLI, so an agency or a contractor can pick the project up later without going through us.
The honest limit for an ecommerce reader: there is no storefront. No catalogue module, no cart component, no checkout to switch on. The payments that are built in are subscriptions and in-app purchases, through a Connect RevenueCat card, which is the wrong rail for selling physical goods. New apps start local first, keeping their data on the phone with no accounts and no server, and the agent adds a backend with sign in, an API service, a Postgres database per environment and file storage only when the app needs accounts, shared data, syncing or payments. If you want the shop handed to you on day one, an all in one ecommerce builder or a Shopify native one is the better buy, and that is most shops.
Where this trade works is the app that is a shop plus something. The catalogue comes from the commerce platform you already pay for, the checkout stays with the processor you already use, and the part nobody sells you, the shelf scanner, the pickup queue, the trade reorder screen, gets written to fit the way you actually work. That is also the version of the app that is still yours in two years.
Questions people ask about ecommerce app builders
There is no single winner, because the shape of your store decides it. If your catalogue is on Shopify, a Shopify native builder is the shortest route, and Tapcart's pricing page lists its Growth plan at $500 a month. Starting from scratch with a small catalogue, GoodBarber sells an ecommerce plan from 40 euros a month billed yearly, and Adalo's pricing page puts app store publishing from $36 a month. If the app has to do something your platform cannot, generate the code and own it.
Decide what you sell, then build the half nobody sells you
Write one line: what the customer buys, and where they use it. That answer picks your payment path and cuts the builder list to two or three. Then build the part of the app that is actually yours.
Start building