lunes, 20 de julio de 2026
Cómo Planeta Huerto reconstruyó seis componentes nativos de su página de producto para su app de Shopify

Planeta Huerto, un minorista español de alimentación saludable y ecológica en Shopify Plus, reconstruyó seis componentes de su página de producto basados en metafields como componentes nativos personalizados y mantuvo la lógica de su marketplace Mirakl. El caso demuestra que una página de producto muy personalizada puede funcionar en una app móvil, siempre que los datos y la lógica subyacentes estén disponibles.
Su catálogo codifica en metafields y metaobjetos los datos de vendedor, los precios por tramos, los filtros dietéticos y la lógica de colecciones. Para decidir entre construir o comprar, y entre una app nativa o una basada en una webview, consulta nuestra guía para convertir una tienda Shopify en una app móvil.
Los resultados tras pasar a nativo
Canal de la app frente a tienda online, primeros 90 días. Estos resultados se observaron después de que Planeta Huerto pasara de una app basada en una webview a una app nativa. Comparan la app con la tienda. No son una comparación controlada de antes y después. Para entender por qué esa distinción importa, consulta cómo leer las métricas de una app móvil.
+9 %
Valor medio del pedido, app frente a tienda
+47 %
Importe gastado por cliente, app frente a tienda
72 %
Tasa de recompra, canal de la app

«Todas las métricas de App Store se han disparado frente al rendimiento anterior, cuando usaban vistas web.»
Albert MiraDirector de Tecnología, Planeta HuertoLa objeción: "nuestro catálogo es demasiado personalizado para una app"
Planeta Huerto llegó a NAPPS desde una plataforma basada en una webview. Si no tienes claro si tu app funciona así, así puedes diagnosticarlo. El rendimiento no era suficiente para una marca cuyos clientes compran de forma recurrente, pero esa app tenía una ventaja: reproducía todos los componentes personalizados de la web.
Ahí estaba la trampa. Aquellos componentes de la web eran sofisticados, y cada uno funcionaba con lógica propia construida a partir de metafields, metaobjetos y cálculos específicos del negocio. Seis de ellos vivían solo en la página de producto. Además, Planeta Huerto tiene una integración con el marketplace Mirakl, así que un único catálogo mezcla productos que vende y envía directamente con productos de vendedores externos, cada uno con su propio vendedor y sus propias reglas de envío y entrega.
La elección puede parecer binaria: quedarte con una app basada en una webview o pagar una reconstrucción nativa completa. El equipo de Planeta Huerto esperaba que la reconstrucción costara entre 2 000 y 3 000 dólares al mes o que le obligara a simplificar la página de producto para encajar en una plantilla. Ninguna de las dos opciones servía al negocio. Los componentes existían por un motivo.
Los seis componentes se reconstruyeron de forma nativa y se incluyeron en el plan de Planeta Huerto en lugar de facturarse como desarrollo a medida de nivel enterprise.
Los seis componentes
La página de producto de Planeta Huerto tenía seis componentes distintos basados en metafields. NAPPS reconstruyó los seis como componentes nativos. Este artículo examina los tres con patrones que probablemente se puedan trasladar a otras marcas. El resto muestra el alcance del trabajo.
La división que importa es interfaz nativa nueva frente a interfaz existente con lógica personalizada encima. Haz esa distinción antes de empezar un desarrollo a medida. Para elegir una plataforma, consulta cómo evaluar una plataforma de apps de Shopify.
Dos se construyeron como interfaz nativa nueva: la tarjeta de aviso de vendedor y envío, y los tramos de descuento por cantidad. Uno reutilizó un componente nativo existente con lógica personalizada encima: el carrusel inteligente de productos. Los otros tres son las etiquetas de producto con lógica propia, el sello de producto ecológico de la UE y el añadir al carrito con estado.
El sexto componente, añadir al carrito con estado, cambia el botón para mostrar cuántas unidades de ese artículo hay ya en el carrito. Eso ayuda a quien compra en el marketplace a seguir sus artículos entre vendedores en un pedido mixto.

Análisis 1: la tarjeta de aviso de vendedor y envío
Muestra en la app el envío y la entrega de cada vendedor. Así los productos del marketplace tienen la misma información clara en la página de producto que el catálogo propio.

