Likely a bug can you file a feedback report?

I ran some tests and documented what I’m seeing: https://stackoverflow.com/a/76673642/1795356

The documentation states you can add it to the app target and it’ll run in your app’s process. But I don’t see how it would compile when referencing an intent in the widget extension when that intent struct only exists in the app target. 🤔 Were you able to figure it out?

Devices running major beta OS versions, such as iOS 17.0, cannot rate or review apps. Apps may not work as expected on beta releases so users cannot rate apps based on that experience. For this reason, requesting a review will not show the review prompt until iOS 17 is publicly released.

Yes this is an issue. See this previous post: https://developer.apple.com/forums/thread/692177

I can confirm this issue occurs with a StoreKit configuration file, in debug mode run from Xcode, TestFlight, and in the production App Store environment. 😕 FB12107567 StoreKit 2: AppStore.sync() unexpectedly throws StoreKitError.userCancelled when a network error occurs

Same here, the model load request fails due to a 503 error. Filed FB11653274. Error Domain=com.apple.CoreML Code=8 "Fetching decryption key from server failed." UserInfo={NSLocalizedDescription=Fetching decryption key from server failed., NSUnderlyingError=0x28b08a310 {Error Domain=CKErrorDomain Code=6 "CKInternalErrorDomain: 2022" UserInfo={NSDebugDescription=CKInternalErrorDomain: 2022, RequestUUID=F7349D6B-6F83-4C92-84AD-51AF9D682735, NSLocalizedDescription=Request failed with http status code 503, CKErrorDescription=Request failed with http status code 503, CKRetryAfter=32, NSUnderlyingError=0x28b08a5b0 {Error Domain=CKInternalErrorDomain Code=2022 "Request failed with http status code 503" UserInfo={CKRetryAfter=32, CKHTTPStatus=503, CKErrorDescription=Request failed with http status code 503, RequestUUID=F7349D6B-6F83-4C92-84AD-51AF9D682735, NSLocalizedDescription=Request failed with http status code 503}}, CKHTTPStatus=503}}}

I too would like an API to access the user-defined caption on PHAsset or in its metadata please. FB8244665, FB10205012

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.

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()     }) }

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

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.

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