I found that his is (now?) also mentioned in the XCode 16.3 beta release notes:
https://developer.apple.com/documentation/xcode-release-notes/xcode-16_3-release-notes#Distribution
There are in fact two locations that should be deleted:
/Library/MobileDevice/Provisioning Profiles and ~/Library/Developer/Xcode/UserData/Provisioning Profiles
codingFriend1
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
1 day ago
User for
8 years
From
Berlin
Post
Replies
Boosts
Views
Activity
@Engineer
Yes! This seems to solve the issue. Thank you. 🙏
Tip to anybody having issues debugging their share extensions on the Mac: It seems that macOS caches the share extension activation rules for all apps that are in the Applications folder. If changes to your activation rule seem to have no effect when run from XCode, try to make a production build and place it in your Applications folder (and maybe reboot).
Awesome! I had the exact same issue. When testing on the Development environment, I had never added this many images or very large images. So CoreData would never extract image data to external ckAsset files / objects and the field was missing from the schema on the iCloud Dashboard. The trick is to really force CoreData to extract the data to separate assets by adding a lot of large assets (in my case images). Thank you very much!
This is the correct way to do it. In fact, the Watch app will sync to a different Key-Value store. The iCloudKey-Value Store needs to be changed manually in the entitlements file as you said. However, I decided to change the Watch app's entitlements file to use the bundle identifier of the iOS app by setting it to $(TeamIdentifierPrefix)com.my-company.myApp
Yes that's it! (And it is still that way in 2022, so 2 years later)
Yes, that's what was missing. Thank you!
It's weird that XCode does not automatically add the watch app as a dependency, though.
I can't follow you. When I first setup the Watch target in XCode 13, XCode created two targets: one Watch App target and one Extension. This is also how it is shown in the latest tutorial: https://developer.apple.com/tutorials/swiftui/creating-a-watchos-app
But when I moved to XCode 14 and set up the new single-target for the Watch App is not included in archives and submissions anymore. When I inspect the archive, it is not included and in TestFlight app details it states "Watch App: No".