"Add to Home Screen" looks like an app until a customer never gets a push, checkout feels like the mobile site, or iOS quietly caps what your "app" can do.
If you run an ecommerce brand with most traffic on mobile, you have heard the pitch: wrap the site, ship a progressive web app, skip the stores. On paper it is clean. In the cart and the reorder loop, iOS still draws hard lines.
This is not a framework war. It is an operator check. What a progressive web app on iOS actually delivers for commerce, where Safari and Apple policy still cut you off, and when native is the conversion lever instead of a nice-to-have icon.
What a PWA actually is for an online store
A progressive web app is your site with extra browser features: a manifest, a service worker, offline or cached shells, and the option to pin it to the home screen. On Android, that package can feel close to an installable app. On iPhone, it is still mostly Safari in a standalone window.
For ecommerce that means:
One codebase you already maintain (the storefront)
No App Store or Play review cycle for every copy tweak
Faster "we have an app" story for leadership decks
None of that is useless. It is also not the same product as a native iOS and Android app that owns session, push, and checkout. If someone sells you a website wrapper and calls the gap "implementation detail," treat that as a buying signal, not a footnote.
What iOS still will not give your PWA
Apple has improved bits of home-screen web apps over the years. The conversion-relevant gaps for retail are still real.
Reliable push and reactivation
Reactivation is where mobile revenue hides after the first order. Email reach keeps shrinking. SMS costs stack up. Push is how you show up for shipping updates, back-in-stock, and cart recovery without paying a carrier tax every time.
On iOS, web push for home-screen PWAs has been limited, late, and easy to oversell in vendor decks. Native apps sit in a mature permission and delivery path customers already understand from the apps they use daily. If your retention plan assumes "we will just push from the PWA like Android," run that assumption against current iOS behavior before you bet a channel on it. For how push compares to email on reactivation math, see push notification strategies for ecommerce and our notes on permission rates you can defend.
Background updates and fresh catalog truth
Service workers help with shells and assets. They do not turn a heavy catalog, layered promos, and personalized merchandising into an always-fresh native storefront. Under real SKU count and peak traffic, "app-like" caching can serve stale price or stock if you are not ruthless about invalidation. Native clients and a proper API contract give you clearer control over what is offline-tolerant and what must be live.
Store distribution and trust
App Store and Play listing are friction. They are also distribution and trust. A home-screen flow depends on education ("tap Share, then Add to Home Screen"). Completion drops. A store listing is a place customers already search when they type your brand plus "app."
That matters when you care about habitual reopen, not a one-time pin after a coupon. More on why the icon habit matters in home-screen commerce.
Payment and checkout UX
Mobile checkout dies on friction: logins, OTP handoffs, lost cookies, clunky wallets. A PWA that is still your responsive checkout inside a standalone browser chrome inherits that tax. Native patterns (persistent session, biometric reopen, tighter wallet flows) are why brands see conversion lift when the app is a real client, not a bookmark.
We break down where in-app webviews quietly reintroduce the same tax in native checkout vs in-app webview. The short version: if checkout is still "the website inside a box," you did not buy a new conversion surface. This piece stays on the PWA and iOS policy line. That one is about what happens after you already claimed you shipped an app.
Performance under catalog weight
Demo PWAs with a handful of products feel snappy. Your production catalog, scripts, tag manager, and personalization layers are a different animal. Native apps do not magically erase bad data modeling, but they stop you from shipping the entire marketing site stack into every session.
For brands already watching mobile CVR lag desktop by a wide gap, that difference shows up in time-to-product and checkout start rate. The wider pattern is in why your mobile site converts at a fraction of a native app: same assortment, different container and session model.
When a PWA is the honest choice
Native is not always the answer. Say so out loud.
A PWA (or a sharp mobile web experience) is enough when:
Purchase is mostly one-off or very low frequency (low repurchase, weak loyalty loop)
Budget and headcount cannot support store releases, push governance, and ongoing optimisation
Content and browsing matter more than logged-in commerce (editorial, light catalog)
You need a bridge while you prove demand for installs
In those cases, spend on site speed, guest checkout, and clearer merchandising before you buy any "app" label. Wrapping a slow store in a home-screen icon does not fix conversion. It decorates the problem.
When native wins for ecommerce
Native pulls ahead when the business model needs repeat purchase and low-cost reactivation:
You already see 70%+ mobile traffic and mobile CVR well below desktop
Customers reorder (beauty, fashion, consumables, specialty retail)
You need push as a primary lifecycle channel, not a science project
You want home-screen commerce with session continuity, not a shortcut to the same browser stack
You care about LTV and reactivation cost, not only first-touch CPA
On our book, brands that treat the app as a growth surface (not a mirror of the site) see on the order of +34% conversion and about x2.8 LTV in-app versus responsive ($85 vs $30 in the proof set we use with operators). Time spent can run around x10 versus the mobile site when the product is used as a habit, not a coupon trap. Push open rates around 45% beat typical email by a wide margin, which is why reactivation cost can drop about 20% when the channel is run properly.
Those are operating outcomes. They are not a claim that "PWA bad, native good" in the abstract. How the LTV math shows up in practice is covered in how native apps lift customer lifetime value.
Notino-scale proof (7M downloads, about €1.2B GMV class) is the extreme end. The pattern still holds for mid-market: install is vanity until reopen, permission, and second order move. See client results when you want the case path.
Buying questions if a vendor wraps your site and calls it an app
Website-to-app positioning is crowded. Some tools are honest about being a wrapper. Others blur PWA, WebView, and native until the demo reel finishes. Before you sign:
What runs checkout? True native checkout screens, or your mobile site in a webview?
What works on iOS day one for push? Ask for the exact permission flow and delivery path on current iOS, not Android screenshots.
Who owns store breaks? When Apple or Google change rules, is the fix in your subscription or your backlog?
What is offline vs live? Price, stock, cart, and login should have a clear answer.
What do you optimise weekly? If the answer is only "theme and push templates you edit yourself," you bought a builder, not a growth partner. The split is the same one we use in managed vs DIY builders.
How do you measure incremental revenue? Channel shift from mobile web to app is not automatic profit. Force a clean read on new vs shifted GMV.
If the pitch is "your website, in the stores, next week," assume you are buying distribution cosmetics until those answers are specific.
Proof lens: judge the container by operator metrics
Skip the architecture religion. Put three numbers on a single slide:
Mobile web CVR vs desktop CVR (same period, same country)
Reorders per buyer and days-to-second-order
Email reach and cart recovery rate on mobile
If mobile is most of traffic, CVR is a fraction of desktop, and repurchase is real, you have a container and retention problem. A home-screen PWA might chip at branding. A managed native app is built to attack CVR, push reactivation, and LTV in one product surface.
ConvertNative designs, ships, and optimises that surface with brands on Shopify, WooCommerce, PrestaShop, and Magento, typically in production in four to six weeks on a subscription, not an indefinite IT program.
What to do next
Map your last 90 days: mobile share, mobile CVR vs desktop, push or SMS spend, and second-order rate. If iOS customers are a big slice of revenue and you are still planning reactivation like it is 2018 email, a PWA-only plan will not close that gap.
If you want a straight read on whether native is worth it for your stack, book a free mobile app audit. We will tell you when mobile web or a PWA is enough. We will also tell you when it is not.