Implementing Data Synchronization Between iPhone and Apple Watch
Synchronization between iPhone and Apple Watch is a separate discipline with a set of constraints that differ significantly from regular network operations. Watch runs on watchOS and communicates with iPhone through WatchConnectivity. Without understanding transmission modes and Watch application lifecycle, we either lose data or drain the battery.
WatchConnectivity: Three Transmission Channels
WCSession provides several mechanisms, each for its own task:
updateApplicationContext — a dictionary that the system delivers when the Watch application is next activated. A new call overwrites the previous one. Suitable for "the last actual state": app settings, user profile. Not suitable for event queues — intermediate values are lost.
sendMessage — synchronous real-time transmission, works only when both applications are active. If the Watch application is in the background — the message is dropped. Response via replyHandler. Used for commands: user pressed a button on Watch, iPhone should respond immediately.
transferUserInfo — a queue that guarantees delivery even if Watch application is closed. Each call is queued separately, nothing is overwritten. Suitable for workouts, steps, events — everything important not to lose.
transferFile — file transmission (images, audio, databases). Also queued, delivered in the background.
import WatchConnectivity
class WatchSessionManager: NSObject, WCSessionDelegate {
private let session = WCSession.default
func setup() {
guard WCSession.isSupported() else { return }
session.delegate = self
session.activate()
}
// Sending current data (settings):
func syncSettings(_ settings: [String: Any]) {
guard session.isReachable else {
// Watch is not available now — use applicationContext for deferred delivery
try? session.updateApplicationContext(settings)
return
}
session.sendMessage(settings, replyHandler: nil)
}
// Sending event from queue (workout, transaction):
func enqueueWorkout(_ workout: WorkoutData) {
session.transferUserInfo(workout.dictionary)
}
}
Lifecycle and Typical Errors
A Watch application doesn't live permanently in the background. It has a strict budget: if the application hasn't been activated for a long time, watchOS will unload it. On next opening — applicationContext will arrive, sendMessage messages — no.
The most common error: developer uses sendMessage to deliver data from the last 8 hours (e.g., steps from HealthKit) and wonders why data is lost. sendMessage is only for real-time when both devices are active. For data "deliver on next opening" — use transferUserInfo.
WCSession.delegate must be set before activate(). Setting it after — doesn't cause a crash, but guarantees skipping the first events. In a SwiftUI project, create WatchSessionManager in @main App before the first View appears.
Handling on Watch Side
// WKExtensionDelegate or watchOS App lifecycle
func session(_ session: WCSession,
didReceiveApplicationContext applicationContext: [String: Any]) {
DispatchQueue.main.async {
// update UI only on main queue
self.viewModel.updateFromContext(applicationContext)
}
}
func session(_ session: WCSession,
didReceiveUserInfo userInfo: [String: Any]) {
// save data to Watch local storage
WorkoutStore.shared.save(userInfo)
}
WCSession handlers are called on background queue. Any UI update must be via DispatchQueue.main.async — this is not optional.
When WatchConnectivity Is Not Enough
If you need data synchronization without active connection to iPhone — CloudKit or Core Data with cloud sync. Watch has its own CloudKit container and can sync directly to the server, bypassing iPhone. This is important for scenarios when Watch works without iPhone (swimming workout, running without phone).
HealthKit is a separate story: workout, heart rate, and step data is stored in a shared HealthKit repository and is accessible on both iPhone and Watch through the same HKHealthStore API. No need to use WatchConnectivity for HealthKit data.
What's Included
- Setting up
WCSessionon both sides with correct lifecycle - Choosing transmission mechanism for each data type
- Queue
transferUserInfofor guaranteed delivery - Error handling and state checks:
isReachable,isPaired,isWatchAppInstalled - Testing on physical iPhone + Apple Watch (simulator WatchConnectivity is limited)
- Synchronization via CloudKit for Watch offline operation if needed
Timeline
3–5 days depending on the complexity of synchronized data and requirements for offline mode. Pricing is calculated individually after analyzing the project architecture.