I'm encountering the same error trying to deploy development to production.

Encountering the same crash. Doesn't happen with every workspace but I have at least two that are crashing. Holding shift opens Xcode without restoring the windows so that's how you can get it to open without crashing but then opening one of my workspaces again just crashes again.

No, there is not an API to access people data in PhotoKit as of now.

Thank you very much for your reply! That’s a good suggestion. Bulk geocoding would also be nice I’ll file feedback. My only question now is, when the limit is hit, does that result in all requests by this app failing (all app users) or just for that one user of the app? The documentation seems to imply its per app, want to confirm it’s per instance of the app.

I have the same question. Did ya ever find an answer?

I had the same issue with Xcode 12 and watchOS 7 simulator - it didn't create all of the expected files, supported complication families was empty. It seems this may not be relevant to watchOS 7? I switched to the watchOS 6 38mm sim and it didn't work but at least threw an error alert that said a template wasn't provided for one of the family types (because that's only supported on Series 4 and later). So I switched to the 44mm Series 4 sim and this time it worked without issue.

didRevokeEntitlementsForProductIdentifiers is not called for me either when refunding a non-consumable IAP in the transaction manager window. Will it be called when Apple refunds the purchase in real life? The docs seem to imply it will but only for other family members’ devices not the purchaser. 🤔

I have this exact question. Did you find a solution that doesn't duplicate the videos?

See answer here on Stack Overflow - https://stackoverflow.com/questions/62940266/does-changing-the-default-email-app-affect-mfmailcomposeviewcontroller-usage/66379220#66379220

No, this API only presents the email compose interface. I wondered about this too and this is what I’d recommend to best support third party email apps: https://stackoverflow.com/a/66379220/1795356

I was able to get this to work in my scenario by reordering my subviews which caused it to be able to find the scroll view. I also filed feedback with a sample project to improve the logic so that’s not necessary.

I too am encountering this issue with the latest Xcode and macOS version. Filed FB9856601.

This issue continues to occur with Xcode 13.3 beta (13E5086k) and macOS 12.2 (21D49).

For Mac Catalyst I found this works well: Picker(selection: $selectedColorOption, label: Text("Color")) {     HStack {         Image(uiImage: colorSwatchImage(with: .red))         Text("Red")     }.tag(1) } .pickerStyle(.menu) private func colorSwatchImage(color: UIColor) -> UIImage {     let size = CGSize(width: 24, height: 12)     let rect = CGRect(origin: .zero, size: size)     let renderer = UIGraphicsImageRenderer(bounds: rect)     return renderer.image(actions: { context in         color.setFill()         UIBezierPath(roundedRect: rect, cornerRadius: 2).fill()     }) }

I don’t think this last comment is accurate, at least as of iOS 15. In digital lounges at WWDC Apple engineers explained it is possible for NSPersistentCloudKitContainer to sync while your app is open in the background. It seems though the work is scheduled with utility priority. In my testing it will sync if you make 4 changes - once enough updates are accumulated it’ll process them. But even then my widget is showing the changes from the 3rd update because it hasn’t yet finished updating it seems, and attempting to delay it causes the code not to execute I assume because iOS suspends the app again very soon after. So basically it may eventually sync in background, only if your app is already open in background, and it may not be reliable and your widget might not get the most up-to-date data. Maybe this can be improved by utilizing background task API, that’s what they suggested trying in the digital lounge. Do note they also said NSPersistentCloudKitContainer does not support multi-process sync so only your app should be attempting to sync. And even if a widget were to attempt sync, it’ll never really be able to because iOS doesn’t give it enough time to execute, and widgets don’t run in the background they’re only running when they need to get more timeline entries for example, and widgets don’t get the app’s push notifications which is what enables background syncs to be scheduled. Your app will need to try to keep the widget up to date as opposed to the widget attempting to sync and keep itself up to date.