So! this appears to be fixed in this week's Xcode 16 beta ... almost! I can create a brand new project, add a package that the iOS app uses, and previews for the watchOS UI now show - finally! HOWEVER! I cannot find a way to get my existing project to work. Removing the package in the Xcode 16 beta reliably crashes Xcode, so the only way to remove it is to drop back to 15, but the problem still persists in Xcode 16 - that I simply cannot get the watchOS previews to show. At one point I did remove derived data, seemed not to help. My project is old and large, so starting an Xcode project from scratch is a non-starter right now. Anxious to hear about anyone else's experiences on this.

Any luck at all fighting this? I submitted a very similar issue with a sample project as FB13566793. It's simply a case of creating a paired iOS and watchOS app and pulling in an SPM package to be used only by the iOS app. When it attempts to show a watchOS preview, for some reason it tries to pull the iOS-targeted package into the build for the watchOS preview. Very simple, very reproducible on other macs as well. I've attempted workarounds but nothing has panned out. Anxious to hear if anyone has luck with this. It's still an issue in the Xcode 15.3 beta

To eliminate any ambiguity or artifacts from my existing project, I verified this in but in the simplest case, using Xcode 15.2: I created a simple project in Xcode: New Project, creating a watchOS app with a new companion iOS app. I verified previews work for the ContentViews for both the watchOS and iOS targets. Then File -> Add Package Dependencies... I added a package - in this case AWSiOSSDKV2 from https://github.com/aws-amplify/aws-sdk-ios-spm - and added it only to the iOS target. Verified it was added correctly in project settings, in the "Frameworks, Libraries, and Embedded Content" section for both iOS and watchOS targets Previews no longer work for the watchOS target

Same here, 15.2 as well - just upgraded from 15.0 hoping for a fix, but same error. My project is an older one (5 yrs), that's adapted over time from earlier versions of Xcode and watchOS app components. Any chance that this could be a cause - that manually adapting projects along the way could have introduced exposure to this error? Hard to think that everyone with an SPM package and a watch app would be experiencing this. Also - anyone have any sense when this could have been introduced? I can't believe I've not had watch SwiftUI previews for the entirety of time that I've had swift packages...

[retracted]

Did not work for me, FYI. I have the same App Group shared for all my targets, and can post data from the watch app but cannot see it in the WidgetKit complication.

Ditto... anyone out there have a solution for this? I saw elsewhere someone commented on using Keychain instead - doesn't seem like the right way to go, but it may be an avenue, all else fails.

FYI, Issue still appears to exist in Xcode Beta 3

I was just referring to my background refresh code: getting JSON data from CloudKit, parsing, processing, etc. It's not a specific API that's timing out, it's that it appears that I'm timing out, since processing will just stop - and it's not while waiting on data, it's during processing of it. Surprisingly, the time elapsed is only a few seconds sometimes. I'm only able to tell from logging that the processing starts, stops for some reason (I've presumed this to be a timeout), and when the next silent push notification comes in, the processing picks back up right where it was suspended. If it matters, I've tended to see this occur more - but not exclusively - on older devices (iPhone 6, 6s,...)

Had a separate exchange via Apple Feedback Assistant, and concluded part of this was user error with respect to file protection levels. I had been using an NSPersistentContainer, with the defaults - i.e., FileProtection = completeUntilFirstUserAuthentication. My mistake was in keying on UIApplication.shared.isProtectedDataAvailable, which - when the device is once authenticated but subsequently locked - is FALSE. But in that case - if the device had once been authenticated - the NSPersistentContainer IS available. It was my misinterpretation of when the file was available, separate from what isProtectedDataAvailable told me. So - it’s not a bug, though it would be useful if there was a way to tell - whether by notification or a property somewhere - if the device has been authenticated. I don't know that that is available from any APIs/properties.

Appears to have been fixed in a subsequent version. No issues in the release versions of iOS 14, watchOS 7

Still persists in iOS 14 beta 6, FYI

Incidentally, this is iOS 14 beta 4

Solution: use applicationWillResignActive/applicationDidBecomeActive to automatically pause/play the video or any active content that might be occluded by the injected TestFlight onboarding screens.