How is a watchOS app structured today versus the legacy WatchKit app and extension, and what do independent apps and extended runtime sessions change?

The old model (watchOS 1 to 6) split a watch app into a WatchKit app (storyboards and assets, running on the watch) and a WatchKit extension (the code, in a separate process on the watch, with the interface driven through WKInterfaceControllers). Since watchOS 7 there is a single watch app target (SwiftUI, a @main App with WindowGroup), the extension split is gone for new apps, and the app can be independent: it does not need an iPhone app to be installed (the “Watch App for iPhone” versus an independent watch-only app, declared by WKRunsIndependentlyOfCompanionApp), so it must be able to sign in, fetch data (through URLSession directly over Wi-Fi or cellular) and store its own data. A companion app instead depends on the iPhone for data and settings and uses Watch Connectivity. The runtime is constrained: the app is foreground for seconds to a couple of minutes (when the wrist drops it is suspended), the screen is small, memory is limited, and background work is scheduled by the system. Foreground time is very limited, so refresh data ahead of time: a WKApplicationRefreshBackgroundTask (scheduled with WKApplication.shared().scheduleBackgroundRefresh(withPreferredDate:userInfo:scheduledCompletion:), a few per hour, with the system choosing the time) updates content and the complication, and WKSnapshotRefreshBackgroundTask lets you prepare the app’s snapshot for the Dock and app switcher. Background URLSession downloads continue and wake the app on completion.

For longer foreground-like work, the watch has extended runtime sessions (WKExtendedRuntimeSession) in specific categories that keep the app running with a visible indicator: self care and mindfulness (10 minutes for guided sessions), physical therapy, smart alarm, health monitoring and workout processing (a HKWorkoutSession, which also keeps the app running and the screen on while a workout is active, with HealthKit data collection), and location (navigation). They are not classic app extensions, but share the idea that you are not the foreground iPhone app: each has a purpose, an Info.plist background mode and limits, and the system may end it. Notifications on the watch have a short look (a glance: icon, title) and a long look (the full content with action buttons), customisable with a WKUserNotificationInterfaceController or a SwiftUI notification scene, and are mirrored from the iPhone unless the watch app handles them itself. Practical guidance: keep every screen to one idea, make the first screen load from cached data, schedule refreshes sparingly, handle being offline or the phone being unreachable, test on a real watch for battery and background behaviour, and use the simulator for layout only.