Building for Apple Watch: What to Know

The most common watchOS mistake is porting an iPhone app. The wrist is a different interaction model — measured in seconds, glanced at rather than read, and used with one hand while doing something else.

The constraint that shapes everything

A watch interaction is a few seconds long. The user raised their wrist, and the screen will turn off shortly. Anything requiring sustained attention or meaningful input belongs on the phone.

Design for one piece of information and at most one action. Features that survive on the wrist are ones where the watch is genuinely more convenient than pulling out a phone — not ones that merely fit.

What works well

Glanceable status
One number or state the user checks repeatedly. Complications on the watch face are the strongest form of this — visible without opening anything.
Quick capture
Logging something in one tap while your hands are busy. Anything requiring typing does not belong here.
Remote control
Controlling something happening elsewhere — media, a timer, or a recording session. Our own Lookout uses this pattern for camera control.
Health and sensor data
The watch is on the body continuously, which is the entire reason heart rate and activity data exist. Our 70 BPM is an iPhone app built on exactly this data, read from Apple Health.
Timely notifications
Actionable alerts where a wrist tap is more appropriate than a phone buzz.

What does not work

Reading anything long. Browsing lists of more than a handful of items. Any meaningful text entry. Complex multi-step flows. Anything needing sustained attention, since the screen turns off. And anything requiring precision — fingers are large relative to the screen.

Technical realities

Power is the hard constraint. A watch app that drains the battery will be deleted, regardless of how good it is. Background work is tightly limited by the system, and that limit is not negotiable.

Independence vs pairing. watchOS apps can run independently with their own network access, or depend on the paired iPhone. Independent is better for users and more work to build, especially around syncing state.

Complications need budgeting. They are the highest-value surface — a permanent presence on the user's watch face — and they have their own update budget. The system decides how often you may refresh, so design for infrequent updates.

HealthKit has rules. Health data requires explicit permission per data type, cannot be used for advertising, and has specific App Store requirements. Background delivery of health data is possible but constrained.

SwiftUI is the path. watchOS development is SwiftUI-first, which is one of the practical advantages of building your iPhone app in SwiftUI too. See SwiftUI vs UIKit.

Is a watch app worth building?

Ask whether there is a moment when your user would rather look at their wrist than their phone. If you can name that moment concretely, build for it. If the answer is "it would be nice to have", the effort is usually better spent on the phone app.

A well-made complication with no app behind it is often more valuable than a full app nobody opens.

Our experience

We ship watchOS in Lookout, where the wrist moment is concrete: starting a recording without touching the phone. We deliberately did not build one for 70 BPM — it is iPhone-only, because the value there is reading a whole day of heart rate against your calendar, which needs a screen the watch does not have. That decision is the point of this guide: the watch earns an app when there is a wrist moment, not whenever the data happens to come from a watch.

Frequently asked questions

Is it worth building an Apple Watch app?

Only if you can name a specific moment when the user would rather look at their wrist than their phone. If the answer is that it would be nice to have, the effort is usually better spent on the phone app.

What works well on Apple Watch?

Glanceable status shown in a complication, one-tap quick capture, remote control of something happening elsewhere, health and sensor data collected continuously, and timely actionable notifications.

What does not work on Apple Watch?

Reading long content, browsing large lists, any meaningful text entry, complex multi-step flows, and anything requiring sustained attention, since the screen turns off quickly.

What is the main technical constraint on watchOS?

Power. A watch app that drains the battery gets deleted regardless of quality. Background execution is tightly limited by the system and those limits are not negotiable.

Should a watch app work without the iPhone?

Independent apps with their own network access are better for users but require more work, particularly around syncing state between watch and phone.

Talk to us about your build

KIDA Studios builds custom software, apps, games, AR and XR across Apple platforms, Windows, Android, web, and embedded. If you have a project in mind, a short discovery call is the fastest way to get a realistic scope and number.

Start a project