Planeta Huerto, del webview a lo nativo: todas las métricas mejoraron, a escala de marketplace

«Todas las métricas de App Store se han disparado frente al rendimiento anterior, cuando usaban vistas web.»

Albert MiraDirector de Tecnología, Planeta Huerto

Sobre Planeta Huerto

Planeta Huerto es un retailer español de salud y alimentación ecológica en Shopify Plus, con uno de los catálogos más grandes y complejos de su categoría. Sus páginas de producto se apoyan intensamente en datos: la información de cada proveedor, los precios por tramos, los filtros dietéticos y la lógica de colecciones están codificados en metafields y metaobjects. Además, Planeta Huerto opera un marketplace con Mirakl, de modo que un mismo catálogo mezcla productos que vende y envía directamente con productos de vendedores externos, cada uno con sus propias reglas de proveedor, envío y entrega.

El problema

La app de Planeta Huerto debía sentirse nativa sobre un catálogo de marketplace que la mayoría de los creadores de apps ni siquiera puede modelar.

La web de Planeta Huerto está realmente bien optimizada. El problema de una app de webview no es la página que carga, sino que envuelve esa web en una carcasa nativa y ambos modelos de interacción compiten entre sí. Los gestos nativos, como deslizar, hacer scroll o volver atrás con el gesto del sistema, chocan con la navegación y los gestos de la propia web. Por eso la app se siente extraña, algo que los clientes perciben aunque todas las páginas se rendericen correctamente.

Por debajo estaba la objeción más difícil para cualquier retailer complejo: ningún creador de apps puede reconstruir lo que hemos codificado en nuestro tema, y mucho menos nuestra lógica de marketplace. Las páginas de producto de Planeta Huerto incorporan seis componentes distintos basados en metafields, y todo el catálogo se apoya en un marketplace de Mirakl. Necesitaban componentes nativos con acceso completo a metafields y metaobjects, un tratamiento nativo de los productos de marketplace y de venta directa, y un modelo de interacción que se comportara como una app en vez de luchar contra ella.

Había un segundo temor: el coste. Planeta Huerto sabía exactamente cuánto trabajo había invertido su equipo en estos componentes de la web y asumía que una plataforma cobraría tarifas de desarrollo a medida para empresa —entre 2.000 y 3.000 dólares al mes— o les obligaría a simplificarlo todo para encajarlo en una plantilla. Ninguna de las dos opciones era aceptable. Los componentes existían por una razón.

La solución

NAPPS reconstruyó de forma nativa todos los componentes de la página de producto con Expresso, y Planeta Huerto se convirtió en el primer cliente en utilizarlo y en demostrar que funcionaba a escala.

Expresso es la capa de NAPPS que lleva React y TypeScript a código nativo: convierte React y TypeScript en componentes reales de SwiftUI y Jetpack Compose, no en contenidos web embebidos. Planeta Huerto fue el primer cliente construido con Expresso y su catálogo, la primera prueba de estrés real. Un catálogo grande, de marketplace y cargado de metafields es el tipo de carga que expone los límites de una app de webview y una prueba exigente para una plataforma totalmente nativa. Si Expresso funcionaba aquí, funcionaría en cualquier sitio.

Dos cosas hicieron posible la reconstrucción:

1. Acceso completo a metafields y metaobjects. Todos los datos de producto que Planeta Huerto había codificado en su tema estaban disponibles para los componentes nativos, así que no hubo que simplificar ni eliminar nada para encajarlo en la app.
2. Gestión nativa del marketplace. La app obtiene datos de marketplace tanto de los metafields del producto como de la integración con Mirakl y muestra correctamente los productos de marketplace y de venta directa: el proveedor adecuado, el coste de envío correcto y estimaciones de entrega que cambian según el tipo de vendedor y el día de la semana. El marketplace dejó de ser algo que la app debía esconder dentro de una página web.

Todo ello sin obligarles a elegir en función del precio. Los seis componentes estaban incluidos en el plan de Planeta Huerto, no se facturaron como desarrollo a medida para empresa. Eso disipó el temor de que tanta personalización costara varias veces más o tuviera que recortarse. Además, no todo requería un diseño nuevo: dos de los tres componentes más complejos —la tarjeta informativa y los tramos de descuento por cantidad— eran UI nativa nueva, mientras que el tercero —el carrusel inteligente— reutilizaba un componente existente de NAPPS con la lógica propia de Planeta Huerto por encima. Lógica a medida sobre una UI compartida cuando es posible, UI nueva solo cuando la interacción no existe: así se mantuvo eficiente el proyecto.

