Problems with WFS forcing API 34

What have you all found are the likely culprits for requiring API 34? I know weather is one of them.

I have an older watch face on API 33. I went in to modify one of the images and republish and WFS is forcing API 34. I didn’t add anything except a static image layer. I’m guessing there is a new setting that got activated when I opened the watch face in the new WFS. I went through again and looked at all the complications and images and their properties and I didn’t see anything that jumped out at me. Any ideas?

1 Like

I solved this particular issue. I had some complications that allowed a Range Value type. Apparently this now requires API 34. But Range Values were around on 30 and 33 right? Is there something we can do to still allow Range Values on 33?

1 Like

And now that I’ve removed the range value, it will only do min API 30, even though Google requires 33. This is getting very frustrating.

1 Like

I think this is a bit messed up at the moment (which may be defensible since the latest build is for beta-testing).

If you click on ‘Diagnosis’, there’s a strange message that ‘Range Value’ now covers GoalProgress and WeightedElement. I think the last two complication types were only introduced in Wear OS 5; by combining them with RANGED_VALUE (even if unimplemented!), Samsung may have condemned RANGED_VALUE to require Wear OS 5.

It would have been safer to treat the new complication types independently (as they are in WFF2).

A further wiggle is that RANGED_VALUE in WFF2 supports colour ramps, which the current beta WFS also claims to support (but doesn’t). Without colour ramps, RANGED_VALUE could drop back to WFF1. This may explain the API variations you’re seeing.

2 Likes

Thank you for that explanation!!

This beta version also suggests it will publish at API 30 even though it is 33.

2 Likes