Wear OS is based on Android, so many of the best practices for Android also apply to Wear OS. However, Wear OS is optimized for the wrist, so there are some differences between the two.
To optimize your development time, review the principles below before you start building your Wear OS app.
Note: New Wear OS quality requirements will come into effect August 31, 2023. For a full list of requirements, see Wear OS app quality.
Design for critical tasks
Focus on one or two needs of your target users rather than a full app experience. Don't migrate an entire mobile codebase and put a Wear OS user interface on top.
Instead, find critical tasks that work well on the wrist and streamline the experience on Wear OS.
Optimize for the wrist
Help people complete tasks on the watch within seconds to avoid ergonomic discomfort or arm fatigue.
Review the Wear OS design guidelines to learn more about optimizing for the wrist.
Respect the user's privacy
Your app must earn a user's trust before they give permission for your app to access potentially sensitive information about them. The system provides several ways to help users maintain their privacy.
Privacy dashboard
Starting in Wear OS 5, the system supports the privacy dashboard. This dashboard offers users a centralized view of each app's data usage, including the following details:
- The data types being accessed, such as location and microphone.
- How recently those data types were accessed.
With access to this information, users can make more informed decisions about which apps should still have access to their personal data. To maintain user trust, use data responsibly and be transparent when collecting and using user data.
Screenshot detection
On devices that run Wear OS 5 or higher, apps can use a privacy-preserving screenshot detection API.
Use the appropriate surface for the task
Wear OS has many more surfaces than mobile to engage users. Apps should tailor their content for those surfaces.
Each surface has its own use case. If more action is required, direct users into a fuller app experience.
Read and understand how your content scales across each surface according to the priority of user needs. Following is an example of priorities for a weather app.
|
|
|
|
|
| Complication
P1: What’s the weather right now? |
Notification
P1 Tell me about a severe weather advisory |
Tile
P1: What’s the weather right now? P2: What’s the weather today? |
App
P1: What’s the weather right now? P2: What’s the weather today? P3: What’s the hourly breakdown? P3: Preferences |
To learn more, read our User Interface Guide.
Add notifications to additional surfaces
In Wear OS API level 30 and higher, pair any ongoing notification to an
OngoingActivity to add that notification to additional surfaces within the Wear OS
user interface to increase engagement with long running activities.
Support offline scenarios
While a Wear OS device generally supports Bluetooth and Wi-Fi, it might not support LTE. Design for spotty connections and offline use cases, such as exercising and commuting, when a user may leave their mobile device at home.
Provide relevant content
The watch is almost always with the user. Keep your app content updated with the user's context, such as their time, place, and activity.
Aid users in completing a task from another device
People increasingly own multiple devices. The watch can aid people in completing a task across a distributed ecosystem of devices. Review use cases where this makes sense for your app.
Improve user experience during an app cold start
To improve user experience during an app cold start, create a splash activity with a separate
theme and set its windowBackground to your custom splash drawable in the manifest
file. The splash screen is made up of a layer-list with two elements, the background color and
the custom drawable that is typically your app icon. The drawable should be 48 x 48dp.
Considerations for media apps
Enable playback controls for music from the phone
If your app is installed on both the phone and watch, users expect to have remote controls from their watch. For example, users expect the ability to pause, play, or skip songs from their watch.
Downloaded content
As called out earlier, it is important to support offline scenarios. This is especially important for media apps. For media apps, it is easier to support offline downloads first, then to add streaming ability if you see the demand.
When designing, make it clear to the user what content is available offline. For any long-running immediate or periodic tasks, use WorkManager. Defer downloads until the watch is charging and connected to Wi-Fi.
Streaming on LTE
Consider offering streaming support on devices that have LTE connectivity, a common use case for media playback. Streaming allows users to leave their other devices at home and still listen to music. Make sure to visually communicate to the user when they are streaming music and cache streamed audio. Avoid using LTE for any jobs that could be deferred, such as sending logging and analytics data, to optimize power usage while streaming.
Support Bluetooth headphones
Users may take only their watch and headphones out for a run or walk. Enable them to have a true standalone experience by supporting pairing with headphones. If headphones are not connected when playing or resuming music, launch Bluetooth settings to allow the user to connect to their Bluetooth headphones directly from the app.
Indicate music source
Clearly indicate whether the sound is coming from the watch or the phone. Use a source icon to indicate where the music is playing. The default source should be where the user starts the music.
Using the speaker
Some Wear OS devices include a built-in speaker which can be used for things like reminders and alarms. Avoid using the built-in speaker for playing media and music, as users expect these experiences to be tied to using headphones. For more information, see Detecting audio devices.
Considerations for fitness apps
When creating fitness apps for Android 10 and higher, request the Physical activity recognition permission.
Complement the mobile app
As outlined above, a Wear OS fitness app should handle only critical tasks for the wrist. This means a fitness Wear OS app will mostly focus on data gathering.
While you can allow some post-workout summary screens, leave detailed post-workout analysis, and any other features that require more screenspace to the mobile app.
Support long-lived activities
Like many apps that subscribe to location and sensor data, design your app to handle running while-in-use. This means your app should function in the foreground.
If the workout starts in an activity, bind that activity to a service that will do the work. When the user navigates away from your app, the service will unbind and can promote itself to an ongoing notification.
In Wear OS, you can expose your Ongoing Notifications to new surfaces with the Ongoing Activity API using a minimal amount of code.
Review the Ongoing Activity code lab on GitHub to see a simplified app with this architecture.
Use always-on sparingly
If a user stops using their watch during a session with your app, the device will eventually go into system ambient mode to save battery.
Wear OS will bring that app back to an active state if the user interacts with the device again within a specified amount of time.
For most use cases, this should be enough for user to have a good experience and save battery life.
In some cases, you may need your app to be visible for longer, such as during an entire
workout. For those cases, you will need to use
AmbientLifecycleObserver.
For more information, see
Keep your app visible on Wear.
Don't hold a wake lock
Use APIs such as Health Services to obtain sensor data, while allowing the CPU to sleep between readings or delivery.
Optimize location and sensor management
Sensor management is very important and can impact battery life negatively if not done properly.
Make sure you follow these recommendations when implementing your sensor strategy:
- Always use sensors in batch mode where possible.
- Flush sensors when the screen/app becomes active again.
- Change the length of batching when the screen goes off to conserve power.
- Unregister sensor listeners when they are no longer needed.
- For location sensors, follow the best practices recorded at Detect location on Wear OS.
Use haptics to confirm actions
Use haptic feedback to confirm actions, such as start, stop, auto-pause, or auto-lap.
Use touch lock
In some cases, disabling the touch experience improves the app experience. For example, it makes sense to disable touch when tracking a workout, because accidental touch is very likely in this case.
Considerations for messaging apps
Start with notifications
Support
MessagingStyle
to improve your user's app experience.
Support voice input
Make sure to support speech-to-text, as it's much faster on a watch. You may also want to support recorded audio as well.