--- title: "Wear OS Tiles for a Fitness App (2026)" canonical: "https://aifitnessapi.com/watch-apps/wear-os-tiles" cluster: "Watch Apps" primary_query: "wear os tile fitness app" last_reviewed: "2026-08-22" description: "Tiles are the swipe-from-watch-face carousel: protolayout instead of Compose, no scrolling, no fetching in the tile service. What a fitness tile needs." publisher: "AIFitnessAPI — independent, not sponsored" cite_as: "\"Wear OS Tiles for a Fitness App (2026)\", AIFitnessAPI, https://aifitnessapi.com/watch-apps/wear-os-tiles" --- # Wear OS Tiles for a Fitness App (2026) > A Wear OS tile is a glanceable surface in a carousel that Google describes as revealed by a swipe on the watch face, with additional swipes switching between tiles. Google frames the purpose as showing a small amount of key information that users can read through after they glance at a tile for a few seconds. Tiles are built declaratively with Jetpack's protolayout and tiles libraries rather than with Compose or Views, and because they render in a separate, remote environment they need different approaches to load, display and update data. Two constraints drive the design: tiles themselves cannot be scrolled, and Google's guidance is not to fetch content frequently or start long-running asynchronous work in the tile service — schedule with WorkManager and cache locally instead. For a fitness app, our judgement is that a tile should start the workout the user actually does and show one figure for today's progress, with everything else a tap away. - Canonical: https://aifitnessapi.com/watch-apps/wear-os-tiles - Last reviewed: 2026-08-22 - Publisher: AIFitnessAPI (https://aifitnessapi.com) — independent, not sponsored - Cite as: "Wear OS Tiles for a Fitness App (2026)", AIFitnessAPI, https://aifitnessapi.com/watch-apps/wear-os-tiles --- A tile is the surface a user reaches without opening your app. Google's documentation describes the mechanism plainly: "The tiles carousel is revealed by a swipe on the watch face, and additional swipes will switch between tiles." No launcher, no app list — one gesture from the watch face. What it is for is stated just as plainly: "Wear OS provides tiles as a way for you to show a small amount of key information, which users can read through after they glance at a tile for a few seconds." A few seconds is the entire design budget. Everything below follows from it. ## Tiles are built differently from the rest of your app This trips up teams who assume a tile is a small screen. Google's documentation states that tiles are built declaratively with "Jetpack's protolayout and tiles libraries" rather than with Compose or Views. Your app's UI toolkit does not come along. There is a second, deeper consequence: "Because Tiles are rendered in a separate, remote environment, they require different approaches to load, display, and update data within them." The tile is not running inside your app's process with your app's state in memory. You are producing a layout that something else renders, later, on its own schedule. Any assumption that a tile can read a value your activity happened to compute is wrong. ## Tiles cannot be scrolled Google's documentation says it in four words: "Tiles themselves cannot be scrolled." This is the constraint that decides your layout, and it is not a soft guideline you can design around with a clever gesture. Whatever the tile shows has to fit. The paired guidance is the escape route: "Don't overcrowd tiles with too much content. Instead, allow users to tap on tiles to learn more and take action on another surface in your app." So the shape of a good tile is one screen of content plus a tap target that leads somewhere with room. A tile that tries to be a dashboard becomes a tile that shows six truncated things. ## Do not do work in the tile service Google's guidance on data is explicit: "Don't fetch content frequently or start long-running asynchronous work in your tile service." The documented approach is to schedule work with WorkManager and cache locally, then have the tile render whatever is in the cache. Inverted into an implementation rule: the tile service is a rendering function over already-available state. It reads, it lays out, it returns. Anything that could block, fail, or take a network round trip happens elsewhere on a schedule you control, and writes to local storage the tile can read. That also settles what a stale tile should do. If the cache is old, render it as old — show the value with its timestamp — rather than blocking the render on a fetch or showing a spinner. A slightly stale number the user can read in two seconds beats a fresh number that arrives after they have swiped away. The same discipline applies to what the tile is caching. Note that the phone link is not a safe place to source it from: the Data Layer does not work when a Wear OS watch is paired to an iOS device, which is covered in [Wear OS phone sync](/watch-apps/wear-os-phone-sync). ## What a fitness tile should carry Everything from here is our judgement rather than Google's documentation, and it comes from the "few seconds" framing above. **Start the workout the user actually does.** Not a menu of workout types. If your app knows this person runs on Tuesdays and lifts on Thursdays, the tile's primary action should be the one workout they are most likely to want, with the full picker one tap away inside the app. A tile whose main affordance is "browse" has spent its budget on navigation. **Show today's state, once.** A single ring, streak, or goal figure that answers "am I on track" without arithmetic. One number the user can read at a glance is worth more than four numbers they have to parse — and, given that tiles cannot be scrolled, the fourth number is probably clipped anyway. **Make the tap target obvious and singular.** Because the deeper content lives in your app, the tile's job is to be a launcher with context. Ambiguity about what a tap does is expensive on a surface people use while moving. **Do not put anything on it that must be current to be safe.** The tile renders from cache by design. Nothing on it should be a number a user would act on medically. ## Tiles among the other glanceable surfaces Wear OS gives your app several places to appear, and they are not interchangeable: - **Tiles** — the swipe-from-watch-face carousel, described here. User-curated: the user chooses which tiles they keep and in what order. - **Complications on the watch face** — a different surface with a different update model, covered on the engagement side in [widgets and complications](/engagement/widgets-and-complications). - **Ongoing Activity** — for when a workout is actually running and the app needs to stay reachable, owned by [Wear OS Ongoing Activity](/engagement/wear-os-ongoing-activity). A tile is not a substitute for it, and an active workout should not be represented only by a tile. Our judgement on picking between them: a tile is for the decision to start, a complication is for a number you want visible without any gesture at all, and an ongoing activity is for the session in progress. Most fitness apps want a tile before they want anything else, because the moment you are competing for is the one where someone raises their wrist and decides whether today is a training day. ## Building it The tile renders from cached state, so your ordering is: get the data locally first, then write the layout. The exercise data that populates a fitness tile comes from the same place the app's live tracking does — see [Wear OS exercise tracking](/watch-apps/wear-os-exercise-tracking) — with the ambient, low-frequency path being the one that feeds a surface like this between workouts. ## FAQ ### Can I build a Wear OS tile with Jetpack Compose, and can users scroll it? No to both. Google's documentation states that tiles are built declaratively using Jetpack's protolayout and tiles libraries rather than with Compose or Views, so your app's UI toolkit does not carry over to this surface. It also states plainly that tiles themselves cannot be scrolled. Together those two facts mean a tile is a fixed, self-contained layout that has to fit what it shows. Google's guidance for content that does not fit is to avoid overcrowding and instead let users tap on tiles to learn more and take action on another surface in your app. [Permalink](https://aifitnessapi.com/watch-apps/wear-os-tiles#faq-1) ### Where should a Wear OS tile get its data, given that it renders in a separate process? From local storage that something else keeps up to date. Google's documentation states that tiles render in a separate, remote environment and therefore require different approaches to load, display and update data, and its guidance is not to fetch content frequently or start long-running asynchronous work in your tile service — use WorkManager and cache locally instead. Treat the tile service as a rendering function over state that already exists. If the cache is stale, our judgement is to render it as stale, with a timestamp, rather than blocking the render on a fetch the user will not wait for. [Permalink](https://aifitnessapi.com/watch-apps/wear-os-tiles#faq-2) ### Should a fitness tile show a workout summary or a start button? Our judgement is a start button for the specific workout this person actually does, plus one figure for today. Google's framing is that a tile shows a small amount of key information a user reads after glancing for a few seconds, and that content should not be overcrowded because users can tap through to another surface. A menu of workout types spends that budget on navigation, and a multi-metric summary spends it on numbers nobody parses in two seconds. Put the picker and the detail inside the app, and let the tile be the fastest possible route into the session. [Permalink](https://aifitnessapi.com/watch-apps/wear-os-tiles#faq-3)