Apple Watch & watchOS App Development
watchOS apps tightly integrated with hardware sensors, health frameworks, and companion iPhone apps — built for wearable medical devices, sports performance trackers, and industrial safety monitors.
What We Build on This Platform
watchOS App Architecture
Standalone watchOS apps, companion-dependent apps, and hybrid architectures selected for the product's connectivity model. Standalone apps enable BLE peripheral connections and local HealthKit writes without iPhone relay; companion-dependent architectures offload complex processing to the phone's larger CPU and memory budget.
HealthKit Integration
Reading and writing HealthKit quantity samples, category samples, and workout routes with correct provenance metadata and authorization handling. Background delivery is configured for sample types requiring near-real-time processing, and cumulative vs. discrete quantity type semantics are matched precisely to measurement intent.
WorkoutKit & Live Activity
WorkoutKit session management for fitness and medical monitoring applications with accurate calorie computation, pace algorithms, and heart rate zone tracking. Live Activity and Smart Stack integration surface real-time session metrics on the watch face without requiring the app to be in the foreground.
Core Motion on Apple Watch
Accelerometer, gyroscope, and device motion data at up to 100 Hz for motion analysis, fall detection, and activity classification. Batch CMSensorRecorder collection enables passive long-duration recording that continues even when the app is not running, with data retrieved on the next app launch.
Core Bluetooth from watchOS
BLE Central role on Apple Watch for connecting to peripheral hardware sensors without iPhone relay, including foreground-only and background-constrained BLE processing. Connection parameter selection is tuned for the Watch's power budget, balancing update interval against the expected data rate from the peripheral.
Complications & Smart Stack
ClockKit complication families and WidgetKit-based Smart Stack widgets for at-a-glance display of hardware sensor data on the watch face. Timeline scheduling is aligned with the hardware sensor update rate, and complication budgets are respected to avoid the system demoting the complication for excessive updates.
WatchConnectivity
WCSession message passing, transferUserInfo, and transferFile between Watch and iPhone companion app for bidirectional hardware data relay. The appropriate transfer method is selected per use case: interactive messages for command responses, transferUserInfo for queued state updates, and transferFile for accumulated sensor logs.
Always-On Display Optimization
Reduced-update AOD views that conserve battery while keeping critical hardware sensor readings visible without requiring a wrist raise. AOD rendering uses a separate, lower-fidelity SwiftUI view hierarchy that avoids animations, gradients, and frequent timeline updates to remain within the AOD power budget.
How Ankh Uses This Platform
Product Architecture: Standalone vs. Companion-Dependent
Determined by connectivity requirements, data processing load, and whether the hardware peripheral connects via BLE directly to the Watch or via iPhone. Standalone Watch apps can connect to BLE peripherals, but the Watch BLE stack may be occupied by system services (heart rate monitor, Bluetooth audio) in ways that make connection reliability unpredictable. Companion-dependent architectures relay data through iPhone but enable richer processing on the phone — FFT, ML inference, complex aggregations — before the result reaches the Watch. Hybrid architectures use direct BLE when the phone is unreachable and fall back to WatchConnectivity when both devices are present.
HealthKit Authorization & Data Model
HealthKit sample types are defined for each measurement the product captures, with careful selection of the quantity type identifier — using HKQuantityTypeIdentifier.heartRateVariabilitySDNN for HRV rather than a custom type ensures data interoperability with Apple Health and third-party apps. Authorization request UI is designed with context descriptions that maximize approval rate; users who understand why the app needs HealthKit access grant it at a significantly higher rate. Background delivery is configured for sample types requiring near-real-time processing, with the delivery update frequency set to the minimum value that satisfies the clinical or product requirement, since aggressive background delivery is a common source of watchOS battery complaints.
Sensor Sampling & Battery Budget
Core Motion sampling rate is configured against the battery budget for the expected session duration. A 100 Hz accelerometer session that must sustain 8 hours requires aggressive batch processing: CMSensorRecorder records to a circular buffer that the app reads in bulk rather than consuming real-time CMDeviceMotion callbacks. For shorter sessions — clinical measurements, workout intervals — streaming processing at 50–100 Hz is feasible within the workout session background execution budget. Significant location and activity classification via CMMotionActivityManager are used where fine-grained inertial data is not required, as they consume substantially less power than raw accelerometer streaming. AOD power budget is reserved explicitly in the battery model so complication updates and background task scheduling do not erode the margin needed for Always-On operation.
Complication & Widget Design
ClockKit complication families are selected for the data type the product surfaces: Gauge for values with a defined range (battery level, fill percentage), CircularSmall for icon-plus-value displays, GraphicCorner for rich curved text. WidgetKit Smart Stack entries are implemented for watchOS 10+ as the primary at-a-glance surface, since users discover Smart Stack entries more frequently than complications on watchOS 10 and later. Complication timeline entries are computed for the next 12 hours where the data is predictable, reducing background wake frequency. The timeline refresh budget — approximately 50 entries per day — is allocated across complication families to avoid the system throttling updates during high-use periods.
WatchConnectivity & Background Transfer
WCSession activation is implemented on both Watch and iPhone at app launch, with a state machine handling the INSTALLED, NOT_INSTALLED, and REACHABLE transitions that WatchConnectivity surfaces. Transfer method selection follows strict rules: sendMessage for real-time command/response when both devices are reachable; transferUserInfo for queued state updates that must survive watch-phone separation; updateApplicationContext for idempotent state that only the latest value matters for; transferFile for accumulated sensor log files. Background WatchConnectivity transfer — particularly transferUserInfo — is relied upon to sync data during charging sessions when the Watch is not being worn. Error handling accounts for the common case where WCSession.isReachable is false during active exercise sessions, where the phone may be stowed and the radio duty-cycled.
Deep Technical Capability
Background BLE Processing Constraints on watchOS
watchOS background execution is fundamentally more constrained than iOS. An iOS app with the bluetooth-central background mode can maintain BLE connections and process characteristic notifications indefinitely in the background; a watchOS app loses background BLE access when it exits the foreground, except during an active WKExtendedRuntimeSession or HKWorkoutSession. The HKWorkoutSession background execution grant is the most practical mechanism for maintaining BLE peripheral connections during exercise or clinical monitoring sessions, but it requires an active HealthKit workout — which is semantically inappropriate for non-fitness use cases. WKExtendedRuntimeSession provides up to 30 minutes of background execution for mindfulness and session-based use cases but is not suitable for indefinite monitoring. The practical consequence is that for a wearable medical device requiring continuous BLE data from an external sensor, a companion-dependent architecture — where the iPhone maintains the BLE connection and relays data to the Watch via WatchConnectivity — produces substantially better real-world reliability. Direct Watch BLE is viable for use cases where data loss during foreground absence is acceptable, or where the session pattern (workout, clinical measurement) fits a supported background execution context.
HealthKit Quantity Sample Accuracy for Regulatory-Adjacent Applications
HealthKit quantity samples carry a start date, end date, and source revision — sufficient for most consumer fitness applications, but requiring careful handling for regulatory-adjacent use cases. The source revision identifies the app version and device OS version that generated the sample, enabling provenance tracing. However, HealthKit performs deduplication across sources: if both the Watch app and the iPhone companion app write the same quantity type for overlapping time intervals, HealthKit's merge behavior varies by quantity type — cumulative types (step count) are summed, discrete types (heart rate) produce multiple samples that query results must de-duplicate. For medical monitoring applications, writing discrete samples with explicit start and end timestamps that do not overlap and carrying device serial number as metadata in the HKDevice parameter produces the most reliable audit trail. HealthKit's background delivery mechanism does not guarantee sub-second latency; for applications requiring real-time clinical alerting, a parallel data path — direct BLE notification to a background-capable iOS process — is more reliable than depending on HealthKit background delivery for time-critical thresholds.
Apple Watch Power Budget Engineering for Extended-Wear Medical Devices
Apple Watch Series 9 and later carry a battery sized for approximately 18 hours of typical use with AOD enabled, but typical use does not include continuous BLE Central, 50 Hz Core Motion, and frequent background task execution simultaneously. Power budget engineering for a 16-hour extended-wear session starts with component isolation: Core Motion at 50 Hz consumes approximately 3–5 mW depending on processing applied to the samples; BLE Central in connected state with 30 ms connection interval consumes approximately 2–4 mW; background task execution for WatchConnectivity transfer adds periodic spikes. The aggregate must remain below the 80 mW average budget implied by a 16-hour session from a full charge. Practical mitigations include reducing Core Motion rate during periods of detected low activity, extending BLE connection interval during phases where real-time data is not required, and batching WatchConnectivity transfers rather than sending per-sample. AOD mode adds approximately 2 mW for the reduced-update display, which must be reserved in the budget from the outset — attempting to retrofit AOD support after the power budget is fully allocated consistently requires removing another feature.
Products Built on This Platform
Wearable Electronics
watchOS apps for biometric data collection, real-time health monitoring, and BLE sensor integration.
View ProductMedical Devices
Regulatory-adjacent watchOS monitoring apps with HealthKit write authorization and provenance tracking.
View ProductPatient Safety
Fall detection and vitals monitoring watchOS apps for clinical and assisted-living environments.
View ProductGPS Tracking
watchOS location and activity tracking with background session management for field operations.
View ProductStructural Monitoring
watchOS display of real-time structural sensor alerts and threshold notifications for field inspection teams.
View ProductHardware-integrated watchOS apps, not fitness clones
Ankh builds watchOS apps in the context of a complete hardware product — the app is designed alongside the BLE peripheral firmware, the HealthKit sample schema is defined in the same sprint as the sensor calibration protocol, and the Watch's power budget is modeled against the hardware peripheral's transmission rate. We do not template watchOS apps from fitness trackers and remove features; we architect them from the peripheral outward. This means the Watch app's connection lifecycle matches the peripheral's connection state machine, and edge cases like simultaneous iPhone BLE connection and Watch BLE connection to the same peripheral are handled before they become field failures.
Health framework compliance for medical-adjacent products
HealthKit authorization, sample provenance, and background delivery semantics matter in a fundamentally different way for medical-adjacent products than for consumer fitness apps. Ankh's engineers understand the distinction between HealthKit data that informs user wellness and data that must satisfy a regulatory audit trail. We implement HKDevice metadata, source revision tracking, and sample timestamp precision to the standards that FDA-cleared software documentation requires. For products navigating the SaMD (Software as a Medical Device) classification process, we document the HealthKit data model in the format that 510(k) technical submissions expect.
Power budget engineering from the sensor hardware up
watchOS power budget engineering is not an afterthought at Ankh — it begins with the hardware peripheral's transmit rate, proceeds through BLE connection parameter selection, and terminates in a Core Motion sampling rate and background task schedule that fits the battery model. We build power budget spreadsheets before writing a line of watchOS code for extended-wear products, and we validate them against real Apple Watch hardware with a power monitor on the peripheral side. When the measured numbers disagree with the model, we diagnose at the radio layer — not by guessing which software feature to remove.