How do you design for the Digital Crown, the always-on display and the watch’s battery and CPU limits?

Input. The watch has taps and swipes on a small screen, the Digital Crown (a rotating dial with haptic detents, the right control for scrolling, adjusting a value or stepping through items), the side button, the Action button on Ultra and some models (an app can be assigned to it for a primary action) and the double-tap gesture on newer models. In SwiftUI, a view reads the crown with .digitalCrownRotation($value, from:through:by:sensitivity:isContinuous:isHapticFeedbackEnabled:) (the view must be focusable, .focusable(), to receive crown events; the modifier exists on watchOS and is unavailable on tvOS) and long lists scroll with the crown automatically. Design principles: one primary action per screen, large tap targets, short text, no precise gestures, and use haptics (WKInterfaceDevice.current().play(_:)) for confirmation. Always-On display: when the wrist drops, the watch dims and keeps showing the app in a low-power mode with a very limited update rate (about once a second or slower): read @Environment(\.isLuminanceReduced) to redraw with less detail (hide seconds and animation, dim bright colours, show only essential information), because high-contrast, high-motion screens burn battery and OLED. The app’s scenePhase still goes inactive and active as the wrist moves, so keep rendering cheap in every phase, and an app state check reads WKApplicationState as active (0), inactive (1) or background (2).

Battery and CPU. The watch’s CPU, memory and battery are a fraction of the iPhone’s, so never assume phone-class resources: keep work tiny and bursty, avoid long loops and large in-memory models, decode small images, and do heavy processing on the phone or the server. Foreground time is short (the app is suspended soon after the wrist lowers, except during workouts and extended runtime sessions), so make the first screen appear instantly from cached data, and do not start work that cannot finish quickly. Background work is scheduled by the system: request WKApplication.shared().scheduleBackgroundRefresh(withPreferredDate:userInfo:scheduledCompletion:) sparingly (about a few per hour, with the system choosing the moment, and not guaranteed), handle WKApplicationRefreshBackgroundTask and complete every task with setTaskCompletedWithSnapshot, use background URLSession for downloads, and have complications and Smart Stack widgets carry future entries (see the widgets topic). Measure: profile with Instruments (Energy Log and Time Profiler) on a real watch, watch the battery after a day of use, and test cold launch time and the always-on state, since the simulator hides power effects. Remember that wrist-raise launches and complication taps are the dominant entry points, so each must work without the phone and without a network.