Smartwatch App Development: A Complete Guide to Wear OS

Most teams building for a smartwatch treat it as a smaller version of the phone app. But in reality, it can be the wrong starting point.

What’s different is that the screen is a third of the size, sessions last seconds, and users need results in two taps, or they don’t bother. Battery tolerates nothing wasteful. A design that works on a phone becomes unusable on a watch without deliberate rethinking.

With over 562 million users worldwide and the Android Wear OS segment valued at USD 48.4 billion in 2025, this is a development surface that demands its own architectural thinking.

This Wear OS app development guide is for product teams and engineering leads deciding whether to build for Wear OS and how to do it correctly. Here, we’re talking about how smartwatches work, what platforms exist, the must-have feature set, the two main development approaches, what makes Wear OS different from regular Android, the full development process, and what publishing on Google Play actually requires.

How smartwatches work

A smartwatch is a wrist-worn device with a touchscreen, onboard sensors, and the ability to run third-party apps. It works like a miniature smartphone, but the constraints are different enough to require a separate development approach.

Smartwatches operate in two modes. In standalone mode, the device works independently. Some models include a SIM card for calls and messaging without a paired phone. In paired mode, the watch connects to a smartphone via Bluetooth and routes data through it. Most users run in paired mode, which extends the watch as a second screen for notifications, health sync, and key app actions.

Modern smartwatch hardware includes GPS, optical heart rate sensors, accelerometers, gyroscopes, barometers, and NFC chips for contactless payments. The sensor stack is what makes health monitoring genuinely useful.

The watch OS manages all of this: app lifecycle, sensor data processing, Bluetooth and Wi-Fi, health data collection, and notification routing. It is optimized for a smaller screen, constrained battery, and short interactions measured in seconds.

Smartwatch platforms and OS options

The smartwatch OS landscape is concentrated. Two platforms dominate. Two serve specific niches. That split directly shapes your development decision.

Wear OS by Google

Wear OS launched in 2014 as Android Wear, then rebranded in 2018. It runs on the Samsung Galaxy Watch, Mobvoi TicWatch, Fossil, Skagen, and others. The platform’s core advantage is simple: it is built on Android. Kotlin, Android Studio, and the core mental model all carry over. What differs is the UI layer, battery constraints, and a set of missing packages covered below.

Wear OS supports standalone apps installed directly from Google Play on the watch, with no phone pairing required for installation or basic operation.

watchOS by Apple

watchOS powers Apple Watch exclusively and pairs only with iPhone. Apple held approximately 28% of the global smartwatch market in 2025, making it the largest single platform by shipments. If your primary product is iOS-native, a watchOS companion is the natural extension. The two ecosystems do not overlap on the development side. A Wear OS app does not run on an Apple Watch.

If a cross-platform wearable strategy is on the roadmap, it is worth reviewing how an iOS mobile app development company approaches watchOS alongside Android work.

Garmin Connect IQ

Garmin Connect IQ supports downloadable apps, widgets, watch faces, and data fields across 100+ Garmin devices. The platform serves athletes, outdoor enthusiasts, and users who need advanced performance metrics. If your app targets health professionals, runners, or trail athletes, Garmin has the installed base that matters.

Huawei HarmonyOS

HarmonyOS powers Huawei’s smartwatch lineup with a lightweight kernel designed for fast data processing and low power consumption. Huawei reached 17% global market share in early 2025, largely driven by Chinese market dominance. The system is optimized for IoT connectivity and long battery life, which suits continuous health monitoring use cases.

Smart watch function list: what users expect

The smartwatch function list for a given product depends on the target audience. Most of these features are now treated as baseline by users. If your app is missing them where they apply to your use case, users notice.

