Companion App — what it is, developing companion applications

What is a Companion App — an application for wearable?

Companion App — an application for wearable devices Apple Watch or Wear OS that ships alongside a main iOS or Android app. The main goal is to extend functionality to the wrist: quick information viewing, replying to messages, controlling music, tracking workouts. The Companion App is automatically installed on the watch when the main app is installed on the phone, provided the developer included it in the build.

Architecture of a companion app includes two components: the iOS/Android app (main) and the watchOS/Wear OS app (companion). Communication between them is handled through system APIs: WatchConnectivity for Apple and Wearable Data Layer for Google. Data is transferred in the background via Bluetooth or Wi-Fi — the user does not see the synchronization process. The watch app can have its own UI, different from the mobile one, adapted for a small screen.

Types of companion apps differ in their degree of dependence on the phone. Mirroring apps display a copy of the phone data and do not work without a connection. Decoupled apps have their own logic, cache data, and retain some functionality when disconnected from the phone. Independent apps (watchOS 6+ and Wear OS 3+) can be installed without a phone and work fully autonomously with their own network access.

WatchConnectivity: syncing iPhone and Apple Watch

WatchConnectivity — Apple's framework for two-way communication between iPhone and Apple Watch. It provides four data transfer mechanisms: Application Context (last known state), File Transfer (files of any size), User Info (dictionaries with guaranteed delivery), and Interactive Messaging (real-time two-way communication). The system automatically chooses Bluetooth or Wi-Fi based on distance and signal quality.

import WatchConnectivity

class PhoneSessionManager: NSObject, WCSessionDelegate {
    func activateSession() {
        WCSession.default.delegate = self
        WCSession.default.activate()
    }
    func sendWorkoutData(_ data: WorkoutData) {
        let dict = ["heartRate": data.heartRate,
                     "calories": data.calories] as [String: Any]
        WCSession.default.transferUserInfo(dict)
    }
    func session(_: WCSession,
               didReceiveUserInfo: [String: Any]) {
        DispatchQueue.main.async {
            NotificationCenter.default.post(
                name: .workoutDataReceived,
                object: didReceiveUserInfo)
        }
    }
}

Interactive Messaging — the only WatchConnectivity mechanism with guaranteed real-time delivery. A message is sent and receives a response within 200–500 ms when the connection is active. It is used for actions requiring an immediate response: starting a workout, confirming a payment, opening a smart home door. The session must be active on both devices — if the watch is locked or the app is in the background, delivery is not guaranteed.

File Transfer API is designed for large amounts of data — images, audio files, exported workouts. Files are transferred in the background even when the app is closed. The limit is up to 10 concurrent transfers in the queue. Application Context is the most economical mechanism: it transmits only the latest state, canceling previous unsent contexts. It is ideal for syncing settings and current status.

Wearable Data Layer: syncing Android and Wear OS

Wearable Data Layer — an API from Google Play Services for syncing data between an Android device and Wear OS watches. It provides three protocols: DataItem (key-value pair synchronization), MessageClient (one-way messages), and ChannelClient (streaming data). DataItems are synchronized automatically via Google Cloud — if the phone is unavailable, data is delivered when the connection is restored.

class WearableSyncService : WearableListenerService() {
    override fun onDataChanged(dataEvents: DataEventBuffer) {
        dataEvents.forEach { event ->
            when (event.type) {
                DataEvent.TYPE_CHANGED -> {
                    val uri = event.dataItem.uri
                    val path = uri.path // /workout/heartrate
                    val data = DataMapItem
                        .fromDataItem(event.dataItem)
                        .dataMap
                    val bpm = data.getInt("bpm")
                    updateUI(bpm)
                }
            }
        }
    }
}

MessageClient — sends one-way messages with a path and byte array. It is used for commands like "Start workout" or "Pause music". The message is delivered reliably if the device is connected. To receive messages on Wear OS, implement WearableListenerService and register it in the manifest. MessageClient does not support automatic caching — if the watch is disconnected, the message is lost.

ChannelClient — a protocol for streaming data: audio, video, continuous sensor streams. It opens a two-way channel through which byte arrays are transmitted. It is supported only on Wear OS 2.0+. ChannelClient is useful for transmitting audio from the phone to the watch for calls via Bluetooth and for relaying data from external Bluetooth sensors (heart rate monitor, bike computer) through the phone to the watch.

Autonomous operation of a companion app on the watch

Autonomous operation — the ability of a companion app to function without a phone connection. On watchOS with a Cellular module, the app sends network requests directly via eSIM. On Wear OS with LTE, similar functionality is available. Even without a cellular module, the watch caches the latest data from the phone and displays it when disconnected — the user sees the information that was current at the time of the last sync.

Data caching — a key element of autonomous operation. The app must save the last received state to the watch's local storage. On watchOS, UserDefaults or CoreData is used; on Wear OS, Room Database or DataStore. When the connection is restored, the cache is updated through background synchronization. If the data is more than 24 hours old, the app shows a stub message "Update your phone connection".

Wearable UI for a limited screen — the watch has a 1.5–2 inch screen — the companion app interface should be as concise as possible. Apple recommends NavigationView with a single column on watchOS, Google recommends a card list on Wear OS with a swipe for navigation. Buttons should be at least 44pt for comfortable touch. Avoid text input fields — use preset replies, dictation, or the Digital Crown scrolling wheel.

Energy-efficient design — the companion app should not drain the watch battery in a few hours. Use background updates with a minimal interval. On watchOS, WatchConnectivity pauses transfers when the battery is low and resumes after charging. On Wear OS, Wearable Data Layer automatically groups small transfers into one to save energy. Wrist raise — update the UI only when the user raises their wrist.

Best practices for developing companion apps

Companion app architecture should be designed with potential connection loss in mind. Use the Repository pattern: a single data source on the phone syncs with the local repository on the watch. The ViewModel on the watch subscribes to the local repository and displays data regardless of connection state. When the connection is restored, the Repository on the watch requests data via WatchConnectivity or Wearable Data Layer and updates the local storage.

class WorkoutRepository constructor(
    private val localStorage: WorkoutDao,
    private val wearableClient: WearableClient
) {
    val workoutFlow: Flow<Workout?> = merge(
        localStorage.observeWorkout(),
        wearableClient.observeWorkout()
            .onEach { localStorage.save(it) }
    )
}

Testing a companion app requires verification on real watches or an emulator. Xcode supports the Apple Watch simulator paired with the iPhone simulator — you can test WatchConnectivity without physical devices. Android Studio includes a Wear OS emulator with Wearable Data Layer support. Critical test cases: connection loss during transfer, low battery, simultaneous operation of two companion apps, and installation without a phone on standalone watches.

Publishing a companion app on watchOS does not require a separate upload to the App Store — the app is included in the iOS app binary and is automatically offered for installation on the watch. On Wear OS, the companion app is published separately on Google Play but is linked to the main app through the same package. App Group on iOS and sharedUserId on Android allow the main and companion apps to use shared data storage.