I added an Apple Watch companion to Dentii. The brushing timer on the iPhone had to work on the Watch too, tracking while the user moved around. I’d estimated “a few days”. It ended up being three weeks, because watchOS plus iOS companion architecture comes with its own set of rules.
Here are the five critical decision points.
1. Standalone or companion?
Apple Watch apps run in two modes:
Companion: doesn’t work without the iPhone app. Data and auth depend on the iPhone.
Standalone: independent, runs without the iPhone. Users can install it directly to the Watch from the App Store.
watchOS 7+ made standalone the default. But being “truly standalone” means:
– Authentication works on the watch
– Data lives on the watch (synced via CloudKit)
– Separate App Store submission, essentially two apps
I went companion for Dentii because:
– The user’s first experience is onboarding on the iPhone
– Data is already in CloudKit, the iPhone authenticates
– No separate signup on the Watch means a simpler UX
Decision rule: does the user find Watch value without the iPhone? Yes, standalone. No, companion.
2. Data sync: WatchConnectivity or CloudKit?
Two main paths for syncing data between Watch and iPhone:
WatchConnectivity framework:
– iOS and watchOS send messages directly
– Over Bluetooth, no shared network required
– Real-time, fast
– But: both devices must be awake and nearby
CloudKit:
– Data goes to the cloud, both devices read from it
– Works offline (local cache)
– Propagates automatically to every device
– But: it lags, and the network has to be there
The best answer is to blend them.
Critical real-time data (an active brushing session): WatchConnectivity.
Persistent data (history, settings): CloudKit.
That way when the user starts brushing on the Watch, the iPhone syncs instantly, and history stays current on both devices through CloudKit.
3. Watch UI strategy: how much do you actually put on the Watch?
The Apple Watch screen is 42mm to 49mm. The user glances at it for three to five seconds. Shipping every iPhone feature to the Watch is an anti-pattern.
For Dentii I boiled the Watch UI down to three screens:
Screen 1 (default): did you brush today? A big green or red indicator.
Screen 2: active brushing timer. 2 minute countdown with haptic feedback.
Screen 3: this week’s consistency. A simple dot grid.
Everything else stays on the iPhone. The Watch is for quick glance plus action, not deep interaction.
Where a richer Watch UI does make sense:
– Fitness apps (run tracking, heart rate)
– Meditation (active session)
– Payments (Apple Pay integration)
– Navigation (hands-free)
Outside those, stay minimal.
4. Complications and Lock Screen widgets
On Apple Watch, complications are the mini widgets embedded in the watch face. iOS 16+ Lock Screen widgets are built with the same SwiftUI WidgetKit framework.
Things to keep in mind when designing a complication:
Refresh is throttled hard: watchOS complications are limited to 50 refreshes a day. Roughly one every 30 minutes at most.
Multiple styles: modular, circular, utilitarian, each watch face uses different styles. Support at least three.
Relevance score: Smart Stack decides which complication bubbles up when. The Dentii complication’s relevance climbs toward evening (brushing time).
In my experience, very few users actually set up complications, it takes four or five taps to add one to a watch face. But the ones who do are deeply engaged. Worth it for heavy users.
5. Haptic feedback
Haptics are the Apple Watch’s most powerful feature. The user can get information without looking at the screen.
In Dentii the brushing timer pulses haptic every 30 seconds. The user can brush without looking at the screen and still feel “I’m on track” from the vibration.
Haptic types (WKHaptic):
– .notification, standard alert
– .directionUp, .directionDown, direction
– .success, .failure, result
– .retry, retry
– .start, .stop, timer flow
– .click, button feedback
Used well, you get screen-less UX. Used poorly (too frequent, too strong), it’s irritating.
The rule: at most one haptic every 30 seconds. More than that and users take the watch off.
Development tips
If you haven’t built an Apple Watch app before:
Use the simulator. Watch simulator is slow but covers most flows.
Test on a real device. Haptics, digital crown, force touch, the simulator doesn’t deliver those.
Paired debugging. Debug iPhone and Apple Watch together. Xcode’s dual debugger is excellent.
Watch battery carefully. A Watch app can drain the battery. Be careful with background update frequency, network calls, and animation.
Submission details. The Watch app ships with the iPhone submission but has its own review criteria. A Watch-only app is a separate submission.
Performance notes
The Watch CPU is much weaker than the iPhone:
– Minimise network calls
– Don’t load large images on the Watch
– Do JSON parsing on the iPhone and send parsed data to the Watch
– Target 30fps in SwiftUI animations, not 60fps
Custom charts or complex drawing freeze the Watch. Lean on Apple’s stock UI components.
Takeaway
Building an Apple Watch companion is not the same as building an iPhone app. Different constraints (screen, battery, CPU), different UX principles (quick glance plus action), different data sync architecture.
Dentii took three weeks. With the patterns in place, future ones can be done in a week. If it’s your first time, budget generously, read Apple’s sample code, start small.
The real question: will the user actually reach for the Watch app, or am I adding it for the sake of completeness? If it’s the second, don’t bother.