There is a solution. It comes from ClockKit framework. It’s not mentioned in new APIs, but it works. In your watchOS target create file ComplicationController.swift with the following content: import ClockKit class ComplicationController: NSObject, CLKComplicationDataSource { func complicationDescriptors() async -> [CLKComplicationDescriptor] { [CLKComplicationDescriptor( identifier: "yourBundleID", displayName: "Your app name", supportedFamilies: CLKComplicationFamily.allCases)] } func currentTimelineEntry(for complication: CLKComplication) async -> CLKComplicationTimelineEntry? { nil } } Then add this field in the Info.plist of watchOS target: key: ClockKit Complication - Principal Class, value: $(PRODUCT_MODULE_NAME).ComplicationController (String type) I hope there will be a better solution later on.

There is a solution. It comes from ClockKit framework. It’s not mentioned in new APIs, but it works. In your watchOS target create file ComplicationController.swift with the following content: import ClockKit class ComplicationController: NSObject, CLKComplicationDataSource { func complicationDescriptors() async -> [CLKComplicationDescriptor] { [CLKComplicationDescriptor( identifier: "yourBundleID”, displayName: "Your app name", supportedFamilies: CLKComplicationFamily.allCases)] } func currentTimelineEntry(for complication: CLKComplication) async -> CLKComplicationTimelineEntry? { nil } } Then add this field in the Info.plist of watchOS target: key: ClockKit Complication - Principal Class, value: $(PRODUCT_MODULE_NAME).ComplicationController (String type) I hope there will be a better solution later on.

Join to this. I want to have deep link from complications to specific view in watch app. In iOS app .widgetURL works great together with .onOpenURL. But on watchOS it doesn’t work (at least for me). It seems like WKExtensionDelegate also doesn’t have such capabilities as SceneDelegate in iOS app to handle incoming URLs..

Hello. I have the same question. I have SwiftUI iOS app with widgets and working deep linking from widgets to specific views based on .widgetURL(…) in widget views and .onOpenURL { } in ContentView. But it seems like on watchOS .onOpenURL doesn’t work. It is simply not called on opening the watch app from complications. Is there a mechanism to deep link from complication to the watch app?

OK. It seems to be fixed in iOS 16 beta 6.

I've had this warning ("Publishing changes from background threads is not allowed") as well while I was using .onReceive(NotificationCenter.default.publisher(for: .NSPersistentStoreRemoteChange)). To avoid this problem let this publisher receive notifications on a main thread like this: .onReceive(NotificationCenter.default.publisher(for: .NSPersistentStoreRemoteChange).receive(on: DispatchQueue.main). I can't say would it affect the UI smoothness - in my case it is not.

Apple definitely did something with CloudKit. In these threads there are also some strange issues with iOS14/15 support: https://developer.apple.com/forums/thread/682925, https://developer.apple.com/forums/thread/690044 Framework Engineer wrote this: "We made a number of changes to Core Data this year to isolate CloudKit classes from non-cloudkit clients". I think it's all somehow connected with each other.

Same issue with my app with iOS 15. After a fresh installation, after a couple of saves, the data stops syncing with iCloud. This can be seen on the iCloud Dashboard. No data is sent or received. They are saved only locally. The most interesting thing is that the size of the application data in the system settings stops changing. I can delete and add data - the displayed size remains the same (it is unclear where the changes occur at all). My application does not crash. Only there is no synchronization with iCloud. On iOS 14 everything syncs perfectly and quickly.