Planeta Huerto, From Webview to Native: Every Metric Improved, at Marketplace Scale

"Every App Store stat is exploding compared with past performance from when they were using web views."

Albert MiraCTO, Planeta Huerto

About Planeta Huerto

Planeta Huerto is a Spanish health and organic food retailer on Shopify Plus, with one of the largest and most complex catalogs in its category. Product pages are heavily data-driven: vendor information, tiered pricing, dietary filters, and collection logic are all encoded in metafields and metaobjects. On top of that, Planeta Huerto runs a marketplace through Mirakl, so a single catalog mixes products it sells and ships directly with products from third-party sellers, each with its own vendor, shipping, and delivery rules.

The Problem

Planeta Huerto's app needed to feel native, on a marketplace catalog most app builders can't even model.

Planeta Huerto's website is genuinely well optimized. The problem with a webview app isn't the site it loads; it's that a webview wraps that site in a native shell, and the two interaction models fight each other. Native gestures like swiping, scrolling, and the system back gesture collide with the website's own navigation and gestures, so the app feels off in a way customers notice even when every page renders correctly.

Underneath that sat the harder objection for any complex retailer: no app builder can rebuild what we've encoded in our theme, let alone our marketplace logic. Planeta Huerto's product pages carry six distinct metafield-driven components, and a Mirakl marketplace runs under the whole catalog. They needed native components with full access to metafields and metaobjects, native handling of marketplace versus direct products, and an interaction model that behaves like an app instead of fighting one.

There was a second fear, about cost. Planeta Huerto knew exactly how much work their team had put into these components on the website, and assumed a platform would either charge enterprise custom-development rates to rebuild them, somewhere around $2,000 to $3,000 a month, or make them simplify everything to fit a template. Neither was acceptable. The components existed for a reason.

The Solution

NAPPS rebuilt every product-page component natively on Expresso, and Planeta Huerto became the first customer to run on it, and the first to prove it at scale.

Expresso is NAPPS's React-and-TypeScript-to-native layer: it turns React and TypeScript into real SwiftUI and Jetpack Compose components, not web embeds. Planeta Huerto was the first customer built on Expresso, and their catalog was its first real stress test. A large, metafield-heavy, marketplace catalog is the kind of workload that exposes a webview app's limits, and a demanding first test for a fully native platform. If Expresso held up here, it would hold up anywhere.

Two things made the rebuild work:

1. Full metafield and metaobject access. Every piece of product data Planeta Huerto had encoded in its theme was available to native components, so nothing had to be simplified or dropped to fit the app.
2. Native marketplace handling. The app pulls marketplace data from both product metafields and the Mirakl integration, and renders marketplace and direct products correctly: the right vendor, the right shipping cost, and delivery estimates that change by seller type and day of week. The marketplace stopped being something the app had to hide inside a web page.

It did this without forcing a choice on price. All six components were included in Planeta Huerto’s plan, not billed as enterprise custom development, which answered the fear that this much customization would cost several times more or have to be cut down. And not everything needed new design: two of the three hardest components (the callout card and the quantity-discount tiers) were new native UI, while the third (the smart carousel) reused an existing NAPPS component with Planeta Huerto's own logic written on top. Custom logic on shared UI where possible, new UI only where the interaction genuinely didn't exist, is how the build stayed efficient.

Implementation reality: this took about four weeks, longer than a typical NAPPS launch, and the honest reason is that Expresso didn't fully exist yet. NAPPS was building the platform while building Planeta Huerto's app: the bridge between native code and the React and TypeScript layer, the services for reading Shopify data (collections, products, metaobjects), and APIs the team only discovered it needed mid-project, like rich-text rendering for the callout card. Planeta Huerto was patient and trusted the process. Everything built here (the bridge, the services, rich text, dynamic icons, event callbacks, locale-aware formatting) became part of the platform and now ships to every NAPPS customer. Nothing was a one-off hack; each piece was built to ship again.

"We had years of logic built into our product pages, and a marketplace on top of it. We expected an app to flatten all of that. Instead every component came back native, our marketplace included, and the App Store numbers moved the moment we switched."

Albert MiraCTO, Planeta Huerto

The Strategy / The Plays

Rebuild everything your theme does with metafields as native components, marketplace logic included.

1. Vendor & Shipping Callout Card (new native component, built in 5 days). Shows the vendor name (clickable, linked to the vendor's collection), the shipping cost, and a delivery estimate that changes with the calendar: order Monday to Thursday and it ships next day, order Friday and it ships Monday, order on the weekend and it ships Tuesday. It also reads whether a product is direct or marketplace and applies the right vendor and shipping rules for each, pulling from product metafields, vendor metaobjects, and the Mirakl integration. NAPPS built it flexible on purpose: unlimited items, any icon, rich-text formatting. The play for any Mirakl or multi-vendor operator: render per-seller shipping and delivery natively so marketplace products feel first-class. The same component now carries certifications (Organic, Fair Trade), sustainability info, or product features for other brands.
2. Quantity Discount Component (new native component, built in 4 days). Shows bulk-discount tiers on the product page (buy 1 regular, buy 3 save 10%, buy 5 save 20%) with a few things baked in: a dynamic number of tiers (2 to 10, not a fixed 3), tags like “Most Popular” on any tier, live selection tracking, and click callbacks that hand the event back to the brand’s own logic to recalculate. The play: keep the UI native and standard, but let each brand wire its own pricing logic underneath, so the discount updates instantly with no web round-trip.
3. Smart Product Carousel (existing UI, custom logic, built in 1 day). This one reused a carousel NAPPS already had; what was custom was the logic for picking which collection to show. Planeta Huerto's collections are named by breadcrumb (Home > Food > Organic > Vegetables), and a product can sit in several at once. The logic counts the breadcrumb depth, surfaces the most specific collection, and titles the row from a custom metafield in the shopper's language. The play: use your own catalog structure to auto-merchandise related products, with no manual curation, on UI you didn’t have to design.

The Results

Every tracked metric improved after the switch from a webview app to a genuinely native one.

The gains didn't come from a new growth strategy. They came from rebuilding the same product pages as native components: the marketplace included, and every gesture, transition, and navigation working the way customers expect on their phone instead of fighting the app.

Conclusion

Planeta Huerto is the case for complex and marketplace catalogs: brands whose product pages run on metafields, metaobjects, and third-party sellers, and who assume no app builder can match that without enterprise pricing or heavy compromise. It is also the proof that Expresso holds up at scale, because this is where it was built. Native doesn't mean locked into templates, and if your website logic works, it can transfer: the challenge was never the complexity, only having a platform with the services, the React and TypeScript layer, and the native components to carry it. If your objection is “our catalog is too custom for an app,” this is what it looks like when it isn’t.

The relationship keeps deepening. The components NAPPS built here now ship to every customer, and Planeta Huerto's own developers have since joined Expresso's closed-access program: they now build new components made specifically for the app, and publish them on the fly, without waiting on an app store review cycle. What started as a migration has become a platform the brand's team builds on directly.