La tarjeta de aviso se sitúa en la página de producto y muestra el nombre del vendedor (enlazado a su colección), el coste de envío y una estimación de entrega. Lo difícil es que la estimación cambia con dos variables a la vez:
- Día de la semana. Si pides de lunes a jueves, sale al día siguiente. Si pides el viernes, sale el lunes. Si pides el fin de semana, sale el martes.
- Tipo de producto. Los productos propios siguen un cálculo de envío. Los del marketplace llevan otro vendedor y otras reglas de envío, extraídas de metafields de producto, metaobjetos de vendedor y la integración con Mirakl.
NAPPS hizo el componente reutilizable: admite un número ilimitado de elementos en lugar de tres o cuatro fijos, un icono por elemento y formato de texto enriquecido en el título y en los elementos. Otras marcas ya lo usan para certificaciones de producto, detalles de sostenibilidad y avisos de características.
Análisis 2: los tramos de descuento por cantidad
Mantén nativa la interfaz del descuento y deja que la marca aporte la lógica de precios. El tramo se actualiza sin una ida y vuelta a la web.

El componente muestra los tramos de descuento por volumen en la página de producto (compra 1 a precio normal, compra 3 y ahorra un 10 %, compra 5 y ahorra un 20 %) y anima a cestas más grandes al enseñar el ahorro con claridad. Lleva cuatro cosas de serie:
- Un número dinámico de tramos, de dos a diez, no tres fijos.
- Etiquetas como "El más popular" o "Mejor relación calidad-precio" en cualquier tramo.
- Seguimiento de la selección en vivo, para que el componente sepa qué tramo está activo mientras el cliente cambia la cantidad.
- Retornos de llamada al pulsar, que devuelven el evento a la lógica propia de la marca para recalcular el precio. La interfaz muestra los tramos; la marca es dueña de los cálculos. Esa separación permite que la misma interfaz nativa se apoye en reglas de precios completamente distintas según la marca.
El componente se combina con el añadir al carrito con estado. Al tocar un tramo se dispara un retorno de llamada que fija la cantidad y después actualiza el botón con las unidades que hay en el carrito. El comprador elige "compra 3, ahorra un 10 %" y ve cambiar el carrito sin recargar la página. Ese aviso resulta especialmente útil cuando un pedido mezcla artículos de varios vendedores.
Análisis 3: el carrusel inteligente de productos
Usa la estructura del catálogo para mostrar productos relacionados de forma automática. La marca aporta la lógica y reutiliza la interfaz existente.