La realidad de la implementación: llevó unas cuatro semanas, más que un lanzamiento habitual de NAPPS, y la razón honesta es que Expresso todavía no existía por completo. NAPPS estaba construyendo la plataforma a la vez que la app de Planeta Huerto: el puente entre código nativo y la capa de React y TypeScript, los servicios para leer datos de Shopify —colecciones, productos y metaobjects— y APIs cuya necesidad apareció a mitad del proyecto, como el renderizado de texto enriquecido para la tarjeta informativa. Planeta Huerto tuvo paciencia y confió en el proceso. Todo lo creado aquí —el puente, los servicios, el texto enriquecido, los iconos dinámicos, los callbacks de eventos y el formato según el idioma— pasó a formar parte de la plataforma y llega ahora a todos los clientes de NAPPS. No hubo soluciones puntuales; cada pieza se diseñó para reutilizarse.

Teníamos años de lógica construida en nuestras páginas de producto, y un marketplace por encima. Esperábamos que una app aplanara todo eso. En su lugar, cada componente volvió en nativo, incluido nuestro marketplace, y las cifras de la App Store se movieron en el momento en que hicimos el cambio.

Albert MiraCTO, Planeta Huerto

La estrategia / Las tácticas

Reconstruye como componentes nativos todo lo que tu tema hace con metafields, incluida la lógica de marketplace.

1. Tarjeta informativa de proveedor y envío (nuevo componente nativo, creado en 5 días). Muestra el nombre del proveedor —clicable y enlazado a su colección—, el coste de envío y una estimación de entrega que cambia con el calendario: los pedidos de lunes a jueves se envían al día siguiente; los del viernes, el lunes; y los de fin de semana, el martes. También identifica si el producto es directo o de marketplace y aplica las reglas correctas de proveedor y envío, obteniendo datos de los metafields de producto, los metaobjects de proveedor y la integración con Mirakl. NAPPS lo construyó para que fuera flexible: elementos ilimitados, cualquier icono y formato de texto enriquecido. La táctica para cualquier operador con Mirakl o varios vendedores es mostrar de forma nativa el envío y la entrega de cada vendedor para que los productos de marketplace se sientan de primera clase. El mismo componente sirve ahora para certificaciones —ecológico, comercio justo—, información de sostenibilidad o características de producto de otras marcas.
2. Componente de descuentos por cantidad (nuevo componente nativo, creado en 4 días). Muestra tramos de descuento por volumen en la página de producto —compra 1 al precio normal, 3 y ahorra un 10 %, 5 y ahorra un 20 %— con varias capacidades incorporadas: número dinámico de tramos (de 2 a 10, no tres fijos), etiquetas como «Más popular» en cualquier tramo, seguimiento de la selección en directo y callbacks que devuelven el evento a la lógica de la marca para recalcular. La táctica: mantener la UI nativa y estándar, pero permitir que cada marca conecte su propia lógica de precios por debajo para que el descuento se actualice al instante, sin viajes de ida y vuelta a la web.
3. Carrusel inteligente de productos (UI existente, lógica a medida, creado en 1 día). Reutiliza un carrusel que NAPPS ya tenía; lo personalizado fue la lógica que decide qué colección mostrar. Las colecciones de Planeta Huerto se nombran mediante migas de pan —Inicio > Alimentación > Ecológico > Verduras— y un producto puede pertenecer a varias a la vez. La lógica cuenta la profundidad de la miga, muestra la colección más específica y titula la fila desde un metafield personalizado en el idioma del comprador. La táctica: utilizar la propia estructura del catálogo para comercializar productos relacionados automáticamente, sin curación manual, en una UI que no hubo que diseñar.

Los resultados

Todas las métricas medidas mejoraron después de pasar de una app de webview a una app realmente nativa.

Las mejoras no vinieron de una estrategia de crecimiento nueva. Vinieron de reconstruir las mismas páginas de producto como componentes nativos, marketplace incluido, y de conseguir que cada gesto, transición y navegación funcionara como los clientes esperan en su teléfono en lugar de luchar contra la app.

Conclusión

Planeta Huerto demuestra lo que es posible para catálogos complejos y de marketplace: marcas cuyas páginas de producto se apoyan en metafields, metaobjects y vendedores externos, y que asumen que ningún creador de apps podrá igualarlas sin precios de empresa o grandes concesiones. También prueba que Expresso funciona a escala, porque se construyó aquí. Lo nativo no implica quedar encerrado en plantillas: si tu lógica web funciona, puede trasladarse. El reto nunca fue la complejidad, sino disponer de una plataforma con los servicios, la capa de React y TypeScript y los componentes nativos capaces de soportarla. Si la objeción es «nuestro catálogo es demasiado personalizado para una app», esto demuestra que no lo es.

La relación sigue creciendo. Los componentes que NAPPS creó aquí llegan ahora a todos sus clientes, y los desarrolladores de Planeta Huerto se han unido desde entonces al programa de acceso cerrado de Expresso: ya crean componentes específicamente para la app y los publican al momento, sin esperar al ciclo de revisión de las tiendas de aplicaciones. Lo que comenzó como una migración se ha convertido en una plataforma sobre la que el propio equipo de la marca construye.