1. Notification mirroring. Display and interact with SMS, calendar alerts, and app notifications forwarded from the paired phone. Users can read, dismiss, and in some cases reply via voice or keyboard.
2. Health and fitness tracking. Heart rate, step count, calorie burn, sleep analysis, blood oxygen, and stress indicators. Over 92% of smartwatch users rely on their device for health and fitness tracking, making this the most-used feature category.
3. GPS navigation. Location tracking via onboard GPS or data relayed from a paired phone. Supports turn-by-turn directions and geofencing for safety applications.
4. Call handling. Accept, decline, or transfer calls. Devices with built-in microphones and speakers handle calls directly. Others route audio through Bluetooth headsets.
5. Safety features. Geofencing, SOS alerts, fall detection, and watch-removal alerts. Particularly relevant for apps targeting children’s safety or senior care.
6. Media control. Play, pause, skip tracks, and adjust volume. Platforms like Spotify and YouTube Music have native Wear OS apps.
7. Contactless payments. NFC-based payments via Google Wallet. No card, no phone required at the point of sale.
8. Voice assistant. Google Assistant on Wear OS enables voice commands for navigation, reminders, and app interactions, reducing dependency on the small touchscreen.
9. Health alerts. ECG readings, irregular heartbeat detection, and high/low heart rate notifications. FDA clearances are expanding for certain medical-grade use cases.
10. Standalone operation. Since Android Wear 2.0, Wear OS apps can operate independently from a phone, with direct access to Google Play on the device.

The more standalone functionality your app requires, the more it must handle battery management on its own. Continuous GPS tracking and real-time sensor polling can drain a 300mAh battery in hours. Design for glanceability.

Two core approaches

Before any code is written, one architectural decision shapes everything else: are you building a dedicated watch app or extending an existing mobile product to the wrist?

Dedicated (standalone) app. All logic, data storage, and UI live on the device. This suits single-purpose apps like a fitness tracker, meditation timer, or specific health monitor where the phone is not the primary interface.

Companion extension. A wearable module is added to an existing mobile app. The watch surfaces key actions and data from the phone. This is the more common pattern, particularly for fintech, communication, and productivity products that already have a mobile audience.

The technical complexity difference between the two is real. A dedicated app is closer to standard mobile app development in its structure. A companion extension requires managing two-way communication between the watch module and the phone, plus handling sync failures gracefully when the Bluetooth connection drops.

If the right approach for your product is not yet clear, a product discovery service will help scope the build before development begins.

Wear OS vs. Android: what actually differs

Wear OS is built on Android, so the core mental model carries over. The language is Kotlin. The IDE is Android Studio. However, several Android packages are absent from the Wear OS environment. Knowing this upfront prevents build failures later.

Missing packages on Wear OS:

• android.webkit — the web rendering engine used by mobile browsers. Not available on Wear OS.
• android.print — print support classes. Not applicable on watch hardware.
• android.app.backup — backup and restore functions are excluded.
• android.appwidget — home screen widget components are not available.
• android.hardware.usb — USB peripheral communication is not supported.

These exclusions rarely affect core watch app functionality. The problem arises with third-party libraries that depend on android.webkit or android.print under the hood. Check your dependency tree early in the project.

Wear OS development: technical guide

Application structure

In Android Studio, start a new project and select the Wear OS tab. Choose an empty activity or another available template.

The project contains two modules: a wear module for the smartwatch and an app module for the phone or tablet. For existing projects, go to File > New > New Module, select Wear OS Module, and configure it.

Both modules compile into separate APK or AAB files. They must share a package name and be signed with the same certificate at release. This is non-negotiable: it allows the two apps to communicate through Google Services.

UI layout for Wear OS

Watch screens vary: round, square, or round with cropped corners, ranging from 38 mm to 46 mm. Designing UI that works across these shapes is one of the defining challenges of Android wearable device app development.

Google’s current recommendation is Jetpack Compose for Wear OS as the primary UI toolkit. The latest Material 3 Expressive library adds purpose-built Wear components, including EdgeButton, TransformingLazyColumn, and the ScreenScaffold pattern. Compose for Wear OS now supersedes the older compose-material library per Google’s official documentation.

For teams still working with the older View-based Wear UI Library, two layout components remain useful for legacy codebases:

BoxInsetLayout adapts child elements to round displays by placing them in the rectangular area inscribed within the screen circle. For square displays, the system ignores this transformation, so the layout remains consistent across all screen shapes.

