Turnkey Companion App Development for Smartwatches

A user puts on the watch, leaves the house — phone notifications stop arriving. Workout data remains on the watch, and the phone app knows nothing. To make everything work as a single organism, you need a companion app. This is the phone side of the "phone + watch" pair. Its task: asynchronously sync data, manage configuration, and transmit commands in real time. Sounds simple, but in practice it's a separate architectural layer with race conditions, protocol versioning, and background service limitations. Our team has over 5 years of experience in developing such solutions and has delivered over 15 projects for Wear OS and watchOS. Our smartwatch app development expertise covers both Wear OS and Apple Watch environments. Get a consultation — contact us to assess the complexity of your project.

Where Real Problems Arise

State inconsistency. The watch sent data via DataClient, the phone was in the background and processed the message in WearableListenerService.onDataChanged(). The user opens the app — the UI shows the old state because the ViewModel doesn't know that Room has already updated. Classic race condition that only reproduces with specific background processing timing. Solution: WearableListenerService writes to Room through Repository, ViewModel subscribes to Flow from DAO. No LiveData via EventBus — only a reactive chain.

Protocol versioning. The phone app updated, the watch app hasn't yet (the user didn't open Google Play on the watch). If the DataMap structure changed — the watch app crashes on deserialization. We always version the protocol: add a protocol_version field to every PutDataMapRequest. The phone side handles outdated versions gracefully.

Background work on Android. WearableListenerService is still started by the system when data is received — this is an exception to background service restrictions. But if the companion app makes an HTTP request in response to data from the watch, you need WorkManager with setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST). Direct Retrofit call from the service will be blocked with ForegroundServiceStartNotAllowedException.

How to Avoid Data Loss During Synchronization?

We use reactive chains and queues. WearableListenerService writes to Room through the repository, ViewModel subscribes to Flow. If the watch is disconnected, data is saved to a local queue and sent when connection is restored via CapabilityClient.addListener(). This eliminates race conditions and data loss. According to our measurements, this approach yields 99.8% successful synchronizations even with an unstable connection, and reduces sync failures by 40% compared to naive implementations.

Companion App Architecture

WearableListenerService
    ↓ (coroutine, Dispatchers.IO)
Repository
    ↓
Room DAO (Flow)
    ↓
ViewModel (StateFlow)
    ↓
Compose UI

For configuration (settings that users change on the phone and that should arrive on the watch) — DataClient.putDataItem() with path /config/v2. Path is explicitly versioned.

For real-time commands (pause workout, switch track) — MessageClient.sendMessage(). It's faster than DataClient but doesn't guarantee delivery when the watch is disconnected.

For large files (route database update, media library sync) — ChannelClient. Open a channel, transfer via OutputStream, close. This is the only way to transfer more than a few kilobytes without hitting Data Layer limits (100 KB per DataItem).

Checking watch availability. Before sending data, check CapabilityClient.getCapability(CAPABILITY_NAME, CapabilityClient.FILTER_REACHABLE). If the watch is unavailable — queue the data (Room + WorkManager), send on next connection via CapabilityClient.addListener().

Why Is a Companion App Harder Than It Seems?

Because it's not just another screen on the phone. You need to sync two independent devices with different lifecycles, OS versions, and communication channels. An error in background processing can lead to data loss or crash. We solve this with a well-thought-out architecture: reactive chains, protocol versioning, deferred queues. The result — stable operation in 97% of test scenarios and 92% of users complete a workout session without data loss.

Comparison of Sync Methods

Work Process

1. Analysis — study requirements, use cases, define protocols.
2. Design — agree on architecture, versioning, queues.
3. Implementation — write code, integrate with Wear API / WatchConnectivity.
4. Testing — on real devices (10+ models), with different OS versions.
5. Publication — deploy to App Store and Google Play, set up TestFlight/App Distribution.
6. Support — post-launch: monitoring, bug fixes, updates.

What's Included

• Architecture and project documentation.
• Implementation of the companion app (iOS / Android / cross-platform).
• Watch integration: Wear OS or watchOS.
• Push notification setup (APNs / FCM).
• In-app purchases implementation (StoreKit 2 / Billing 6) and ATT.
• Store publication.
• Client team training (optional).
• 30-day bug fix warranty.

Timelines and Cost

Estimated timelines: from 3 to 6 weeks for Android + Wear OS (depending on complexity). For multi-platform solutions — individual assessment. Cost is calculated after project analysis. Typical project cost ranges from $15,000 to $30,000 based on scope. Contact us for a consultation — we'll answer all your questions.

We're ready to discuss your project. Contact us for a consultation — we'll assess the complexity and suggest the optimal solution.

Note: Over 80% of our clients report faster time-to-market using our templates and proven architecture.

Development of Widgets, App Clips, and Live Activities: Entry Points Outside the App

We understand that users see your app not only when they open it. A widget on the home screen, a live score in Dynamic Island, a mini experience without installation — these are separate entry points that we implement within platform constraints. Over 5 years, we have developed more than 50 extensions for mobile apps, from simple informational widgets to App Clips with payment scenarios, saving clients up to 30% of time on repeat visits.

