Home readings your care team actually sees.
Curlew is the patient side of a clinic-run remote monitoring programme. A patient pairs their home blood pressure cuff, glucometer, scale and pulse oximeter over Bluetooth, takes readings on the schedule their clinic set, logs symptoms and medication, and messages the practice — while the clinic watches the trend and is alerted when a reading falls outside the range set for that person. It is used by people managing hypertension, type 2 diabetes or heart failure between appointments, and by the nurses and care coordinators running the monitoring list. It supports a care plan; it does not diagnose.
A BuildspaceLabs reference build. We designed Curlew in-house to show how we approach native mobile — it is not a client engagement, and every name, record and figure inside these screens is fictional demo data.
Curlew is designed twice — once in the iOS idiom and once in Material 3 — on top of a shared domain core, rather than one layout wrapped twice for both stores. The frameworks below are the stack each side is specced against.
3 surfaces from the build — 2 in the iOS idiom and 1 redesigned in Material 3 on Android. Everything inside the frames is fictional demo data.
The daily hub: greeting with check-in progress, the next scheduled prompt with start and snooze actions, live Bluetooth state for four home devices, a 2×2 vitals grid with sparklines, the flagged 148/94 evening reading, today's medications, and the symptom check-in, over a five-tab bar and a persistent monitoring-aid disclaimer.
Thirty days of systolic and diastolic readings plotted against the clinic-set target band, with out-of-range points ringed, a drag-scrub readout, medication-change and symptom annotations, the out-of-range list, the in/high/low distribution, excluded-reading note, and export actions.
The same day and the same data rebuilt in the Material 3 idiom: top app bar in its collapsed state, filled and elevated cards, wavy progress indicator, assist chips, M3 list items with checkboxes, a connected segmented button group, navigation bar with an active-indicator pill, and a FAB in place of the iOS in-card CTA.
The case for building this twice rather than wrapping a web app. Each one is designed around an operating-system capability a browser either cannot reach or cannot be trusted to hold.
The app talks to the Bluetooth SIG Blood Pressure (0x1810), Glucose (0x1808), Weight Scale (0x181D) and Pulse Oximeter (0x1822) profiles directly, including indication-based stored-record transfer — a cuff that batched three readings while out of range hands them all over on the next connect, with timestamps reconciled against device drift. Web Bluetooth cannot bond, cannot background, and is not available on iOS at all.
CoreBluetooth state restoration on iOS, plus a foreground service and BLE scan-callback wake on Android, mean a scale stepped on at 6am or a cuff powered on across the room syncs on its own. A web app is dead the moment its tab is.
Blood pressure, blood glucose, body mass and oxygen saturation land in the OS health record the patient and their other clinicians already trust, with per-type permission prompts and revocation handling. Only a native app can hold those entitlements.
Time-zone-aware local notifications using the iOS Time Sensitive interruption level and Android exact alarms with Doze exemptions, so the 7:00 PM reading prompt and 9:00 PM medication prompt actually fire.
On-device text recognition (Vision on iOS, ML Kit on Android) reads a value straight off a non-Bluetooth device display, and CoreNFC / Android NFC handles tap-to-pair for clinic-issued kit that ships with a tag on the box.
SQLCipher with keys in Keychain and Android Keystore, Face ID / BiometricPrompt unlock, and a conflict-safe outbound queue so readings taken with no signal reach the clinic in order once connectivity returns.
The target architecture this build is specced against, chosen per constraint rather than per habit — the stack shifts with the problem.
Curlew is a reference build, so there is nothing to buy on this page. If your team has a problem that needs this kind of depth — offline for a full shift, real sensors, work that has to happen with the screen off — tell us about it and we will tell you honestly whether we are the right people to build it.