WearableRecyclerView is a scroll list adapted for watch screens, handling cropped upper and lower views near rounded edges.

WearableLinearLayoutManager enables scrolling via a mechanical crown on supported hardware and brings list items near the screen edges to the center, which makes reading easier on round interfaces.

Google’s open-source Horologist library provides working implementations of scroll scaffolds, progress indicators, and time-text components. It fills gaps the core Wear Compose libraries leave and saves teams from rebuilding common patterns from scratch.

How data sync works: DataLayer API

The DataLayer API manages data sync between all wearable devices connected to a single Google account. It selects the most efficient transmission path automatically, whether Bluetooth, Wi-Fi, or mobile data, and guarantees delivery to the target device.

DataLayer has five core components:

DataItem is the workhorse for most companion extension scenarios. You create a data request, populate it with key-value pairs, and hand it to the DataClient. The item is then stored and accessible from all paired devices on the same Google account.

Assets handle files exceeding 100KB, such as photos or audio. An important design consideration: the DataItem may arrive before the asset finishes transferring, so your UI must handle this loading state gracefully.

Messages handle one-off transmissions to a specific node. Use the CapabilityClient to identify available nodes before sending, so the message reaches the right device.

Channels handle real-time streaming. A voice memo sent from a watch to a phone is a typical channel use case. You obtain a client through the Wearable API and open the appropriate input or output stream.

Capabilities let you register what a given device can do, so messages are targeted precisely. You define a string array in your app resources to declare capabilities, and other devices in the network can query those declarations.

Treat the DataLayer message protocol as a mini API design exercise. Define the message schema, version it from the start, and plan for the watch to work in offline mode without blocking the user. Most companion extension bugs originate here.

The full process of development

Phase 1: Discovery

A proper discovery phase in project development covers market and competitor research, requirement gathering, user needs analysis, feature prioritization, and technology stack selection.

For a companion extension, the tech stack is partly predetermined: the watch OS must match the OS of the main mobile app. An iOS app extends to watchOS; an Android app extends to Wear OS. For a standalone watch app, choosing a technology stack for mobile app development is an open question. Kotlin with Jetpack Compose for Wear OS is the current standard for Wear OS app development.

Phase 2: UI/UX design

Wearable design isn’t phone design resized. Interactions are different: taps, swipes, crown rotation on supported hardware, and voice commands. Sessions are measured in seconds. Users should complete key tasks in two taps. If they can’t, the design needs rethinking.

For companion extensions, the design system from the mobile app typically carries over, but every screen must be reconceived for a 1.5-inch display. Navigation flows that work on a phone become unusable on a watch without deliberate restructuring.

Design for round screens first. Cropping issues on round displays are harder to fix late in development.

Phase 3: Development

Development for companion extensions splits into two distinct tracks.

Core development covers the watch app’s main functionality: UI in Compose for Wear OS, sensor data collection via Health Services APIs, local data storage, and watch-specific business logic. This part is close to standard android app development services in structure.

Interaction development is unique to companion extensions. It covers the two-way communication layer between the watch module and the phone app. This includes DataLayer API integration, capability registration so each device can discover the other, and handling reconnection and sync recovery when the Bluetooth connection drops.

Teams with existing Android experience often underestimate this layer. What happens when the phone is off? When the user switches phones? What about data conflicts between devices? These edge cases require careful handling, and usually, this is the place where companion extension bugs appear.

For teams evaluating broader technology choices, a Flutter vs React Native comparison is worth reviewing. For Wear OS specifically, native Kotlin remains the standard.

Phase 4: Testing

Smartwatch testing involves hardware variability that mobile testing does not. Screen shapes, processor speeds, and OS versions differ across the Wear OS device ecosystem.

Required test types for a wearable release:

Phase 5: Publishing

Submitting a Wear OS app follows the same procedure as a mobile app submission. Before you submit, verify that the app meets the Design for Wear OS guidelines and that at least one screenshot sized for a Wear OS device is included.

Submission checklist:

1. Select the correct application file in the All Applications page.
2. In Pricing and Distribution, locate the Wear OS by Google category.
3. Check the “Distribute your app on Wear OS by Google” checkbox.
4. Add Wear OS screenshots. These minimize rejection risk and improve store conversion.
5. Save and publish following the standard release flow.

After submission, three review states are possible in the Google Play Console: Pending (review in progress), Approved (will appear in the Wear OS category), and Rejected (details sent via email with the option to resubmit after changes).

If you already have a strong mobile app on Google Play and are adding Wear OS support, Google recommends including the Wear OS APK in the same listing as the phone app. Same package name, same description. Your existing users receive the update automatically, and ratings are preserved.

DashDevs in practice: FitGrid health and fitness app

One of the clearest examples of what mobile app development for health and fitness actually involves in practice is FitGrid, a retention software platform for fitness studios built by DashDevs.

Challenge. The client needed four separate Android and iOS applications built from scratch (apps for studio owners, instructors, and gym members) with shared data, analytics, real-time communication, and the ability to handle a large and growing concurrent user base.

Solution. We delivered all four apps in three months using React Native, Android, iOS, and Swift. The platform connects gym visitors, administrators, and instructors through a learning and recommendation grid that automates instructor-client communication and drives community engagement. Security standards, analytics integration, and a scalable architecture were built in from day one.

Results. FitGrid now serves 1,000+ locations across 48 US states and 15 countries. The client raised $1.5M off the strength of the product, reached 2,000+ daily active users within the first months after launch, and expanded into 30+ international markets.

FitGrid is a mobile product. But it illustrates the same core challenges that come up in any health and fitness wearable project: multi-platform coordination, real-time data sync, scalability under load, and building for an audience that expects reliability during a workout. The wearable layer adds watch-specific UI and DataLayer sync on top of that foundation.

You can explore more success stories from DashDevs across mobile, wearable, and fintech products.

What does development cost?

Cost depends on scope. A standalone dedicated app is simpler to estimate, and at the same time, a companion extension adds the interaction development layer and requires coordinating changes across both phone and watch codebases at the same time.

The key variables are app complexity, number of targeted Wear OS devices, custom sensor integrations, and whether you are building standalone or extending an existing mobile product. A smartwatch app development solution built on native Kotlin with a well-scoped DataLayer will cost less to maintain long-term than one patched together with cross-platform libraries that do not fully support Wear OS. For a detailed view of how development budgets break down, the how much it costs to build an app guide covers the main cost categories.

Teams planning a wearable investment should also have a monetization plan before committing to scope. The mobile app monetization guide covers the models that apply to wearable apps, including subscription, freemium, and in-app purchase approaches.

Working with development services

Not every team has in-house Android expertise. Fewer still have Wear OS-specific experience. The Wear OS ecosystem has its own complexity: DataLayer sync edge cases, health services API requirements, and Play Store submission for wearables. All of these add weeks to a project if a team is learning as it goes.

Experienced smartwatch app developers should be able to answer technical questions about DataLayer, screen-shape handling, and standalone versus companion app architecture without needing to escalate. If the conversation stays at a feature level rather than an implementation level, that is a signal worth noting before you sign anything.

Before engaging a vendor, a clear scope document saves time on both sides. How to write an RFP for app development covers what to include for mobile and wearable projects.

The wrist is a real product surface. Build it like one.

Smartwatch app development isn’t a niche experiment. With over 562 million users worldwide and Android-based systems, including Wear OS, growing at approximately 11.5% CAGR through 2033, wearables represent a real extension surface for health, fitness, finance, productivity, and communication products.

The development path is well-defined: Kotlin and Jetpack Compose for Wear OS, the DataLayer API for sync, and Google Play for distribution. The real complexity sits in the design and the interaction layer, particularly for companion extensions that need to handle sync edge cases gracefully.

DashDevs has built dedicated watch apps and companion extensions across health, media, and fintech. With over 15 years of mobile development experience and 500+ products shipped, the team handles the full stack: discovery, design, development, testing, and launch. If you have a wearable project in scope, contact us to discuss the right approach for your product.