A smartwatch companion app is usually a phone app that knows when to be brief.
Start with the fact that changes the plan. React Native builds for phones, not for watches, so a smartwatch companion app made that way is an iPhone or Android app whose output happens to land on a wrist. That is less limiting than it sounds. Most of what people want on a watch arrives from the phone with no watch code at all, and the rest is a second native app. The same boundary runs through Wear OS app development and through the Apple side of it.
This page covers what reaches the wrist for free, what forces a native watch target written in Swift or Kotlin, what the watch already recorded that a phone app can read, and how to tell which of the three your feature list is asking for.
Sort your feature listThe short version
The watch is an output device long before it is an app.
Whether you call it an Apple Watch companion app or a Wear OS companion app, the first question is the same. Almost everything people mean by a watch app is a notification with the right words in it at the right moment. Both platforms deliver those from your phone app with no watch code, which is why the cheapest useful version of this project has no watch target in it at all.
The expensive version starts when you want a screen the wearer opens, a number kept on the watch face, or a sensor reading the phone cannot take. Those are written against Apple's or Google's watch SDKs and maintained beside your React Native app, not inside it.
What a React Native build can and cannot put on a watch
Say the hard part first. React Native builds for Android and iOS. Its documentation keeps a page for the other platforms it has been ported to, maintained by partners and by the community: macOS, Windows, visionOS, OpenHarmony, tvOS, the web. Neither watchOS nor Wear OS is on that list. There is no flag, no config option and no setting that turns a React Native project into a watch app.
Expo does not change this. Its own introduction describes it as a React Native framework for developing Android and iOS apps. So a project produced by any AI app builder that outputs React Native and Expo is a phone app, every time, and the watch question has to be answered somewhere else.
The useful framing is that the watch is a second device with its own SDK. A watchOS app is Swift or SwiftUI compiled against Apple's watch SDK and added as a target in Xcode. A Wear OS app is an Android app built against Google's Wear libraries, with its own screens and its own build. Your JavaScript does not run in either of them. Anyone who tells you otherwise is describing notifications and calling it an app.
The wrist is already reachable from the phone
Here is the part that saves the project. The thing most teams actually want on a watch is an alert that arrives at the right moment with the right sentence in it. Both platforms do that from your phone app, and neither asks you for watch code to get it.
On iOS the routing is documented and short. If the iPhone is unlocked with its screen on, the notification goes to the phone. Otherwise, if the paired Apple Watch is on the wrist and unlocked, it goes to the watch. Otherwise it falls back to the phone. Your app does not choose and cannot choose. The system decides, and it needs nothing from you beyond a notification worth showing.
Google's default has the same shape. The system bridges, or shares, notifications from a phone app to any paired watch. Google documents the controls for this mainly so that teams who do ship a watch app can stop the wearer seeing everything twice, which tells you which way the default runs.
That is enough for a real product. A medication tracking app whose whole job is a prompt at eight in the morning gains nothing from a watch screen. It gains from the prompt being on the wrist, which it already is. What is left is getting the notification sent, permitted and timed at all, and what reaches the wrist depends far more on that than on the watch.
Apple Developer, Taking advantage of notification forwarding
Three kinds of watch feature, and only one is free
Requests in this area fall into three buckets, and separating them early saves weeks. The first is delivery: an alert, a reminder, a button on that alert that the wearer taps without reaching for the phone. That is your phone app doing its normal work, and the wrist comes with it.
The second is a surface the wearer opens on purpose: an app screen on the watch, a tile, a complication showing one number on the face. Each of those is native code on the watch, maintained separately from your React Native app. A complication is also not the same piece of work as the app, so two of them on the list is two jobs, not one.
The third is sensing: a heart rate while the phone is in a bag, a wrist gesture, a workout the wearer starts from the watch. That needs a native watch app plus a channel back to the phone, and it is the most expensive of the three by a distance. This is where a fitness app builder stops helping, because the sensor sits on a device it does not build for.
Try it
Sort your watch feature list
Tick what you want on the wrist. The first two come with a phone build. The rest are a second app, in another language, that you keep alive.
No watch code needed
- Your phone app already does this. Both platforms pass the alert to a paired watch.
Reading what the watch already measured
There is a middle road that people miss. You may not need live access to the watch at all. You may need yesterday's numbers, and those are usually already on the phone by the time anyone opens your app.
On iPhone the store is HealthKit, a shared repository for health and fitness data across iPhone and Apple Watch. An app reads from it only with the user's permission, granted per data type, and the user can inspect or revoke that in the Health app whenever they like. From React Native you reach it through a native module, so it is a dependency decision rather than a line of JavaScript.
On Android the equivalent is Health Connect, built into recent Android versions, with permissions also granted per data type. Whether a given watch writes into it depends on that watch's own software rather than on anything in your code, so check it for the model you care about before you design around it. That is the difference between a feature and an assumption.
Either way you are reading what was recorded, not watching a live feed. If the product genuinely needs the number this second while the phone is in a pocket, the middle road runs out and you are back to a native watch app.
What each route puts on the wrist
| Route | Alerts on the wrist | A screen the wearer opens | Number on the watch face | What you maintain |
|---|---|---|---|---|
| React Native phone app, no watch code | Yes | No | No | one app |
| Phone app with notification actions | Yes | the alert only | No | one app |
| Plus a watchOS target in Xcode | Yes | Yes | Yes | a Swift app as well |
| Plus a Wear OS module | Yes | Yes | Yes | a Kotlin app as well |
| Both watches covered | Yes | Yes | Yes | two native apps as well |
Building the phone half well
Nearly all the value here sits in the phone app, and most of it is judgement rather than code. What is worth interrupting someone for. What can wait until the evening. What the alert says in the dozen words a watch will show before it truncates. Teams that get this right rarely need a watch app. Teams that get it wrong ship one and still annoy people.
Newly is an AI app builder. You describe the app in plain English, it writes a real React Native and Expo project you own, runs it on a cloud iPhone or Android simulator while it builds, and ships it to TestFlight and to Google Play internal testing. It also builds a standalone production APK. iOS distribution goes through App Store Connect on your own Apple Developer account. It is $25 a month and there is no free plan. It builds the phone app, which is the part that reaches the wrist. It does not produce a watchOS or Wear OS target, and nothing on this page pretends otherwise.
If you later need one, the code is yours to take: install the CLI with npm i -g @newly/cli, run newly pull with your project id, then open the result in Xcode or Android Studio and add the native watch target by hand. The pull runs one way, and you can also connect a GitHub repository you own from the Deploy tab and keep the two in step, so decide where the project is going to live before you split it across two toolchains.
Questions people ask about watch companion apps
No. React Native targets Android and iOS, and watchOS appears neither in the core platforms nor in the list of ported ones maintained by partners and the community. A watch app is a separate target in Xcode, written in Swift or SwiftUI. You can ship both, but the watch half is native code you write and maintain yourself.
Describe the app that has to reach the wrist
Write down the moment that matters, what the alert says, and who it interrupts. Build the phone app around that first, and revisit a watch target only when someone tells you the notification was not enough.
Start building