Post

Replies

Boosts

Views

Activity

Reply to App group shared user defaults
What about if I want to share a preference between a Watch App WidgetKit Extension (for Watch Face complications) and a Watch app? I don't see how any of the suggested methods would apply to a WidgetKit extension.... This has worked for me previously when sharing between iPhone App and iPhone Widget Extension.
Topic: App & System Services SubTopic: General Tags:
Aug ’23
Reply to Migrating ClockKit complications to WidgetKit not working
I've found the Apple Watch Face Editor on iPhone is still not reliable when doing the WIdgetKit migration. See separate post here for details on that, any ideas welcome. As for the migration, I'm having success with the getWidgetConfiguration in my ComplicationController which conforms to the CLKComplicationWidgetMigrator I provide it the identifier for the widget configuration and I provide the Widget bundle extension identifier. Although I have widgets on iPhone and Apple Watch, I provide separate Extension targets and identifiers as I was struggling to get the right entitlements with a combined one. If there are any other details I can provide to help please let me know!
Topic: App & System Services SubTopic: General Tags:
Jul ’23
Reply to Swift Charts Slow Navigation
Another +1 on this here. I'm trying to draw Charts with ~1,000 point marks and scroll through them in a page style tab view. Even on the latest devices there's noticeable lag. Was wondering if there's anything that can be done to pre-draw them, optimise the data set or something. Currently I just use: In the View initialiser: let data:[(Date,Double)] And in the view body: ForEach(0..<data.count, id: \.self) { index in PointMark( x: .value("Time", data[index].0), y: .value("Data", data[index].1) ) } Many thanks for any suggestions
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Jul ’23
Reply to Complications in WidgetKit - .accessoryCorner with curved text
Right, I've submitted 2 subtly different feedback for this. One for existing SDK and one for WatchOS 10. If this isn't resolved by WatchOS 10 I'm going to be in big trouble with my users because I need to implement WidgetKit to be in the Smart Stack. But If I implement it as is, I'll loose one of my most popular Complications which will really upset users. Stuck between a rock and a hard place.... plus I did confirm in a WWDC23 lab that WidgetKit implementation is all or nothing, you cannot run ClockKit & Widgetkit complications on the same Watch. Here are the feedbacks, FB12331689 & FB12331662 🙏 for a fix
Topic: App & System Services SubTopic: General Tags:
Jun ’23
Reply to Watch Complication Only Showing Dashes
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!
Topic: App & System Services SubTopic: Core OS Tags:
May ’23