Native, WebView or PWA: what a WooCommerce app really is

Search “WooCommerce app builder” and every result on the page says the word native. It is the most abused word in the category, because there is no badge, no certification, and nothing in an app listing that tells a shopper — or a store owner evaluating vendors — which of three very different things they are looking at.

The three architectures are genuinely different. They fail differently in App Review, they feel different in the hand, and they cost different amounts of money over a year. Here is how to tell them apart before you pay anyone.

The three things a “store app” can be

A WebView wrapper is a native shell containing one browser view pointed at your website. The shell provides the app icon, the splash screen, and usually push notifications. Everything inside — product grid, product page, cart, checkout — is your website, rendering in a hidden browser. Tap a category and a web page loads.

A progressive web app (PWA) is your website plus a service worker and a manifest, so a mobile browser offers to add it to the home screen. There is no app bundle, no App Store listing, and no install from a store — the “install” is a bookmark with an icon and offline caching.

A native app renders its own screens with the operating system’s own UI toolkit, and gets its data from an API. There is no web page behind the product grid. A category tap changes a screen that already exists in memory instead of fetching a document and laying it out.

Most products in this market are a blend, and the blend is the whole story. The honest question is never “is it native?” but “which screens are native, and which ones are a browser?”

How to tell from the outside, in ninety seconds

You do not need the vendor’s answer. Install any app built with the tool — most vendors have a demo — and run these four checks:

1. Scroll a long product list and stop hard. Native scrolling has platform-specific rubber-banding at the edges and momentum that matches every other app on the phone. A WebView scrolls like a web page, because it is one.
2. Turn on airplane mode and reopen the app. A native app shows the last state it had, or a real empty state it designed. A wrapper shows a browser error page, sometimes a dinosaur.
3. Long-press a product image. A web page offers “Open in new tab” / “Copy link address”. A native image does not, because it is not a link.
4. Watch the transition between the catalog and a product. A page load — a flash of white, a progress line at the top, text arriving before images — is a browser. A native push transition animates a screen in.

Any vendor whose demo fails checks 1, 2 and 4 is selling a wrapper with native trim around it. That is not necessarily a scam; it is a real product category with real customers. It is just not the same thing, and it carries a different risk.

Why the architecture decides your App Review risk

Apple’s Guideline 4.2 — Minimum Functionality — asks whether an app includes features, content and UI that “elevate it beyond a repackaged website.” A WebView wrapper is, definitionally, close to that line, and wrapper vendors’ own documentation is full of advice about adding native features to improve approval odds. We wrote about the specifics in why Apple rejects wrapper apps.

Guideline 4.2.6 is the second, sharper one, and it catches a different vendor model entirely: apps “created from a commercialized template or app generation service” are rejected unless they are submitted by the content provider — that is, by you, under your own developer account. Any vendor who publishes your app under their own account has built you a 4.2.6 problem, no matter how native the rendering is.

A PWA sidesteps review altogether, because there is nothing to review. That is its advantage and its ceiling: no App Store listing, no Play listing, no store search traffic, and on iOS a set of platform limits on notifications and background behavior that change with the operating system and are outside your control.

The part nobody should be native — and the part everyone should

Here is where honest architecture beats marketing. In a WooCommerce store app, the screens that decide whether people buy are the browsing screens: home, category, search, filters, the product page with its gallery and variation picker, the cart, the wishlist, order history. Those should be native, because they are where every tap happens and where slowness is felt as friction.

The final payment step is the one screen that should stay on your store. Your gateways, your settlement account, your fraud rules, your 3-D Secure flow, your PCI scope — all of it already works, and re-implementing it inside an app means re-implementing the riskiest software in your business.

That is how StoreToNative is built, and we say it plainly: the storefront is rendered natively from your store’s live data, the cart and an optional address-and-shipping step are native, and then the payment itself runs on your store’s own secure checkout pages with your own gateways. It is a semi-native checkout by design. Because you are selling physical goods, Apple’s in-app purchase system is not required for that transaction, so you keep 100% of the sale.

Compare that with what a WebView product means by “checkout”: one vendor’s own WooCommerce page states that the final checkout screen in their app is loaded in a WebView — which sounds identical until you notice that in their case the catalog is the part that varies, and in ours the browser only ever appears once, at the payment step, after the shopper has already decided.

What each one costs you over a year

Architecture shows up on the invoice in ways the sticker price hides:

• Wrappers are cheap monthly (single digits to low tens) and expensive in resubmissions, added “native feature” upsells, and the day a platform tightens WebView rules.
• Managed WebView services remove the work and charge for it — one runs $1,499/month on its Business plan for up to 10,000 monthly active users, plus $50 per additional 1,000. Predictable, and priced like an agency retainer.
• PWAs are nearly free and cost you the store listings, which is where a meaningful share of app installs come from.
• Native builders sit in between: StoreToNative is $29, $79 or $249 a month depending on plan, with a 14-day free trial, and the platform fees are the same for everyone — $99 a year to Apple, a one-time $25 to Google.

The number that actually matters is not the monthly. It is the monthly plus the cost of being wrong: a rejected submission is weeks, and a rebuild is a project.

Choosing, in one paragraph

If your catalog is small, your margins are thin, and you mainly want a home-screen icon, a PWA is a legitimate answer and costs almost nothing. If you need App Store and Play listings and you want the browsing experience to feel like the other apps on your customer’s phone, you want native rendering with checkout on your own gateways. And if a vendor cannot tell you, screen by screen, which of the two things each screen is — that answer is itself the answer.

Related reading

• Why Apple rejects wrapper apps — and how a native storefront avoids Guideline 4.2
• Over-the-air updates, explained
• From store to first build
• 12 store-readiness checks before you launch

Want to see which category your own catalog lands in? Start a 14-day trial, connect your store, and run the four checks above on your own app.