Creating Wear OS apps with Flutter (1/4): Introduction
I recently published my first Wear OS app, but I found resources around developing smartwatch apps, particularly for Wear OS (Android) to be quite lacking. This series of blog posts will share how you can create full-fledged Wear OS apps using Flutter, that are production-ready and published to Play Store for end-users; I hope it can help others bring their own ideas to life as smartwatch apps, and get an idea of the process involved perhaps even before starting!
- Introduction to Wear OS, its design guidelines, and other considerations
- Setting up a Flutter Wear OS app and running it on an emulator/device
- Using Platform Channels to replace common Flutter packages which aren't yet compatible with Wear OS
- Creating a Splash Screen for your Wear OS app in Flutter
- Getting approved and published on the Play Store
Before we start, I do want to call out that whilst Flutter is best known and most useful for creating cross-platform apps, this series assumes we are creating a simple standalone Wear OS app only.
You might question what is the point of creating just a Wear OS app in Flutter, but if Flutter is something you're already comfortable with for Android/iOS/Web apps, it's likely much faster to continue to use Flutter. You can also re-used any brand components and styles with ease, as opposed to migrating to e.g., Kotlin entirely.
Introduction
To start with, here are a few core concepts that are useful to understand before developing a Wear OS app. Some of these might decide the direction in which you decide to go!
Standalone vs non-standalone Wear OS apps
A 'standalone' app is one that can run independently of a connected phone.
This was a little confusing at first, because the majority of Wear OS smartwatches don't have cellular capabilities, so does that mean they are 'dependent' on a connected phone? No – 'dependent' in this context means that all the app's functionality must be able to be completed entirely on the watch without the user interacting with their phone.
For example, if you require users to set up the watch app, or configure settings, through their phone via a companion app, then it is a non-standalone app. Conversely, if you have a settings page within the watch, and the user doesn't need to touch their phone, then you have a standalone app.
Crucially, either type of app will still be able to use the connected phone for Internet access – so if your standalone app uses e.g., an online API to surface data to a user, this is fine! And if you're using a watch with cellular capability, then it won't even need to be connected to the phone.
In this blog series, we focus on creating a standalone app.
Internet capabilities
Smartwatches prioritise using Bluetooth Low Energy (BLE) for communication (if you're interested in how BLE works and implementing your own BLE services on e.g., Raspberry Pis, check out my other blog series).
This is because BLE is much less power-hungry than Wi-Fi and Cellular data. This also means that even if your standalone watch app is accessing the Internet, the requests may still be going to and from your phone via Bluetooth (where the phone then connects to the Internet via Wi-Fi/mobile data).
This is something to bear in mind because your watch app might end up having a relatively small bandwidth of ~4KB/s. This can introduce latency, memory, or battery usage.
Ideally, Wear OS apps should be snappy and quick to use, so this can be an important factor if you are trying to do data-intensive things, or even load pictures/icons from the Internet!
Battery
One of the biggest pain points of modern smartwatches is their battery life. The majority are still at ~1 day battery life (save some, like the OnePlus Watch 2 and 3, which I'd highly recommend!).
This means we need to be wary about the resources we use in our app, for example by reducing animation and memory-intensive processes.
The official docs outline many areas to look out for when considering battery usage.
Design
Smartwatch screens are very small, so need to be designed with that in mind. The UI and UX considerations are vastly different to a typical mobile app, such as:
- Buttons should have quite a large tap surface
- Text should be relatively large and glanceable
- Loading times should be minimal (nobody wants to stare at their wrist just waiting for something!)
Another challenge I faced was figuring out exactly how to portray the information I wanted to in such a small screen. Taking into account different screen sizes, and even different font sizes, means that you also need to adapt the information density for different users. That might mean showing one less piece of information, or prioritising functional UI elements over aesthetic ones.
In the next part, we'll set up a sample Flutter project and get it running on a Wear OS device!