Este componente reutilizó un carrusel que NAPPS ya tenía. La parte personalizada fue elegir qué colección mostrar. Planeta Huerto nombra las colecciones por su ruta de navegación, así que un producto puede estar en varias a la vez:
Inicio > Alimentación > Ecológico > VerdurasInicio > Alimentación > EcológicoInicio > Alimentación
El carrusel tira de Verduras, la colección más específica, en lugar de la amplia Alimentación. La lógica cuenta la profundidad de la ruta, selecciona la colección más profunda y lee el título de la fila desde un metafield personalizado en el idioma del comprador. Es un patrón habitual en desarrollos a medida: mantener la interfaz nativa existente y añadir lógica en TypeScript.
async onComponentCreated() {
// Every component already has the current product in scope.
const collectionIDs = product.collectionIDs;
// Fetch collections, including the custom metafield used for the display title.
const collections = await collectionService.getCollectionsByIDs(
collectionIDs,
["custom.show_title"]
);
// Collections are named by breadcrumb, e.g. "Home > Food > Organic > Vegetables".
const separator = " > ";
// Find the deepest (most specific) collection this product belongs to.
let stepsToProduct = 0;
let mainCollection: Collection | null = null;
for (const collection of collections) {
if (!collection?.title) continue;
const steps = collection.title.split(separator).length;
if (steps > stepsToProduct) {
stepsToProduct = steps;
mainCollection = collection;
}
}
// Guard: if no collection matched, leave the carousel untouched.
if (!mainCollection) return;
// Title the row from the custom metafield, in the shopper's language.
const title = mainCollection.metafields.custom.show_title;
this.updateState({
collectionID: mainCollection.id,
title: `Más productos de ${title}`,
});
}El fragmento usa tres capacidades de la plataforma que los componentes personalizados suelen necesitar:
- Contexto global de producto.
productya está disponible, así que un componente nunca tiene que volver a pedir el producto de la página. - Servicios de datos.
collectionService(junto aproductServiceymetaobjectService) lee datos de Shopify, incluidos los metafields con nombre, sin escribir llamadas a la API a mano. - Contexto de la app.
AppUtilsexpone valores de la app, como el país del comprador, que aquí se usa para decidir cómo debe leerse el título de la colección.
La nota honesta sobre la implementación
Este desarrollo llevó unas cuatro semanas, más que un lanzamiento típico de NAPPS. Planeta Huerto fue el primer cliente construido sobre Expresso, la capa de NAPPS que lleva React y TypeScript a nativo, así que el equipo amplió capacidades básicas de la plataforma durante la implementación.
Durante esas cuatro semanas, NAPPS amplió:
- El puente entre el código nativo (SwiftUI y Jetpack Compose) y la capa de React y TypeScript.
- Los servicios de lectura de datos de Shopify: colecciones, productos y metaobjetos.
- Capacidades que el equipo confirmó que necesitaba a mitad de proyecto, como la representación de texto enriquecido para la tarjeta de aviso, la carga dinámica de iconos, los retornos de llamada de eventos para los tramos de descuento y el formato según la configuración regional para el carrusel.
Las capacidades creadas para este proyecto se convirtieron en funciones reutilizables de la plataforma. Desde entonces, los desarrolladores de Planeta Huerto se han sumado al programa de acceso restringido de Expresso y crean directamente nuevos componentes nativos para la app.
Antes de planificar una migración, confirma quién es el propietario de las cuentas de desarrollador y qué se puede transferir de la app actual.
A quién le sirve esto y qué hacer a continuación
Planeta Huerto es relevante para catálogos complejos y de marketplace cuyas páginas de producto usan metafields, metaobjetos y vendedores externos. Una app nativa no tiene por qué encerrarte en plantillas. La lógica existente de la web puede trasladarse cuando la plataforma tiene los servicios, la capa de React y TypeScript y los componentes nativos que la sostienen.
Si crees que tu catálogo es demasiado personalizado para una app, empieza por mapear los datos y la lógica. Después identifica qué partes necesitan una interfaz nueva y cuáles pueden reutilizar un componente nativo existente.
Descubre cómo funcionarían los componentes nativos personalizados en tu marca. Reserva una demostración.
Preguntas frecuentes
Sí. Planeta Huerto tiene un marketplace Mirakl, así que un mismo catálogo mezcla productos que envía directamente con productos de vendedores externos, cada uno con su propio vendedor y sus propias reglas de envío y entrega. Todo eso se reconstruyó de forma nativa: avisos de envío y entrega por vendedor, enlaces de vendedor pulsables y un añadir al carrito con estado pensado para pedidos que mezclan varios vendedores. La lógica del marketplace se mantuvo intacta.
Sí. Cada uno de los seis componentes de la página de producto de Planeta Huerto funcionaba con lógica propia construida a partir de metafields, metaobjetos y cálculos específicos del negocio, desde los precios por tramos hasta la selección de colección por ruta de navegación. Se trasladaron combinando componentes de interfaz nativos con lógica personalizada en TypeScript encima, leyendo los datos de Shopify (incluidos los metafields con nombre) a través de los servicios de datos de la plataforma. Sin rediseño y sin renuncias por culpa de una plantilla.
No necesariamente. Planeta Huerto esperaba pagar entre 2 000 y 3 000 dólares al mes, o simplificarlo todo para encajar en una plantilla. En cambio, los seis componentes se reconstruyeron de forma nativa y se incluyeron en su plan, sin facturarse como desarrollo a medida de nivel Enterprise.
El de Planeta Huerto llevó unas cuatro semanas, más que un lanzamiento típico de NAPPS, porque fueron el primer cliente construido sobre Expresso (la capa de NAPPS que lleva React y TypeScript a nativo) y se ampliaron capacidades básicas durante el proyecto. Esas capacidades ya son funciones reutilizables de la plataforma, así que los desarrollos a medida posteriores parten de una base más completa.
No. Planeta Huerto pasó de una plataforma basada en una webview a una app nativa y vio mejorar sus métricas de app frente a tienda en todos los frentes. Una migración así sustituye lo que funciona dentro de la app, de modo que conservas tu ficha de App Store, tus valoraciones y tu base de instalaciones en lugar de relanzar desde cero.
Sí. Tras el desarrollo inicial, los propios desarrolladores de Planeta Huerto se sumaron al programa de acceso restringido de Expresso y ahora crean directamente nuevos componentes nativos para la app.
Seguir leyendo

27 de octubre de 2026 - 10 min de lectura
4 alternativas a MobiLoud para Shopify: precios y encaje




23 de octubre de 2026 - 8 min de lectura
Tapcart vs Shopney: precios, funciones y cuál encaja con tu tienda Shopify




18 de septiembre de 2026 - 13 min de lectura
Alternativa a Tapcart: NAPPS, precios, funciones y migración


