This is getting comical but I had a feeling this would come up. For a couple of months I have been getting rejections on new faces and updated (already in production) faces with the simple, completely uninformative reason that…
This particular app was being updated to satisfy the new API/SDK requirements. Happy days, I got the email telling me I resolved the issue but was subsequently let down by this rejection (again) on an app that has been in production since May with no issues.
The only way I have managed to get around this so far is doing stupid pointless stuff like moving things out of groups/folders and other tiny little changes, re-upping new version and hoping for the best. But you tell me, is that any way to function here?
I have tried in vain to determine what the problem is by posting here and appealing in Google but nothing. I have not received any other correspondence from my paying customers or testers about not being able to load the app or crashing issues.
I have ZERO confidence in getting anything passed because of this issue and it totally sux.
I do not use companion app, all my apps are done is WFS 1.6.10 with elements (tiny mostly white .png’s) made in illustrator/Photoshop
Anyway, that’s my rant, it’s good to talk about it and get it off my chest and I truly hope none of you have to deal with this ever.
If you want to poke around, here is the file I just upped to Google Play - see for yourself and tell me if you see anything that might cause this rejection.
NRW.wfs.ZIP (1.4 MB)
1 Like
Hey, I took a look at the file you shared and I was wondering, is there any chance the complication at the top of the design could be crashing or at least “not working as described” on certain watches? So far I haven’t used any complications because I don’t yet fully understand them or how to configure them properly. But, that’s the only thing I see that makes me wonder about a compatibility/crashing issue because I’ve read some things here that indicate not all complications work with all devices.
Very cool design by the way! I love the 80’s retro theme. You did an awesome job with that in my opinion. 
1 Like
Hey thanks,
even if it does or doesn’t work on a certain device I wouldn’t know because Google provide absolutely nothing so what am I supposed to do? Also, if there was issues with complications not running on certain devices, I feel like I would not be the only one posting about issues here. This forum would be full of posts about complications having issues on certain devices and subsequent rejections. Maybe I am just unlucky and whoever is testing my face is using some antiquated old POS smart watch? who knows?? They certainly aren’t going to tell me.
One thing I do know is I keep my work organized and small, and I think I know how to navigate Google Play Console well enough to get apps published. At least I did before these past 2 months or so that I have been having the same re-occuring rejections on various different apps.
could it be my hardware? I think not…2023 MacBook Pro, software? nope…I am running the latest version of WFS. Am I using some crazy outside the box coding?? That would be a no again…
so yeah wtf?
Seriously though, thanks for the reply as I have posted about this issue more than once and it’s like a got the Black Plague or something here.
1 Like
This is a major long-shot (ha ha), but perhaps it’s because the complication doesn’t seem to display the Long Text field. As I read the rules, that’s the only field that’s actually compulsory for LONG_TEXT complications.
I have at least two watch faces with the same exact rejection reason. I can tell you right from the bat that it’s not complications (both of the watch faces have none) and not your hardware setup (I’m running Windows). Also, no Google employees are testing your watchfaces manually, it’s all part of the automatic testing pipeline that runs watch faces in emulated environments for different supported devices.
oh wow ok…maybe if I only want to display temp and icon, I should just use a short-text complication? I had no idea that there were compulsory things that had to be displayed in complications. In WFS you can just turn off what you don’t want to display. I’ll see what happens with the next “in review”. If it gets rejected again I’ll try that.
Yay! more darts to throw at the wall.
Thank you!
1 Like
So are you still at a loss as to the cause of your rejections? Have you managed to get them passed like I have by just making small changes and re-upping? Also, I am not going to even pretend I know how apps get reviewed but thanks for letting me know that it’s not some dude with a terrible, old device trying to load my app. 
1 Like
If it is in fact the long text complication and the compulsory use of the long text field,…couldnt I just display it and make the opacity 0? it would then be displayed but no one could see it. yeah?
1 Like
I still have those watch faces as “rejected”. Didn’t have enough time to investigate as I was kept busy with the infamous target SDK version policy violations.
Only Google knows. I’m not sure they’d be so easily fooled.
If you really don’t want to display the only compulsory field, are you sure that you’re using the most appropriate type of complication?
When you design editable complications, bear in mind that the user should be able to use them to view ANY complication (including third-party ones) that serve one or more of the specified complication types. Such complications would be perfectly valid if they only provided LONG_TEXT — but your clockface would display nothing. That’s not a good user experience. One way to avoid this would be to make your complication uneditable and lock it to a specific complication provider package (such as the weather complication you’ve got in mind). That seems a bit poor, though.
1 Like
Weather is not an option on an uneditable complication right? I know what you’re saying about being able to use any complication type globally and that would be best. I guess I just don’t know enough about them at this point but I see a lot of faces with not only weather seemingly baked in but custom weather icons too. I imagine this is done with a component app and some super android developer skills? With my faces I have pretty explicit written and illustrated instructions on the preferred set up with the Largebox complication. For now, I have gotten other faces passed using the same Largebox complication/weather set up but we’ll see if this pass when I update them.
1 Like
Thanks anyway, well it would be great if you got it figured out and shared the solution. 
1 Like
Are you sure you really need a complication? If you only want to display weather and are happy with the system-provided service, you could just use tags.
Sorry I am not up on the lingo, I am trying but I am still a rookie here. What system-provided service? There are tags for weather in WFS 1.6.10? Are you meaning just an app launcher?
1 Like
“system-provided service”: Wear OS can sometimes provide weather values directly to the watchface so it isn’t always necessary to use complications.
I don’t know when weather tags were introduced in WFS. I know they’ve been in WFF since version 2, but that version may only be available on Wear OS 5.
2 Likes
That is absolutly correct . The New Weather Tags are for the The New Watches Only . We are waiting for GW5 and GW6 to be Updated .
2 Likes
Well I stripped out the complications and it still got rejected again. Just like the other respondent here, I think I am going to let this one die on the vine.
1 Like
Hey I was wondering because you had the same rejections…did you make those “rejected” face in 1.6.9? I made 2 faces in 1.6.9 that have given me this rejection and although finally passed (I have no idea how) the one that I tried to update with 1.6.10 has been rejected twice now with the same reason even though I did nothing but save a new .aab in 1.6.10 for the API/SDK requirements.
So far, all my faces I made in 1.5.7 and previous were all passed with no issues and updating them in 1.6.10 has had no issues yet either. I have even made an entirely new face in 1.6.10 which also passed with no issues.
The thing is, throughout the various versions of WFS that I have used, I have used pretty much the same code/elements/features on my faces so why does it seem like only the faces made in 1.6.9 have issues? I think I just might remake this face entirely in 1.6.10 and see what happens…I bet it passes.
1 Like
Both of the “rejected” watch faces were created with WFS 1.5.7. Then re-uploaded with WFS 1.6.9 and again with WFS 1.6.10. Every single time got the same rejection email. I have also tried asking for more details like error logs, stack traces, images, and anything that could help me understand what’s making Google upset about my watch faces. Only to get the same exact vague auto-generated explanations. So yeah, not the greatest experience so far.
1 Like
Yup, certainly has been the same for me. Google just hates these 2 particular face and I am stumped as to why. Also, if I see another “helpful” email from them I might just put my fist through my screen. It’s certainly not good for my confidence either. Yesterday I managed to get basically the same face passed in 1.6.10 for the API/SDK requirements but that one was originally made in 1.4.*.
1 Like
