Am I reading <this> correctly that watch faces tha...
# compose-wear
b
Am I reading this correctly that watch faces that want to run/render their own UI are deprecated?
kodee angry 1
e
b
Didn't see that, but just reading this now, it's wasn't very clear that only XML watch faces would be supported.
to be honest this comes as a bit of a shock to me
k
Yes that’s correct.. There were gradual restrictions already in place for new devices and newly uploaded watch faces. Starting from January ’26 all watch faces must use Watch Face Format. On bright side, there are a few new features that we just announced at I/O that provide more functionality to developers: https://android-developers.googleblog.com/2025/05/whats-new-in-watch-faces.html cc @Garan Jenkin
b
Yeah... Honestly I am extremely surprised and unhappy about this. This is obviously a huge limitation of what watchfaces can do. Not trying to troll but this makes me want to toss my Android get an Apple Watch... Can I at least hope that this is a store only limitation and as a developer I'll still be able to install my own WF?
k
I don’t have answer out of my head right now, I’ll need to take a look. Do you mind sharing legacy watch faces that you want to install? Also wondering if you mainly concerned for distribution restrictions or your main case is using own WF for self use?
b
I'm the author of a fairly simple WF which could probably be ported to the new format. But it currently behaves exactly as I want it to, so I have no interest in trying to re implement it with no insurance that the result would be exactly the same - not to mention the time and effort that this would take. But I'm also thinking of the many developers who spent a lot of time on their WF to do amazing things. All their work is wasted now? Lastly, I'm just bummed out on the principle itself that we will only see simple, limited WF from now on. That makes my watch worse than it was before.
y
Yep, you are not the only developer deeply frustrated by this. But it's hugely inefficient for battery if the watchface needs to run code for every single frame. And the watchface gets access to your complication data as well. So this pivot had to happen to build rich interesting watchfaces with long battery life.
b
I understand a WF that does all kind of render computation at 30fps will consume more battery... but most of the time the watch is in ambiant mode and will be updated at most once a minute, right? I don't know... I know battery life is a huge concern, but I'm having a hard time believing this measure will be a huge difference - so this sounds like a bad tradeoff. But even so, could a warning for non-xml WF (something like "this watchface may consume more battery") be enough? Or an advanced setting at the very least. Let users decide. Another concern: I assume Google and other vendors won't have this restriction - so now this is an unfair advantage.
y
Yep, OEMs can build their own custom watch faces and implement offloaded features however they want. They don't have the same restriction for pre installed watchfaces.
😭 1
b
Do you know if
adb install
a non-xml WF should still work in the future?
y
I'm not sure what's intended for future versions, but I wouldn't feel comfortable promising it even if I did.
1
b
All right, well, what a terrible day to be a WearOS developer. That being said, thank you both, appreciate your help 🙏
g
+1 to not relying on
adb install
for the future
😢 1
l
The word "migration" has been misused all along, including in that blog post. I don't like that that blog post makes it seem like it's possible to do so and is only a little work, while in reality, it is : Backwards compatibility -> gone Your user base -> not our problem Smooth 30-60fps animations on interactions -> 15 fps, good luck with your users User settings with custom UI -> gone In app purchases -> maybe one day Creativity -> yes, but start from scratch with another tech having much fewer capabilities I don't understand what Google is getting from completely barring third party devs from those, while OEMs can still do it, and warning users about the increased battery consumption is 100% possible. It's only going to get fewer devs trusting Wear OS as a platform worth investing into, since Google is happy to sweep your work away while claiming yet to be proven gains that don't even apply to all hardware your app can run on.
sad panda 1
I probably should write a few blog posts about that situation, since discussing the issue with Google led to no substantial consideration.
🙏 1
1