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.

This seems to be resolved in iOS 17.0 beta 6. Repeating these steps causes Plants to appear in the plural form as expected.

One way you can get it is by searching your favorite search engine for App Store . Likely the link you’re looking for will be in the top results.

UISearchBar is the only type that conforms to UILookToDictateCapable currently so you can only set isLookToDictateEnabled on a search bar, not a text view. It’s false by default for iOS apps but you can enable it so people using your app as-is on visionOS can use that feature.

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.

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