NutriSync le pide hoy a la usuaria que teclee cada día lo que su teléfono ya sabe: si durmió, si se movió, si tuvo el periodo. Conectar con Apple Health y Health Connect elimina ese trabajo y, sobre todo, mejora lo que de verdad importa: saber en qué fase del ciclo está. La temperatura de muñeca que mide un reloj de noche confirma la ovulación mejor que cualquier calendario.
Esto no se empieza de cero. De una sesión anterior (Epic E) ya existe:
health_signal con clave única por (usuaria, proveedor, tipo, instante): la misma muestra no puede entrar dos veces aunque se sincronice cien veces.connected_providers con registro del consentimiento y de su retirada, con fecha. Auditable.Y de esta sesión, el contrato de datos: la traducción de lo que dan las plataformas a nuestro modelo, en funciones puras con 21 casos de prueba. Falta el conector nativo, no el andamiaje.
Consecuencia: integrar Fitbit hoy sería construir algo que muere solo. Y hay una razón mejor para no hacerlo: quien tiene un Fitbit puede volcar sus datos en Health Connect, así que la integración con Android ya lo cubre indirectamente.
Consecuencia: para una app cuyo valor está en inferir sobre los datos, ese contrato es un muro. Strava es una red social de deporte; nosotros no lo somos. Además, quien registra en Strava suele volcar también en Apple Health o Health Connect: la vía indirecta funciona sin firmar nada.
«App de Apple Watch» y «Apple Health» suenan a lo mismo y son dos proyectos distintos:
| Apple Health (HealthKit) | App de Apple Watch | |
|---|---|---|
| Qué es | Dependencia nativa en la app iOS que ya tenemos | Aplicación aparte, con su propia interfaz |
| Stack | El mismo: Expo + EAS build | Swift + SwiftUI, código nuevo que no comparte nada |
| Su equivalente Android | Health Connect, también nativo | Kotlin + Compose para Wear OS: un tercer código |
| Qué aporta | Los datos, sin que nadie los teclee | Comodidad de registrar desde la muñeca |
Los datos vienen de la plataforma de salud del teléfono, no de la app del reloj. Un reloj Apple ya escribe en Apple Health sin que nosotros hagamos nada. Por eso las apps de reloj son un proyecto de comodidad, no de datos — y llegan después.
Regla: cada señal que pedimos tiene que tener un uso concreto en la app. El texto de la derecha es literalmente lo que verá la usuaria en el diálogo de permisos. Si no sabemos escribirlo, no lo pedimos: pedir «por si acaso» es lo que hace que la gente diga que no a todo.
| Señal | Para qué le sirve a ella | |
|---|---|---|
| Sueño | Rellena tu descanso del día sin que lo teclees | esencial |
| Entrenamientos | Marca el movimiento que ya has hecho en tu anillo del día | esencial |
| Flujo menstrual | Si ya registras tu periodo en Salud, no lo repites aquí | esencial |
| Temperatura de muñeca | La subida tras la ovulación confirma en qué fase estás | opcional |
| Energía activa | Ajusta las recomendaciones de nutrición a lo que gastas de verdad | opcional |
| Pasos | Distingue un día activo de uno sedentario | opcional |
| Frecuencia en reposo | Señal de recuperación: sube cuando el cuerpo pide descanso | opcional |
| Variabilidad cardiaca | Acompaña a la fase del ciclo y ayuda a decidir intensidad | opcional |
Solo tres son esenciales. Con esas tres la integración ya aporta; el resto se puede denegar sin romper nada.
El reloj mide hechos, no sentimientos. Puede saber cuántos minutos dormiste; no puede saber si descansaste. Puede medir tu variabilidad cardiaca; no puede saber cómo estás.
Técnicamente podríamos rellenar el ánimo a partir de la frecuencia en reposo y la HRV. No debemos. El día que una mujer se sienta perfectamente y la app le diga que está de mal humor, hemos perdido su confianza para siempre. Y el riesgo de fondo es peor: ánimo + ciclo es exactamente el terreno donde un producto como el nuestro puede acabar reforzando el estereotipo de «estás así porque te va a venir la regla». Con un número detrás, suena a ciencia. No lo es.
| Señal medida | Alimenta | Cómo |
|---|---|---|
| Sueño | sleep_quality | Sugerencia que ella puede cambiar |
| Entrenamiento | Anillo de movimiento | Directo |
| Flujo | flow_level | Directo |
| Energía activa, pasos | Recomendación de nutrición | Calibra la ración a lo que gasta |
| Temperatura | Confirmación de fase (Epic M) | La señal de más valor |
| HRV, frecuencia en reposo | Intensidad recomendada | «Hoy tu cuerpo pide menos», nunca «estás triste» |
| Ánimo, energía percibida | Nada. Los escribe ella | Se usan como eje para explicar patrones |
El núcleo de NutriSync es sincronizar nutrición y movimiento con la fase del ciclo. Hoy la fase se estima por calendario, con la incertidumbre que eso arrastra en ciclos irregulares. Los relojes con sensor de temperatura (Apple Watch Series 8 y posteriores, y varios Wear OS) miden la temperatura de muñeca durante el sueño; la subida sostenida tras la ovulación es una señal fisiológica real.
Bien usada, mejora la precisión de la fase sin prometer nada que no podamos cumplir: «tu ciclo se comportó como esperábamos» o «esta vez ovulaste más tarde de lo previsto, ajustamos».
connected_providers guarda cuándo se dio y cuándo se retiró.| Riesgo | Mitigación |
|---|---|
| La usuaria deniega los permisos y la app parece rota | Las tres señales esenciales se piden con su porqué; todo lo demás es opcional y la app funciona igual sin nada |
| Datos contradictorios (ella dice una cosa, el reloj otra) | Gana ella, siempre. El reloj rellena huecos, no corrige |
| Los relojes baratos dan datos malos | Guardamos el proveedor de cada muestra: si una fuente es ruidosa, se puede desactivar sin tocar el resto |
| Sincronizar consume batería | Sin lectura en segundo plano en la fase 1: se sincroniza al abrir la app |
| Apple rechaza la app por los textos de permiso | Escritos explicando para qué, no qué. Se revisan antes de enviar |
Tres cosas distintas, y conviene no mezclarlas: decisiones (dirección), diseño (cómo se ve y se siente) y lógica (qué hace el sistema cuando nadie mira). Sin las tres, O1 se queda a medias.
| # | Decisión | Recomendación | Bloquea |
|---|---|---|---|
| D15 | ¿Wearables antes o después del 8-oct? | Antes solo O1–O3 (las dos plataformas de teléfono). Aprovecha el piloto, que ya tiene iPhone en la mano | Todo Epic O |
| D16 | ¿Se rellena el ánimo con datos del reloj? | No. Lo objetivo se rellena, lo subjetivo se correlaciona (§5) | O1 y O5 |
| D17 | ¿Fitbit y Strava? | No por ahora. Fitbit muere en septiembre; Strava prohíbe lo que hacemos. Ambos llegan de rebote vía Health Connect | Alcance de O3 |
| D18 | ¿Temperatura para confirmar fase? | Sí, con la redacción de §6: confirma, no predice, y jamás como anticonceptivo | O4 |
| D19 | ¿Apps de reloj? | Después del lanzamiento, y solo si el piloto lo pide. Son dos códigos nativos nuevos | O6 |
Cuatro piezas visuales, en orden de necesidad. Las tres primeras bloquean O1.
| Pieza | Qué tiene que resolver | Cuidado con |
|---|---|---|
| Antesala del permiso | Explicar POR QUÉ pedimos cada cosa antes de que salte el diálogo de iOS. Una sola oportunidad: si dice que no, iOS no vuelve a preguntar | Que no parezca un trámite. Es el momento en que se gana o se pierde la confianza |
| Estado de conexión | En «Dispositivos conectados»: conectado / sin permiso / no disponible en este teléfono, y la última sincronización | «No disponible» no es un error — un iPhone sin reloj sigue dando sueño y pasos |
| Tarjeta de sugerencia | «Tu reloj dice que dormiste 7 h 20. ¿Lo anotamos?» con aceptar o descartar | Tiene que verse claramente como una propuesta, no como un dato ya guardado |
| Tarjeta de patrón (O5) | Contar una correlación de sus propios datos en una frase | Nunca en tono de diagnóstico ni de juicio. Un espejo, no un juez |
Formato: como siempre, pack del builder. Todo lo nuestro se inyecta después como bloque registrado.
Son decisiones de producto disfrazadas de detalles técnicos. Si no las fijamos nosotras, las fija el código por accidente.
| # | Regla | Propuesta |
|---|---|---|
| L1 | ¿La sugerencia se aplica sola o requiere un toque? | Un toque. Que aparezca algo en su diario sin que ella lo apruebe rompe la regla de §5 |
| L2 | Umbrales de sueño → etiqueta | <4 h muy pobre · 4–5,5 inquieto · 5,5–7 normal · 7–8,5 reparador · >8,5 profundo. Revisar con criterio nutricional |
| L3 | Si dos fuentes dan el mismo dato distinto | Gana la plataforma del teléfono; guardamos ambas con su origen |
| L4 | Cuánto histórico leemos la primera vez | 30 días. Suficiente para ver un ciclo completo, poco para ser invasivo |
| L5 | Qué pasa si retira el permiso | Se deja de leer y se marca la fecha. ¿Se borra lo ya leído? — decisión vuestra, tiene coste y tiene lectura legal |
| L6 | ¿Contamos su actividad real en la racha? | Sí, si aceptó la sugerencia. Una racha que ignora lo que hizo de verdad desmotiva |
Today NutriSync asks each woman to type in what her phone already knows: whether she slept, whether she moved, whether her period started. Connecting to Apple Health and Health Connect removes that chore and, more importantly, improves the thing that matters most: knowing which phase of her cycle she's in. The wrist temperature a watch measures overnight confirms ovulation better than any calendar can.
This doesn't start from zero. From an earlier session (Epic E) we already have:
health_signal table with a unique key on (user, provider, type, timestamp): the same sample cannot land twice, however many times we sync.connected_providers table recording consent and its withdrawal, with timestamps. Auditable.And from this session, the data contract: the translation from what the platforms hand us into our model, written as pure functions with 21 unit tests. What's missing is the native connector, not the scaffolding.
Consequence: building Fitbit today means building something that dies on its own. And there's a better reason not to: anyone with a Fitbit can push their data into Health Connect, so the Android integration already covers it indirectly.
Consequence: for an app whose value lies in reasoning over data, that contract is a wall. Strava is a social network for sport; we are not. And people who log in Strava usually also push to Apple Health or Health Connect: the indirect route works without signing anything.
"Apple Watch app" and "Apple Health" sound like the same thing. They are two different projects:
| Apple Health (HealthKit) | Apple Watch app | |
|---|---|---|
| What it is | A native dependency in the iOS app we already have | A separate application with its own interface |
| Stack | The same one: Expo + EAS build | Swift + SwiftUI, new code sharing nothing |
| Android equivalent | Health Connect, also native | Kotlin + Compose for Wear OS: a third codebase |
| What it buys | The data, without anyone typing it | The convenience of logging from the wrist |
The data comes from the phone's health platform, not from the watch app. An Apple Watch already writes into Apple Health without us doing anything. That's why watch apps are a convenience project, not a data project — and why they come later.
The rule: every signal we request must have a concrete use in the app. The text on the right is literally what she will read in the permission dialog. If we can't write it, we don't ask for it — asking "just in case" is what makes people decline everything.
| Signal | What it does for her | |
|---|---|---|
| Sleep | Fills in your rest for the day without you typing it | essential |
| Workouts | Marks the movement you've already done on your daily ring | essential |
| Menstrual flow | If you already log your period in Health, you don't repeat it here | essential |
| Wrist temperature | The post-ovulation rise confirms which phase you're in | optional |
| Active energy | Tunes nutrition guidance to what you actually burn | optional |
| Steps | Tells an active day from a sedentary one | optional |
| Resting heart rate | A recovery signal: it rises when the body is asking for rest | optional |
| Heart rate variability | Tracks with cycle phase and helps decide intensity | optional |
Only three are essential. With those three the integration already earns its place; everything else can be declined without breaking anything.
A watch measures facts, not feelings. It can know how many minutes you slept; it cannot know whether you rested. It can measure your heart rate variability; it cannot know how you are.
We could technically fill in mood from resting heart rate and HRV. We must not. The day a woman feels perfectly fine and the app tells her she's in a bad mood, we have lost her trust for good. And the deeper risk is worse: mood plus cycle is exactly the terrain where a product like ours can end up reinforcing the stereotype that "you're like this because your period is coming". With a number behind it, that sounds like science. It isn't.
| Measured signal | Feeds | How |
|---|---|---|
| Sleep | sleep_quality | A suggestion she can change |
| Workout | Movement ring | Direct |
| Flow | flow_level | Direct |
| Active energy, steps | Nutrition guidance | Calibrates portions to what she burns |
| Temperature | Phase confirmation (Epic M) | The highest-value signal |
| HRV, resting heart rate | Recommended intensity | "Your body is asking for less today", never "you're sad" |
| Mood, perceived energy | Nothing. She writes them | Used as the axis that explains patterns |
The core of NutriSync is syncing nutrition and movement to cycle phase. Today phase is estimated from the calendar, with all the uncertainty that carries in irregular cycles. Watches with a temperature sensor (Apple Watch Series 8 and later, and several Wear OS models) measure wrist temperature during sleep; the sustained rise after ovulation is a real physiological signal.
Used well, it improves phase accuracy without promising anything we can't deliver: "your cycle behaved as expected", or "you ovulated later than predicted this time, so we've adjusted".
connected_providers records when consent was given and when it was withdrawn.| Risk | Mitigation |
|---|---|
| She declines permissions and the app looks broken | The three essential signals are asked for with their reason; everything else is optional and the app works without any of it |
| Contradictory data (she says one thing, the watch another) | She wins, always. The watch fills gaps, it doesn't correct anyone |
| Cheap watches produce poor data | We store the provider of every sample: a noisy source can be switched off without touching the rest |
| Syncing drains battery | No background reads in phase 1: we sync when the app opens |
| Apple rejects the app over permission wording | Written to explain what for, not what. Reviewed before submission |
Three different things, and they shouldn't be blurred: decisions (direction), design (how it looks and feels) and logic (what the system does when nobody is watching). Without all three, O1 ships half-built.
| # | Decision | Recommendation | Blocks |
|---|---|---|---|
| D15 | Wearables before or after 8 Oct? | Only O1–O3 before (the two phone platforms). It capitalises on the pilot, which already has iPhones in hand | All of Epic O |
| D16 | Should mood be filled from watch data? | No. Objective fills, subjective correlates (§5) | O1 and O5 |
| D17 | Fitbit and Strava? | Not for now. Fitbit dies in September; Strava forbids what we do. Both arrive indirectly via Health Connect | Scope of O3 |
| D18 | Temperature for phase confirmation? | Yes, with the wording in §6: it confirms, it doesn't predict, and never as contraception | O4 |
| D19 | Watch apps? | After launch, and only if the pilot asks. They are two new native codebases | O6 |
Four visual pieces, in order of need. The first three block O1.
| Piece | What it must solve | Watch out for |
|---|---|---|
| Permission pre-screen | Explain WHY we ask for each thing before the iOS dialog appears. One shot only: if she declines, iOS never asks again | It must not feel like paperwork. This is the moment trust is won or lost |
| Connection state | In "Connected devices": connected / permission denied / not available on this phone, plus last sync | "Not available" is not an error — an iPhone without a watch still gives sleep and steps |
| Suggestion card | "Your watch says you slept 7h20. Shall we log it?" with accept or dismiss | It must read clearly as a proposal, not as something already saved |
| Pattern card (O5) | Tell one correlation from her own data in a single sentence | Never in a diagnostic or judgemental tone. A mirror, not a judge |
Format: builder pack as always. Everything of ours is injected afterwards as a registered block.
These are product decisions dressed as technical details. If we don't settle them, the code settles them by accident.
| # | Rule | Proposal |
|---|---|---|
| L1 | Does a suggestion apply itself or need a tap? | A tap. Anything appearing in her diary without her approval breaks the rule in §5 |
| L2 | Sleep thresholds → label | <4h very poor · 4–5.5 restless · 5.5–7 okay · 7–8.5 restful · >8.5 deep. To be reviewed against nutrition criteria |
| L3 | When two sources disagree on the same figure | The phone platform wins; we keep both with their origin |
| L4 | How much history do we read on first connect? | 30 days. Enough to see a full cycle, little enough not to feel invasive |
| L5 | What happens when she revokes permission | We stop reading and record the date. Do we delete what was already read? — your call; it has a cost and a legal reading |
| L6 | Does real activity count towards her streak? | Yes, if she accepted the suggestion. A streak that ignores what she actually did is demotivating |