You have to give Wear OS devotees some credit: They’ve survived for almost a decade through Google’s start-and-stop investment pattern in the platform, with half-baked native apps and features being broken longer than anyone cares to admit. But if it was for the users, just think how much crap third-party developers had to suffer to serve them. Today, as Pixel Watch and Jetpack Compose for Wear OS look set to bring some relevance back to the operating system, we’re speaking to a developer who’s been with the platform since the beginning and find out what’s up after all in Wear OS development -Apps has changed years.
Greg Viczian, known to most as DYNA Logix, has been closely associated with what came to be known as Android Wear since its inception, creating watch faces and other applets, his most famous being the highly customizable Bubble Clouds launcher with two modes – one App that has racked up more than a million installs.
We have edited Viczian’s answers to our interview questions for readability.
The Android Wear age
The early years of Android Wear were exciting but incredibly frustrating for developers left to their own devices.
“The earliest versions of Android Wear (1.x) had a much more limited SDK, sparse documentation, and little information on developer forums,” Viczian said.
However, as a developer who wanted to start on the ground floor, Viczian had to lend a hand himself. Bubble Clouds offered users some of the most useful and customizable features a Wear app package could offer in the v1 years. Eventually, a community grew around Android Wear and he was able to leverage some homemade libraries to make further improvements. He also spent a lot of time addressing complaints from his audience of power users, particularly about battery and storage consumption. Both assets are very expensive in a tiny form factor, but they’re also in high demand considering what people use a watch for: checking the time.
But novelty and mass interest in the platform quickly waned, and when Google launched Android Wear 2.0 in 2017, there was some serious catching up to do.
“Google added watch-specific libraries for watch face complications, introduced billing and networking-related libraries, and we got material themes and design guidelines.”
But after a short time, the same aura of discomfort set in. When Google redesigned Android Wear into Wear OS in 2019 and introduced its Tiles user interface, developers immediately started building and circulating their own APIs, long before the company bothered to release an official one in 2021. Even with an official release, Viczian says Builder-based implementation was “awful”.
Change is a-happenin’
This year, it seemed like Google was turning the corner on wearables development. It convinced Samsung to let go of Tizen and help out with Wear OS 3.0 and pour arm fat into refreshing things for app and watch face makers.
It’s exciting to see renewed interest in Wear OS from Google: the updated APIs, policies and tools. I was also very excited about Samsung’s withdrawal to Wear OS.
The Android Studio experience has been greatly improved with the ability to pair a phone with an emulated Wear device, as well as debugging over Wi-Fi. Even the Tiles API has been rebuilt into a more acceptable form. The Health Services API is of particular interest to Viczian – he plans to use it to improve the energy efficiency of his inactivity reminder app, Stand-up Alert.
The developer is also thrilled that Jetpack Compose is tailored specifically for Wear OS. But he’s in no rush to convert his existing projects, especially considering how much legacy code runs on Bubble Clouds.
I started working on this app in 2014: Some of the core parts of the app are 7-8 years old! Back then there was no Kotlin, not even Material Design. A lot has changed since this project began, and making everything look functional and familiar for long-time users (some of my favorite members of the user community have been with us since the beginning) is becoming a challenge. Keep the app for the new Galaxy Watch- Crowd attractive, not to mention preparing them for the Pixel Watch.
Bubble Clouds came out when Android was still heavily tied into Java’s class inheritance model. It took a while for JetBrains’ Kotlin language and Google’s complementary Jetpack Compose toolkit to see full adoption – eventually it did when the company announced Kotlin as the preferred Android language in 2019. However, it has had to shift to a feature-centric mindset, and applying it to Bubble Clouds’ existing features requires a lot of effort. Add to that the need to find replacements for outdated APIs, and you can probably imagine a situation akin to a birthday cake lit with gag candles that can’t be blown out.
It always feels redundant to rewrite parts of an app due to API changes. Is not broken, why fix it? Over the years I’ve had to update how background services worked and how rotation input was handled. I’ve redesigned the UI a couple of times, and I have another UI redesign pending. Tile functionality still uses Stringmon’s unofficial API and conversion to official API is still ahead of me. I’m still using the legacy ComplicationData library, which at this point seems to be more reliable than the new, recommended API, but at some point I’ll have to switch.
What the future brings
Still, there are good reasons for Viczian’s wait-and-see attitude. He tested some Compose libraries for his Fat Finger Scribble Calculator app and found that they increased the size of his app bundle by more than 40% – far from ideal when the native storage on almost all Wear OS watches is limited 4GB hangs.
“What we gain by cutting development time,” Viczian told me, “could negatively impact app quality relative to primary development priorities.”
And that development may be wasted if OEM-level support fails. Viczian cited numerous issues developing with the Galaxy Watch4, including the loss of a number of complication-related features for third-party apps, as well as disabling the ability to hide persistent notifications – particularly important for Bubble Clouds, as it can show overlays to other apps and needs them hence a permanent notification. It even had to incorporate burn-in protection into its always-on watch face, as the Watch4 didn’t include such a feature.
But with Google’s renewed stance on Wear OS and a first-party device that’s almost guaranteed to get the attention and support it deserves, it looks like the platform might be poised to revive trust from its existing developer base, but in a number of new ones to be welcome in the fold. And with 8 years of Stack Overflow threads and GitHub example repos scattered across the web, there’s hope that it’s more fun and easier for the newbies to build apps than it was for the Viczian and the rest Wear veterans out there ever was.