Hi Ziqiao Chen! It seems the URL does change after reset (but is still valid) and the URL does not change upon restarting iPhone to get the successful case. I added debug text to my widget to show the URL and whether it can be accessed, then performed these steps: Run the app on my iPhone from Xcode and verify there is no error in the widget, note the sqlite file URL Perform iCloud backup Reset iPhone and restore from that backup The app is not automatically installed because only apps downloaded from the App Store are reinstalled, so I had to enable Developer Mode then run the app from Xcode The error message appears in the widget - the sqlite file couldn't be opened, it is a different URL than it was before the iPhone was reset, and yet FileManager says the file exists, the file is readable and writable, and the contents at that path are non-nil Restart iPhone The error message is not shown in the widget and everything else is the same (the URL, file exists, readable, writable, non-nil contents) The URL in step 1 was file:///private/var/mobile/Containers/Shared/AppGroup/FAF64427-9826-4C86-9C2E-D7E5285BA7EC/MyApp.sqlite The URL in step 5 and 7 was file:///private/var/mobile/Containers/Shared/AppGroup/FDE4F3AF-E775-4D5F-842D-1C5AA77BE26F/MyApp.sqlite The URL is set like this myPersistentCloudKitContainer.persistentStoreDescriptions[0].url = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "group.com.mydomain.myapp")!.appendingPathComponent("\(container.name).sqlite"). Note if you install the app from the App Store instead of installing it via Xcode in step 4, you also see the error in the widget. But if you first delete the app and then install it, you of course wouldn't see the error since there's no existing data from the app. While this may not replicate the issue exactly, it seems to be close enough with the same end result - the app can access the database but the widget fails to until you restart iPhone. It seems it can only be fully tested with the production app that's live on the App Store, since that's the only way iOS will reinstall it upon restore from backup. I can't put debug text in my widget for customers to see. 😀

In testing, I removed this layoutManager code altogether, and it works as expected. It seems like the intrinsic content size height is never actually UIView.noIntrinsicMetric so that code was not executing in the first place 😄

What is known about this error? Will affected Live Photos always encounter this error or is it a bug that can be fixed in a future iOS version?

I've simplified my question in a post here asking how I can now test this framework in an example app, before actually distributing it.

Just in testing it seems like you can’t make the window smaller than 320 in width - classic number

No, UIApplication.shared.supportsAlternateIcons returns false on visionOS, as of now.

Yes after submitting a rating it updates to ask if they’d like to write a review.

FWIW images randomly aren’t there in my local notifications either, though I believe it replicates in all environments (debug, TestFlight, App Store).No idea why, seems to be an iOS bug, I’d recommend filing a bug report.

You’re exactly right. We need the associated time zone in order to display the correct date/time to the user. I submitted FB13363638: PHAsset and PHContentEditingInput API to get creation date time zone. Note the time zone can be changed independently of the location via Adjust Date & Time, and photos don’t always have location anyways, so it’s not reliable to infer a time zone from its location.

I'm encountering this with my photo editing extension, exclusively with iOS 17.0+. This app was last built with the iOS 16 SDK.

No I haven’t

Eventually the old tokens will begin to fail. It’s intentional the token changes upon reinstallation.

This allows you to customize the appearance of the navigation bar title. You set it on the contents within a navigation stack (same place you specify a toolbar and navigation title). The new option that brought about this API is inlineLarge, which iOS 17 introduces. The App Store and TV apps use this style - you can see it in the Search tab. The difference from the large style is it’s pushed up further on screen, so there’s more room for your content (like ads in App Store), and it doesn’t support leading (or center) items.

It is intentional behavior for the widget to reload upon performing an AppIntent. This is what enables the system to get a new timeline entry and animate between the old and new entries. Your code is not executing in the widget except to get a static “snapshot” and then the widget process may terminate, so the state is not being saved in memory to be able to modify upon tapping the button. With that being the case perhaps you can think of another way to achieve the desired behavior. For example perhaps you can persist the last liked item identifier in UserDefaults and show that instead of a random item. Probably need more than that to achieve what you have in mind but should point you in the right direction to persist to disk instead of relying on in-memory state.

This API is free. If you reach the limit (which I believe is not documented and may vary), additional requests will fail for a period of time until you’re no longer rate limited. You will not be charged and there’s not a way to pay for additional requests if you wanted to.