Post not yet marked as solved
In testing today, syncing in the background with NSPersistentCloudKitContainer seems to be working more reliably with the iOS 16 SDK. The first time you change something on another device it still seems to schedule a task to perform that work with utility priority (via -[NSCloudKitMirroringDelegate checkAndScheduleImportIfNecessary:andStartAfterDate:] which logs Scheduling automated import with activity CKSchedulerActivity priority 2 Utility), so it doesn't execute right away. If you change it again then I'm seeing it does immediately import the two accumulated changes (NSCloudKitMirroringDelegate Beginning automated import - ImportActivity - in response to activity, then -[PFCloudKitImportRecordsWorkItem applyAccumulatedChangesToStore:inManagedObjectContext:withStoreMonitor:madeChanges:error:] followed by NSCloudKitMirroringImportRequest Importing updated records) which triggers NSManagedObjectContextObjectsDidChange, NSPersistentStoreRemoteChange, and NSPersistentCloudKitContainer.eventChangedNotification. This process seems to repeat - the 3rd change will be scheduled, 4th will cause import.
In my app, I have logic to detect if the widget needs to reload from NSManagedObjectContextObjectsDidChange examining the info in the notification's userInfo. In this specific scenario updating one record, NSRefreshedObjectsKey contains an instance of my NSManagedObject subclass, so I call WidgetCenter.shared.reloadAllTimelines() after DispatchQueue.main.async and the database is updated at that time so the widget gets a new timeline that includes the latest change.
But do note that sync won't happen unless the app is open in the background as the remote notifications do not launch your app, so for example restarting the device will result in sync not occurring until they open the app again. Perhaps background task API can be explored to attempt to keep the widget up-to-date otherwise.
Post not yet marked as solved
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.
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()
})
}
Post not yet marked as solved
This issue continues to occur with Xcode 13.3 beta (13E5086k) and macOS 12.2 (21D49).
Post not yet marked as solved
I too am encountering this issue with the latest Xcode and macOS version. Filed FB9856601.
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.
Post not yet marked as solved
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
See answer here on Stack Overflow - https://stackoverflow.com/questions/62940266/does-changing-the-default-email-app-affect-mfmailcomposeviewcontroller-usage/66379220#66379220
Post not yet marked as solved
I have this exact question. Did you find a solution that doesn't duplicate the videos?
Post not yet marked as solved
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. 🤔
Post not yet marked as solved
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.
Post not yet marked as solved
I have the same question. Did ya ever find an answer?
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.
Post not yet marked as solved
No, there is not an API to access people data in PhotoKit as of now.
Post not yet marked as solved
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.