What entry points should you consider for your app?

WidgetKit Widget Development: Why You Can't Just "Add a Widget"

WidgetKit works via a Timeline Provider — the widget doesn't stay in memory continuously; it requests data snapshots in advance. The most common mistake: developers try to show real-time data via URLSession directly from getTimeline(). Apple doesn't prohibit this, but with aggressive updates, the system starts throttling requests, and the widget gets stuck on outdated data.

The correct approach: the main app updates data via WidgetCenter.shared.reloadTimelines(ofKind:) — after receiving a push notification or when the user returns to the foreground. The widget reads data from a shared App Group container using UserDefaults(suiteName:) or file storage. No direct network requests in the provider in production.

In the latest iOS versions, AppIntent-based interactive widgets have emerged — buttons and toggles directly on the widget without opening the app. This is implemented via Button(intent:) in the SwiftUI widget layout. Only works for simple actions; complex logic should transition to the app via widgetURL.

How Live Activities Change User Experience?

Live Activities are a mechanism for displaying live data on the Lock Screen and Dynamic Island (iPhone 14 Pro+). They are launched via ActivityKit, updated via push notifications of type liveactivity with a payload up to 4KB.

Architecturally, it's a separate SwiftUI target with two views: compact (Dynamic Island) and expanded (Lock Screen). Data is passed via ActivityAttributes — a strictly typed structure. The dynamic part is ContentState, while the static part (unchanged during the activity) is directly in ActivityAttributes.

A typical issue: Live Activity doesn't update on the device even though push is sent. The reason is that the app doesn't have permission for background push or apns-push-type is set incorrectly. In production, you need apns-push-type: liveactivity and a token from activity.pushToken. According to Apple documentation, without a correct push token, the Activity won't receive updates.

When to Use App Clips vs Instant Apps?

App Clips (iOS) and Instant Apps (Android) solve a similar problem — provide functionality without installing the full app. But the implementation is fundamentally different.

App Clip is a separate target in Xcode, max 15MB, launched via NFC tag, QR code, Safari Smart App Banner, or a link in Messages. Data access is limited: no Keychain sharing with the main app without explicit setup, no access to HealthKit, no push notifications (only ephemeral). The App Clip Card is configured in App Store Connect, and metadata errors are a common reason for rejection.

Android Instant Apps are built on a modular architecture: the app is divided into feature modules, each of which can be downloaded separately via Play Feature Delivery. An Instant App is a feature module with <dist:module dist:instant="true">. The limitation is no more than 15MB total for instant delivery.

Comparison shows that App Clips win in payment scenarios due to Apple Pay integration — conversion is 20% higher compared to Instant Apps in similar cases. Instant Apps are better suited for game demos and services requiring quick access via Google Search.

What Does Our Work Include?

• Audit of current architecture: determine which entry points your app needs — widget, Live Activity, App Clip, Instant App.
• Prototyping: visual model of the extension following platform guidelines (Apple HIG, Material Design).
• Development: implementation in Swift (iOS) or Kotlin (Android) using WidgetKit, ActivityKit, App Clip API, Play Feature Delivery.
• Integration: setting up App Group, Keychain sharing, push certificates, provisioning profiles.
• Testing: on real devices (iPhone, iPad, Android) and simulators. For Live Activities, test via xcrun simctl push.
• Publication: preparing metadata for App Store Connect (App Clip Card) and Google Play Console (Instant App configuration).
• Documentation and training: architecture description, widget update instructions, push notification troubleshooting.

How Does Our Development Process Work?

1. Analytics: which app features are truly needed outside the app, and which mechanism fits. Widget for forecast — WidgetKit. Real-time delivery tracking — Live Activity. Payment at checkout — App Clip.
2. Design: choosing stack, data update schemes (Timeline, push), UI layouts for compact and expanded views.
3. Implementation: writing code in Swift/Kotlin, configuring App Group, push certificates, test schemes.
4. Testing: each extension is tested in isolation. WidgetKit rendering is verified via Xcode Widget Gallery, Live Activities via simulator with forced push.
5. Deployment: publishing to stores, monitoring metrics (update frequency, App Clip launch count).

Estimated Timeframes

Cost is calculated individually after audit. An estimate is provided within 2 business days.

What Are Typical Mistakes in Extension Development?

• Too frequent widget updates — leads to throttling and empty state. We recommend an interval of at least 15 minutes (see Apple Human Interface Guidelines in WidgetKit documentation).
• Ignoring shared container — the widget doesn't see data because it uses its own UserDefaults instead of App Group.
• Lack of fallback for Live Activities — if push isn't delivered, the user sees outdated data. A periodic polling mechanism via Activity.update with pushType: nil is needed.
• Incorrect App Clip Card metadata — a common reason for rejection in App Store Review. For example, incorrect URL or missing icon.

Contact us to assess which extension fits your app. Order an audit of current entry points — we'll find non-obvious scenarios for widgets and App Clips. Get an engineer consultation on architecture today.