Design a Mobile Wearable Companion App: Apple Watch-Style

Designing a mobile wearable companion app like an Apple Watch app or Wear OS counterpart is a multi-device system design problem. The phone is the “brain” — the watch is a constrained client with limited storage, weak network, and aggressive battery requirements. The interview tests whether you understand the watch-phone synchronization patterns, complications, and what fits where.

Functional requirements

• Watch displays the user’s key data at a glance
• Data syncs from phone to watch
• Watch can perform actions (start workout, log entry)
• Complications (small data widgets on the watch face)
• Fall back gracefully when phone is unreachable

Architecture

Two devices, two apps, one shared data model. The watch app is constrained; design accordingly.

Data sync

iOS: WatchConnectivity framework. Methods:

• updateApplicationContext — small, latest-state, low-priority
• sendMessage — synchronous, requires both apps active
• transferUserInfo — guaranteed, queued, asynchronous
• transferFile — for larger payloads

Wear OS: Wearable Data Layer with similar primitives (DataItems, MessageClient, ChannelClient).

What lives where

Phone is the source of truth for most data. The watch:

• Reads recent / glanceable data
• Captures user interactions for sync to phone
• Renders the UI
• Does not perform heavy computation or networking

Apps that put too much logic on the watch are slow and battery-hungry.

Complications

Tiny widgets on the watch face. iOS uses ClockKit (or WidgetKit in newer OS); Wear OS uses ComplicationDataSource.

Constraints:

• Refresh budget — typically 50–60 refreshes per day
• Render time must be very fast (<50ms)
• Tap action opens the app

For frequently changing data, the complication shows a stale snapshot until the watch app or phone pushes an update.

Workouts

Independent watch workout sessions are common — the user starts a run from the watch, leaves the phone behind. The watch:

• Tracks heart rate, GPS (if equipped), distance, calories
• Stores the workout locally
• Syncs to phone when reconnected

The phone handles longer-term storage, charts, and uploading to backend services.

Battery considerations

The watch has 1/10 the battery of a phone. Mitigations:

• Always Show display has a separate, lower-power rendering
• Background tasks are budget-limited; the OS schedules them
• App lifetime is short; suspend aggressively
• Use system data (HealthKit) rather than custom sensor reads

Falling back without phone

If the watch is paired but the phone is out of range:

• Cellular watches can use their own cellular connection (Apple Watch with cellular plan)
• Wi-Fi watches can use known Wi-Fi networks
• Otherwise, queue actions for sync when the phone returns

Standalone watch apps

Apple Watch increasingly supports independent apps. The watch app can fetch data over its own network. Useful for music streaming during workouts, podcast playback, payments.

Wear OS has had this since launch. Apps designed standalone-first run on Wear OS without a paired phone.

Frequently Asked Questions

How do you handle the watch and phone being out of sync?

Each side has a “last synced at” timestamp. On reconnect, fetch deltas in both directions. Conflicts resolve by latest timestamp (with some user-facing surfacing if material).

Should the watch UI mirror the phone UI?

No. Design for the watch separately — glanceable, minimal, single-task focused. Mirroring produces hostile UX.

What about Always Show on the watch?

Render a low-power version of your UI: less detail, dimmer, fewer animations. Both Apple and Wear support distinct rendering modes.