Do I actually need a watch or TV version?

In two situations, yes. Fitness and health, because heart rate, movement and workout data come off the wrist and the phone simply cannot supply them. And media, because long-form video is watched on a television and being absent from that screen costs you the session. Outside those two it is usually a nice-to-have, and we would rather tell you that than take the money.

Can this be built cross-platform like the phone app?

No, and that is the main thing to understand before budgeting. Flutter does not officially support watchOS or tvOS. React Native has routes to television but nothing for watches. This work is native — Swift and SwiftUI for Apple, Kotlin and Compose for Wear OS and Android TV — which is why it is priced as its own project.

We already have the phone app. Isn't the watch version a small addition?

It is not. It has its own interface design, its own codebase, its own testing and, on the App Store, its own review. The phone app being finished saves you the backend and the product thinking. It does not save you the build. Treating it as a small addition is the most reliable way to turn a profitable project into a loss.

Do you test on real devices?

Yes, and on this platform there is no alternative. Watch and TV emulators are poor stand-ins — they cannot generate real sensor data, they do not reproduce how a remote actually behaves in someone's hand, and they tell you nothing about legibility at arm's length or across a room.

Which is harder, a watch app or a TV app?

They are hard in different ways. The watch is a design problem — one inch of screen, a couple of seconds of attention, so you get one piece of information and at most one action. The TV is a navigation problem — there is no finger, only a directional pad, so every screen has to be rebuilt around focus order and what happens when someone presses right.

Does data go both ways between the watch and the phone?

It can, and the direction changes the price. Sending information out to the watch to display is the simpler half. Collecting sensor data on the wrist, holding it while the watch is off the phone, and reconciling it later is meaningfully harder work and it should be identified in the scope rather than assumed.

Mobile & App Development

Watch and television companions to an app you already have

watchOS, Wear OS, Apple TV and Android TV builds designed for a glance or a remote control — treated as their own product rather than the phone app made smaller.

From: $5,000–$30,000
Typical time: 2–4 months
Usually bought by: Media, fitness

What this actually solves

Two markets buy this because they genuinely need it, and the rest mostly do not. In fitness and health, the wrist is the sensor. Heart rate, movement, sleep and workout data originate there, and no phone app can produce them — a fitness product without a watch companion is missing its primary input, not an optional extra. In media, the television is where long-form viewing actually happens. A video business that is absent from the living-room screen loses the sessions that last an hour, keeping only the ones that last four minutes.

Outside those two, the honest advice is usually to skip it. A watch companion for a shopping app or a booking tool tends to be built because it sounds modern, gets used for a week, and then quietly costs money to maintain across every OS release afterwards. If you ask us to build one and we think that is where it ends up, you will hear so before you spend anything.

The reason this is a separate project rather than an extension is that the design has to start again. A watch face is about an inch across and a person looks at it for a couple of seconds while doing something else, which means one piece of information and, at most, one action. A television has no pointer at all — it has a remote with a directional pad, so navigation is a question of focus order and what the highlight does when someone presses right, and every layout has to be legible from across a room. This is not the phone app scaled down. It is the same idea rethought for a different body position.

What we do, and in what order

Interrogate the use case. What is the one thing a person needs on their wrist, or the one session a viewer wants on the television, and does the existing product actually support it. This step sometimes ends the project, and that is a legitimate outcome. Two to four days.
Design for the device, not the phone. Screen-by-screen design done natively for the target — complications and glanceable states for a watch, focus order and remote-driven navigation for a television, with type sized for the actual viewing distance. Reviewed on hardware, not on a desktop monitor. One to two weeks.
Data and sync design. What crosses between the phone, the companion and the backend, in which direction, and what happens when the watch is out of range of the phone. Sensor data coming off the wrist is the harder direction and it is designed before it is built. Three to five days.
Native build. Swift and SwiftUI in Xcode for watchOS and tvOS, Kotlin and Compose for Wear OS and Android TV. Built against real hardware from the first working screen, because these are platforms where the emulator misleads more than it helps. Four to ten weeks depending on how many platforms are in scope.
Device testing. Physical watches and physical televisions with physical remotes. Legibility from a normal viewing distance, behaviour when the connection to the phone drops, battery impact on the watch, and what happens when someone mashes the directional pad. One to two weeks.
Store submission. Companion apps carry their own listing requirements, their own screenshot sizes for each device class and, on Apple, their own review pass. Budgeted as its own stage. One to two weeks.

What moves the price

The range is $5,000–$30,000 across 2–4 months, and because every target here is a native build, three things move it sharply.

How many platforms are in scope. Apple Watch, Wear OS, Apple TV and Android TV are four separate builds in two languages. Choosing one platform to start with is usually the right commercial decision and it moves the number substantially.

Whether the phone app already exists. With a working phone app and a live backend, this is a companion project. Without one, you are buying the underlying product as well, and the companion is the smaller half of that.

Which direction the data flows. Pushing information out to a device to display is the straightforward case. Collecting sensor readings on a watch, buffering them while it is disconnected, and reconciling them with the phone afterwards is considerably more work and it is the detail most often missing from a brief.

What usually goes wrong

It gets priced as a bit more work on the existing app. This is the mistake that turns a healthy project into a loss. A watch app has its own design, its own codebase, its own device testing and its own store review. Folding it into the phone app's price as an afterthought means absorbing a second project's worth of work for nothing.

The phone interface is shrunk onto the watch. Lists, tab bars and multi-field forms arrive on a one-inch screen and become unusable. A watch screen has to answer one question in about two seconds, with one action available if any. Anything more than that is a screen that gets opened once.

The TV app is built as though it had a touchscreen. Layouts that work on a tablet are pushed to the television and then nobody can drive them, because there is no finger — there is a directional pad, a focus highlight and a viewer two or three metres away. Focus order, visible focus state and type sized for distance are the actual work, and they have to be designed rather than inherited.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

Do I actually need a watch or TV version?: In two situations, yes. Fitness and health, because heart rate, movement and workout data come off the wrist and the phone simply cannot supply them. And media, because long-form video is watched on a television and being absent from that screen costs you the session. Outside those two it is usually a nice-to-have, and we would rather tell you that than take the money.
Can this be built cross-platform like the phone app?: No, and that is the main thing to understand before budgeting. Flutter does not officially support watchOS or tvOS. React Native has routes to television but nothing for watches. This work is native — Swift and SwiftUI for Apple, Kotlin and Compose for Wear OS and Android TV — which is why it is priced as its own project.
We already have the phone app. Isn't the watch version a small addition?: It is not. It has its own interface design, its own codebase, its own testing and, on the App Store, its own review. The phone app being finished saves you the backend and the product thinking. It does not save you the build. Treating it as a small addition is the most reliable way to turn a profitable project into a loss.
Do you test on real devices?: Yes, and on this platform there is no alternative. Watch and TV emulators are poor stand-ins — they cannot generate real sensor data, they do not reproduce how a remote actually behaves in someone's hand, and they tell you nothing about legibility at arm's length or across a room.
Which is harder, a watch app or a TV app?: They are hard in different ways. The watch is a design problem — one inch of screen, a couple of seconds of attention, so you get one piece of information and at most one action. The TV is a navigation problem — there is no finger, only a directional pad, so every screen has to be rebuilt around focus order and what happens when someone presses right.
Does data go both ways between the watch and the phone?: It can, and the direction changes the price. Sending information out to the watch to display is the simpler half. Collecting sensor data on the wrist, holding it while the watch is off the phone, and reconciling it later is meaningfully harder work and it should be identified in the scope rather than assumed.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Wearable / TV app All Mobile & App Development services