Watch Complication Only Showing Dashes

Question

I have a watch complication that used to work just fine and now all of a sudden in my latest build it's showing only dashes. The watch app is there, if I tap on the complication then the watch app opens correctly, if I edit the watch face and select the complication I can see my placeholder (and it's fine) but when I select that complication, the sample watch face shows dashes.

The only major change I've made is to make the watch app a single-target without an extension delegate as per Apple's recommended settings. I don't think this is the problem as the simulator shows the complication. It's only on the Watch Series 4 that I'm testing on that I can't see my complication.

It was working only last week and I have not touched the complication code at all, so I'm stumped as to what's wrong. I can't find any help on line, apparently no one has ever seen the complication just have dashes.

When I debug the watch app and ask for how many complications there are, it comes back with zero even though I've put them on the watch face. It seems like watchOS9 is just not respecting the complication any longer but I can't figure out why.

Please note that I'm not using WidgetKit complications as the corner complication doesn't flow the text in an arc like ClockKit does, so I'm still using the old complications. But none of the code is getting called as none of my breakpoints are firing.

I've rebooted the watch about 10 times and the problem persists.

Any ideas why all of a sudden this has fallen over and gone boom?

2.1k

Posted by

Attila

Reply

Add a Comment

Answer 1

I am 99% sure I know what's happening here having experienced the exact same issue. I too migrated to the single app target and have regretted it for this problem ever since.

My understanding is that in the WatchOS system there are caches for the complications you run on your watch face. These caches include bundle identifiers for the complications, bundle identifiers which change when you migrate to the new single target! So this means the complications on your existing watch face point to what seems like a non-existent app hence the "--". I think the reason this so blatant problem has got through and continued is because Apple expects developers to also adopt WidgetKit for complications instead of Clockkit, and this has a migrator (although I've read plenty of issues with that). The problem is that some developers, including me, are not yet adopting WidgetKit for complications for many reasons including supporting < WatchOS 9, issues with WidigetKit update performance not being as reliable as ClockKit etc....

In theory, with my answer above you would think that just deleting the complications off the watch face and adding them back will resolve the issue. It can do, but often the caches don't clear and you have to either reboot the watch, delete the watch face entirely and start again or various other combinations of fixes. I missed and therefore shipped the problem so I have had to create an entire support document for my users to resolve this bug. I also will not ship an update undoing the problem because then I'll have even more users with watch faces on a variety of complication bundle identifier caches if that makes sense....

So, if you have shipped it, that's a problem. The good news is it won't affect new users of your app, but old users with existing complications will have a pain migrating over. If you haven't shipped yet, my only advice is don't and revert back to a single target until Apple fixes the issue. (FB 11989396) If you somehow felt like you had to ship a single target you could try changing all the identifiers in your CLKComplicationDescriptors you provide to the getComplicationDescriptors() function. I've not tested this but think it would solve the problem. That said, any existing users with watch face complications will still have to change them for the new ones, but the caching/restart issues should be prevented.

I really hope this is the answer you're looking for and it's helpful, please let me know either way! As I'm sure you can tell from the length of my response, it's given me a great deal of pain in the last 8 months!

Posted by

simonfromhelix

Thanks! Sadly, I found this thread only after releasing a watchapp update with a single app target, and looking why Weathergraph users report randomly broken complications. Not even the new watchOS betas fix this :(.

—
tomaskafka
Reported as FB12819243 with a link to this issue.

—
tomaskafka
@simonfromhelix would you be able to share what specific steps you told users to take in order to fix this issue? Unfortunately I wasn't aware of this issue before releasing my update, and now obviously it's too late. In my testing, just switching to another complication then back again fixed the issue, but I have at least one user now who wasn't able to get things working again by doing that.

—
developer555

Answer 2

I am 99% sure I know what's happening here having experienced the exact same issue. I too migrated to the single app target and have regretted it for this problem ever since.

My understanding is that in the WatchOS system there are caches for the complications you run on your watch face. These caches include bundle identifiers for the complications, bundle identifiers which change when you migrate to the new single target! So this means the complications on your existing watch face point to what seems like a non-existent app hence the "--". I think the reason this so blatant problem has got through and continued is because Apple expects developers to also adopt WidgetKit for complications instead of Clockkit, and this has a migrator (although I've read plenty of issues with that). The problem is that some developers, including me, are not yet adopting WidgetKit for complications for many reasons including supporting < WatchOS 9, issues with WidigetKit update performance not being as reliable as ClockKit etc....

In theory, with my answer above you would think that just deleting the complications off the watch face and adding them back will resolve the issue. It can do, but often the caches don't clear and you have to either reboot the watch, delete the watch face entirely and start again or various other combinations of fixes. I missed and therefore shipped the problem so I have had to create an entire support document for my users to resolve this bug. I also will not ship an update undoing the problem because then I'll have even more users with watch faces on a variety of complication bundle identifier caches if that makes sense....

So, if you have shipped it, that's a problem. The good news is it won't affect new users of your app, but old users with existing complications will have a pain migrating over. If you haven't shipped yet, my only advice is don't and revert back to a single target until Apple fixes the issue. (FB 11989396) If you somehow felt like you had to ship a single target you could try changing all the identifiers in your CLKComplicationDescriptors you provide to the getComplicationDescriptors() function. I've not tested this but think it would solve the problem. That said, any existing users with watch face complications will still have to change them for the new ones, but the caching/restart issues should be prevented.

I really hope this is the answer you're looking for and it's helpful, please let me know either way! As I'm sure you can tell from the length of my response, it's given me a great deal of pain in the last 8 months!

Posted by

simonfromhelix

Thanks! Sadly, I found this thread only after releasing a watchapp update with a single app target, and looking why Weathergraph users report randomly broken complications. Not even the new watchOS betas fix this :(.

—
tomaskafka
Reported as FB12819243 with a link to this issue.

—
tomaskafka
@simonfromhelix would you be able to share what specific steps you told users to take in order to fix this issue? Unfortunately I wasn't aware of this issue before releasing my update, and now obviously it's too late. In my testing, just switching to another complication then back again fixed the issue, but I have at least one user now who wasn't able to get things working again by doing that.

—
developer555

Answer 3

Thanks for the reply! Your description matches what I was seeing exactly. I'm glad I wasn't the only one seeing it, as I thought I was going crazy! Unfortunately I didn't see the problem before shipping out the update. Apple could have done a better job about reporting this back to us, as a mismatched descriptor is a real problem! A log entry from the watch to the phone would have cleared up a lot of confusion, even if it didn't help us fix the problem.

I didn't think about removing the watch face, so I unpaired the watch and set it up as a new watch (and then had to reconfigure the watch faces). This cleared the problem but I've seen other issues show up:

The complication will show the template and then update itself several times until it reaches the correct date
The complication will forget what it is and show incorrect data. I traced this down to code that used an old graphic bezel complication layout instead of the new layout, but I'm still puzzled by why it branched out to that code path. I need to make sure any changes don't cause other problems now.

All of this makes me wish I hadn't switched over to the single-app approach. Apple's constant nagging about doing it finally convinced me, and now like you I am regretting it. But at least now with your help I understand what is going on. Again, many thanks!

Posted by

Attila

Add a Comment

Watch Complication Only Showing Dashes

Accepted Reply

Replies