Caso de éxito · HealthTech · Nutrición
Caso de éxito BasilDoc: cómo entregamos una app de nutrición para consumidores multiplataforma, lista para App Store y Google Play, con una única base de código en Flutter, un motor de calorías y macronutrientes, un constructor de planes de comidas semanales y una infraestructura de compras dentro de la app que resiste la validación de recibos para audiencias de Estados Unidos y la Unión Europea desde el primer día.
El equipo de producto de BasilDoc gestionaba un servicio de dietas consolidado en la web y quería una versión móvil en iOS y Android. El backend y parte de un sistema de diseño ya existían, pero el equipo no tenía capacidad móvil propia, la especificación estaba incompleta y había un requisito estricto: las compras dentro de la app debían funcionar sin fisuras con Apple StoreKit y Google Play Billing, para audiencias de Estados Unidos y la Unión Europea, donde las normas de las tiendas y el tratamiento fiscal difieren de maneras que importan a nivel de ruta de código. Construimos el cliente móvil en Flutter con Dart para lanzar ambas plataformas desde una única base de código. Como la especificación era escasa, realizamos entrevistas con las partes interesadas para aclarar los flujos reales de los usuarios (selección de objetivo, cálculo de calorías, consumo de recetas, planificación semanal), y las respuestas impulsaron ajustes de backend y de diseño que llegaron antes de escribir ningún código de producción. Una cadencia combinada de Scrum/Kanban absorbió los cambios de alcance sin perder velocidad, y la infraestructura de compras dentro de la app se trató como una línea de trabajo propia, con validación de recibos en el servidor contra los endpoints de verificación de Apple y de Google. El resultado final es una app HealthTech para consumidores lista para las tiendas de EE. UU. y la UE, concebida como un desarrollo insignia de nuestra práctica de desarrollo de aplicaciones móviles.
Un resumen de lo que aportó el desarrollo de BasilDoc en una única base de código Flutter, el motor de calorías y la infraestructura de compras dentro de la app durante su primer ciclo de producción.
La decisión sobre el stack pesa más que cualquier otra decisión de arquitectura en un desarrollo HealthTech multiplataforma. Elegimos Flutter con Dart frente a React Native, iOS y Android nativos en paralelo e Ionic / Capacitor porque las ventajas y desventajas encajan con claridad con un producto de nutrición para consumidores en el que la paridad de píxeles entre plataformas es una característica. Flutter dibuja con su propio motor basado en Skia en lugar de entregar árboles de widgets a primitivas nativas del sistema operativo, lo que significa que una cuadrícula de planes de comidas se comporta igual en un iPhone y en un Pixel sin desajustes de diseño por plataforma. Material 3 cubre Android y los widgets Cupertino cubren iOS, ambos desde el mismo código fuente de Dart.
React Native se descartó porque la sobrecarga del puente y las diferencias en el motor de renderizado añaden desajustes por plataforma justo donde una interfaz HealthTech no puede permitírselos: las cifras del motor de calorías, las barras de macronutrientes y la cuadrícula de planes de comidas tienen que caer en el mismo píxel en ambas plataformas. Desarrollar en paralelo iOS y Android nativos habría duplicado los ciclos de desarrollo, QA y lanzamiento para un conjunto de funciones que no necesita integraciones profundas específicas de cada plataforma. El renderizado de Ionic / Capacitor, basado en WebView, pierde la fluidez de gestos que necesita una app HealthTech para consumidores.
| Criterio | Flutter (BasilDoc) | React Native | iOS + Android nativos / Ionic |
|---|---|---|---|
| Modelo de renderizado | Basado en Skia; paridad de píxeles entre plataformas | Primitivas nativas del sistema operativo mediante un puente JS | Nativo: directo; Ionic: WebView |
| Número de bases de código | Una base de código Dart para ambas tiendas | Una base de código JS/TS con ramas por plataforma | Nativo: dos bases de código; Ionic: una base de código web |
| Coherencia de la interfaz | Material 3 + Cupertino: idéntica en iOS y Android | Predeterminada de la plataforma: desajustes en los bordes del diseño | Nativo: trabajo completo de paridad; Ionic: sensación de web |
| Cadencia de compilación / lanzamiento | Una única matriz de CI compila ambas tiendas | Una única matriz; los módulos nativos la ralentizan | Nativo: dos matrices; Ionic: web + envoltorios |
| Profundidad de la integración de compras dentro de la app | Plugins propios de StoreKit y Play Billing | Plugins de la comunidad; la calidad varía | Nativo: la más profunda; Ionic: restricciones de WebView |
| Fluidez de gestos | Alta: Skia controla el fotograma | Variable: el puente puede perder fotogramas | Nativo: la mejor; Ionic: techo de WebView |
| Ecosistema maduro de plugins | Sólido en superficies de consumo: pagos, multimedia, push | Sólido, pero de calidad heterogénea | Nativo: plataforma completa; Ionic: legado de Cordova |
Referencias de plataformas: documentación de Apple StoreKit, referencia de Google Play Billing, Material 3.
La superficie de iOS usa widgets Cupertino para que la experiencia de BasilDoc resulte nativa a un usuario de iPhone: el ritmo de navegación, las hojas modales y el comportamiento de los selectores coinciden de serie con lo que espera una audiencia de iOS de EE. UU. o de la UE. El motor de calorías y macronutrientes reside en la capa compartida de Dart: un selector basado en objetivos se resuelve en una meta calórica diaria y un reparto de macronutrientes (proteínas, carbohidratos, grasas), el recomendador basado en objetivos propone programas que encajan con el perfil del usuario y la biblioteca de recetas se muestra con un reproductor de instrucciones en vídeo que respeta las reglas de audio en segundo plano de iOS para que el usuario pueda seguir cocinando mientras se reproduce un paso.
Toda la superficie de iOS (incorporación, selección de objetivo, motor de calorías, biblioteca de recetas, constructor de planes de comidas) se gestiona con el mismo código Dart que mueve Android, con widgets adaptados a la plataforma que resuelven la capa visual en tiempo de renderizado. La ruta de compras dentro de la app pasa por el plugin propio de Apple StoreKit, y las llamadas de validación de recibos se envían al mismo endpoint del servidor que usa Android. La superficie conjunta se entrega como parte de nuestra práctica de desarrollo de aplicaciones móviles, con una puerta de CI estricta contra desajustes entre plataformas que mantiene iOS y Android sincronizados en cada lanzamiento.
La superficie de Android usa Material 3 desde el mismo código fuente de Dart, con widgets adaptados a la plataforma que resuelven la navegación, los diálogos y el movimiento según los ritmos nativos de Android. El constructor de planes de comidas semanales es la pieza central: el usuario elige un programa, el motor de calorías resuelve una meta diaria y un reparto de macronutrientes y el constructor rellena siete días con la biblioteca de recetas, con huecos fáciles de intercambiar para que el usuario pueda sustituir el desayuno del martes sin rehacer el resto de la semana. La exportación de la lista de la compra agrupa la semana seleccionada en una única lista compartible, y los recordatorios push de comidas se gestionan con Firebase Cloud Messaging en Android, con adhesión voluntaria por defecto para mantenerse limpios ante el RGPD para los usuarios de la Unión Europea.
La ruta de compras dentro de la app en Android pasa por Google Play Billing con el mismo validador en el servidor que usa iOS. El registro único de derechos controla el acceso a funciones en programas de dieta, recetas e historial de planes de comidas, lo que significa que un usuario que se suscribe en Android y luego cambia de teléfono a iOS recupera el acceso sin problemas porque el derecho reside en el servidor y no en la tienda. Los procesos en segundo plano gestionan las operaciones no urgentes (sincronización de la biblioteca de recetas, programación de notificaciones push, rotación de certificados) con una semántica de retroceso que respeta los estados de ahorro de batería de Android 10 a Android 14 en las familias de dispositivos Samsung, Xiaomi, OnePlus y Pixel.
El enfoque de privacidad de BasilDoc fue una decisión de arquitectura antes de ser una afirmación de marketing. La app recoge solo los datos personales que necesita el motor de calorías (objetivo, rango de edad, peso objetivo y restricciones dietéticas) y los almacena bajo un identificador de usuario opaco deliberadamente separado de la identidad de pago. Los endpoints de verificación de Apple y de Google conservan los recibos; el validador del servidor normaliza la respuesta y escribe un único registro de derechos asociado al identificador opaco. El lado de las tiendas nunca ve el perfil dietético del usuario, y el lado dietético nunca ve el ID de Apple ni la cuenta de Google del usuario.
Los flujos de consentimiento adaptados a la región están integrados en la capa del cliente: los usuarios de la UE y el EEE reciben una pantalla de consentimiento granular al estilo del RGPD con interruptores independientes para cualquier analítica de producto opcional; los usuarios de California reciben en el mismo flujo un aviso al estilo de la CCPA, «No vender ni compartir mi información personal». El enfoque está concebido para alinearse con las obligaciones del RGPD para los usuarios de la Unión Europea y con las de la CCPA / CPRA para los usuarios de California y del resto de Estados Unidos, y para que una futura revisión independiente de privacidad sea un ejercicio de documentación y no una reforma de la arquitectura.
Enfoque de cumplimiento: alineado con el RGPD · preparado para ISO 27001 · SOC 2 Type II en curso · apto para HIPAA · CCPA contemplada.
Un desarrollo en cinco fases que llevó a BasilDoc desde una especificación escasa y un servicio de dietas solo web hasta una app de iOS y Android en producción con infraestructura de compras dentro de la app.
Entrevistas con las partes interesadas, validación de los flujos de usuario, contrato de entrada/salida del motor de calorías, análisis de carencias del backend, mapeo del enfoque RGPD + CCPA y revisión de las políticas de revisión de Apple y Google.
Capa compartida de Flutter, estrategia Material 3 + Cupertino, motor de calorías y macronutrientes, modelo de datos del constructor de planes de comidas, esquema de derechos de compras dentro de la app y esqueleto del validador de recibos en el servidor.
Selección de dieta basada en objetivos, biblioteca de recetas con reproductor de instrucciones en vídeo, constructor de planes de comidas semanales, exportación de la lista de la compra, recordatorios push y compras dentro de la app en ambas tiendas.
Refuerzo de la validación de recibos en el servidor, redacción de la política de privacidad, flujos de consentimiento adaptados a la región, declaración HealthTech de App Store y preparación de la revisión de datos sensibles de Google Play.
Envío a App Store y Google Play en las tiendas de EE. UU. y la UE, despliegue del nivel de pago, ajuste de cohortes de recordatorios push y analítica voluntaria para la tasa de consecución de objetivos.
La capa de monetización de BasilDoc se construyó para mantener demostrablemente separadas la identidad de pago y el perfil dietético, porque el enfoque de privacidad de una app HealthTech se derrumba en cuanto una sola base de datos une una transacción de StoreKit con una selección de objetivo. Las suscripciones se venden mediante Apple StoreKit en iOS y Google Play Billing en Android, con validación de recibos en el servidor contra el endpoint de verificación de cada tienda y un único registro de derechos asociado a un identificador opaco y rotativo, nunca al ID de Apple, a la cuenta de Google ni al correo electrónico. Dentro del motor de calorías y del constructor de planes de comidas, lo único visible es un token de portador de corta duración que se corresponde con un derecho y caduca con rapidez. El acceso a los programas de dieta, el desbloqueo de la biblioteca de recetas, el control de acceso al reproductor de instrucciones en vídeo y el historial semanal de planes de comidas leen del mismo registro de derechos, de modo que una única suscripción se resuelve limpiamente tras reinstalaciones, cambios de dispositivo y el eventual traspaso a una cuenta web. Todo el subsistema se construyó pensando en la extensibilidad: añadir un plan familiar, un derecho multidispositivo o un nivel de entrenador y cliente con perfiles emparejados es un cambio de configuración en el servicio de derechos, no un lanzamiento de código. El mismo enfoque deja espacio para futuras funciones de ingeniería de IA/ML y datos: recomendaciones personalizadas ajustadas a cohortes anonimizadas, sin vincularlas a la identidad de pago.
BasilDoc se construyó para las tiendas Apple App Store y Google Play activas en Estados Unidos y en la Unión Europea. La versión en inglés atiende a usuarios de California, Nueva York, Texas, Florida y Washington en EE. UU., y a usuarios de Países Bajos, Alemania, Francia, Irlanda y Suecia en la UE, sin una base de código distinta por región. Los flujos de consentimiento se adaptan a la región en la capa del cliente: los usuarios de la UE y el EEE reciben una pantalla de consentimiento granular al estilo del RGPD con interruptores independientes para cualquier analítica de producto opcional; los usuarios de California reciben en el mismo flujo un aviso al estilo de la CCPA, «No vender ni compartir mi información personal». Las prácticas de tratamiento de datos están alineadas con el RGPD para los usuarios europeos y con el mosaico de leyes estatales de privacidad de EE. UU.: CCPA / CPRA (California), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) y la CPA de Oregón. Como el identificador de usuario opaco aísla los datos dietéticos de la identidad de pago, el cumplimiento regional se reduce a una divulgación honesta y no a una segregación de datos por jurisdicción.
Los canales de compras dentro de la app se probaron contra el sandbox de Apple y el canal de pruebas de licencias de Google Play en ambas regiones en paralelo, y la clasificación por edades de App Store y la clasificación de contenido de Google Play se calibraron para el conjunto de funciones HealthTech. La política de privacidad se redactó para documentar exactamente la arquitectura descrita, citando directamente las obligaciones del RGPD y las obligaciones de la CCPA de California. El equipo de ingeniería responsable del desarrollo trabaja en CET y sigue una jornada CET con solapamiento con la costa este de EE. UU. (9:00–13:00 ET) para las reuniones diarias, la coordinación de las revisiones de las tiendas y la respuesta a incidencias: la franja horaria que permite a un equipo de producto de EE. UU. y a uno de ingeniería de la UE compartir cuatro horas de solapamiento en directo cada día.
La hoja de ruta activa de desarrollo de software a medida de BasilDoc incluye una vía de ingesta de datos de wearables para Apple Health y Google Fit, una caché de recetas offline-first para viajes con poca conectividad, un nivel emparejado de entrenador y cliente para nutricionistas de EE. UU. y la UE y una app de escritorio complementaria que comparta la lógica de negocio de Flutter mediante Flutter Desktop. Se prevén un embudo de crecimiento centrado en EE. UU. y otro en la UE con bibliotecas de recetas específicas de cada región, y el subsistema de derechos ya admite la asignación multipuesto que necesitará un futuro nivel B2B de nutrición.
Si planea una app multiplataforma de dieta, nutrición o HealthTech en la que la infraestructura de compras dentro de la app y el enfoque de privacidad deban superar una revisión de Apple y Google para audiencias de EE. UU. y la UE, hemos entregado este stack de principio a fin y podemos acortar de forma notable el plazo de desarrollo. El equipo de ingeniería que la desarrolló forma parte de YuSMP Group. Trabajamos a precio cerrado en MVP bien acotados y con equipos de desarrollo dedicados para la entrega continua, con jornada CET y una franja garantizada de solapamiento con la costa este de EE. UU. (9:00–13:00 ET) para reuniones diarias, demos y respuesta a incidencias.
Un MVP multiplataforma de dieta y planificación de comidas con iOS y Android mediante Flutter, un motor de calorías y macronutrientes, una biblioteca de recetas e infraestructura de compras dentro de la app suele costar $90k–$210k. Añadir un recomendador basado en objetivos, un constructor de planes de comidas semanales, la exportación de la lista de la compra, un reproductor de instrucciones en vídeo y recordatorios push lleva un producto completo a $250k–$520k. Los principales factores de coste son la precisión del motor de calorías, la validación de recibos de compras dentro de la app en dos tiendas y el flujo de consentimiento del RGPD y la CCPA ajustado a las tiendas de EE. UU. y la UE.
Flutter entrega una única base de código Dart a iOS y Android con widgets Material 3 y Cupertino exactos al píxel, lo que encaja con un producto HealthTech para consumidores en el que la paridad entre plataformas es una característica y no un accidente. En comparación con React Native, el motor de renderizado es más predecible y la sobrecarga del puente es menor. En comparación con iOS y Android nativos en paralelo, una única base de código reduce aproximadamente a la mitad los ciclos de desarrollo, QA y lanzamiento para un conjunto de funciones que no necesita integraciones profundas específicas de cada plataforma.
Las compras dentro de la app son una línea de trabajo propia. El cliente de iOS integra Apple StoreKit, el cliente de Android integra Google Play Billing, y ambas rutas de cliente envían los recibos a un único validador en el servidor que consulta los endpoints de verificación de Apple y de Google, normaliza la respuesta y escribe un registro de derechos por usuario. Ese registro controla el acceso a funciones en programas de dieta, planes de comidas y recetas. La validación en el servidor es obligatoria: las comprobaciones de recibos solo en el cliente se pueden eludir con trivialidad e invalidan todo el enfoque de suscripciones.
La app recoge solo los datos personales necesarios para ejecutar el motor de calorías (objetivo, rango de edad, peso objetivo y restricciones dietéticas) y los almacena bajo un identificador de usuario opaco que no se une a la identidad de pago. Los flujos de consentimiento adaptados a la región presentan una pantalla de consentimiento granular al estilo del RGPD a los usuarios de la UE y el EEE y un aviso al estilo de la CCPA a los usuarios de California. Los recordatorios push son de adhesión voluntaria por defecto en ambas regiones, y la política de privacidad documenta cada ruta de datos que usan el motor de calorías y el constructor de planes de comidas.
Un MVP centrado en selección de dieta basada en objetivos, un motor de calorías y macronutrientes, una biblioteca de recetas, un constructor de planes de comidas semanales y compras dentro de la app en ambas tiendas suele tardar 14–22 semanas. Añadir un reproductor de instrucciones en vídeo, exportación de la lista de la compra, recomendaciones personalizadas y recordatorios push de comidas suma 6–10 semanas. El paso de envío a las tiendas y coordinación de las revisiones (la declaración HealthTech de Apple, la revisión de datos sensibles de Google Play y una política de privacidad que cubra los flujos de consentimiento de EE. UU. y la UE) debería presupuestarse con 3–5 semanas de trabajo dedicado.
Casos relacionados
App para pacientes de una red de laboratorios en varias ciudades: reserva de citas, resultados, notificaciones push e integración contable.
Ver el caso →
App de consultor de retail para el inventario de boutiques en varias tiendas: búsqueda con ElasticSearch e integración con 1C.
Ver el caso →
App móvil de marketplace local para una cadena física de artículos infantiles: catálogo flexible y sincronización de stock online.
Ver el caso →
MVP listo para inversores entregado en 12 semanas por 60-120k EUR. PM sénior, diseñador, ingenieros y QA.
Más información →
Apps nativas para iOS y Android y multiplataforma, con pipelines de publicación listos para las tiendas.
Más información →
Plataformas SaaS multi-tenant con SSO, facturación y residencia fijada por región. SOC 2 en curso.
Más información →Cuéntenos algunos detalles y un consultor sénior le responderá en un día hábil.