Develop experiences for kids on Wear OS

Review the following guidelines to optimize your Wear OS app's experience for kids. Also, confirm that your app or game satisfies requirements for kid-friendly experiences.

Review Wear OS principles

Review the following resources for creating new Wear OS apps:

Don't port the phone app

Don't port your mobile app onto Wear OS. Wear OS devices have much smaller batteries and components than mobile devices, which makes directly-ported mobile games very difficult to play.

Learn more about how to design experiences for kids on Wear OS.

Choose a development environment

To develop kid-friendly experiences, you can use Compose for Wear OS, our recommended approach for building UIs on Wear OS, as well as Unity for Android.

If you're more familiar with Unity's workflows and capabilities, or if your game is more complex and has 3D graphics and physics, we recommend using Unity to develop your game. It also comes with a variety of performance optimization features. Some Wear OS quality requirements may require custom implementations in Unity, such as support for rotary input.

For games with only a few simple and short animations, the Compose Animation API should be sufficient and is better supported within the Android environment.

Minimize impact on device battery

Minimize events that affect battery life over the course of one session. Kids use watches that provide important safety features for their parents or guardians, which depend on the device having enough battery life.

The following list includes some best practices for reducing battery impact. You can also learn more about how to conserve power and battery.

Design for offline use cases so that kids can play without incurring network-related battery costs.
Minimize tasks that require an internet or GPS connection.
Limit active gameplay time per day.
Use power efficient APIs for all day activity tracking as well as tracking exercises.
Reduce manual creation of wakelocks and use WorkManager.

The following list includes elements that you shouldn't include in your experience:

Don't use direct sensor tracking as this significantly reduces the battery life.
Don't include long-running animations.
Don't encourage the user to keep the screen on longer than necessary.

Prepare for standalone experiences

When developing standalone experiences, consider the following:

Design for offline use cases so that kids can always play.
Test how your app behaves on an emulator that doesn't have an active connection to a mobile device.

Use Watch Face Format to create watch faces

A watch face that's designed for kids must be created using Watch Face Format. Be mindful of how color saturation affects battery performance.

Learn more about how you can either design a watch face using Watch Face Studio or manually configure the Watch Face Format, and check out our watch face validation tools.

Hide open-on-phone actions

Starting in Wear OS 5, the RemoteActivityHelper API includes support for detecting whether a Wear OS device is in standalone mode. If a device is in standalone mode, hide any Open on phone interactions that your app or game might otherwise show.

For use cases where an app needs to be able to open a public URL on the phone to display Terms of Service, legal notices, a privacy policy, or something similar, display a short-link or QR Code using the Dialog component. If you provide a QR Code, parents and guardians can scan it using a mobile device.

Check standalone mode status before sending cross-device authorization requests

If your app makes OAuth authorization requests to other devices, first check whether the device is in standalone mode. To do so, call getAvailabilityStatus() from a RemoteAuthClient object:

If the return value is STATUS_UNAVAILABLE, the device is in standalone mode, and you should wait to send any OAuth authorization requests to mobile devices.
If the return value is STATUS_TEMPORARILY_UNAVAILABLE, wait for the value to change to STATUS_AVAILABLE before sending authorization requests.