Still seeing this issue with Xcode 14.1 and the library "ProgressHUD". SettingsError: noExecutablePath(<IDESwiftPackageStaticLibraryProductBuildable:ObjectIdentifier(0x000060000bec3ba0):'ProgressHUD'>) An issue has been logged with the offending package, but this used to work without changes needed in the package. https://github.com/relatedcode/ProgressHUD/issues/130 Maybe removing type: .static is all that is needed there too? (Like was done here.)

I am also happy to report that I can again use SwiftUI previews with Xcode 14.2.

I am experiencing this exact same issue as well. Subscription renewals that happen when the app is not running are not presented to my app on launch through Transaction.updates. They remain in an "unfinished" state. Attempting to Restore Purchases does nothing, and attempting to repurchase the subscription just presents the alert that the item has already been purchased. In both cases, current entitlements never reflect that the subscription is purchased and valid.

I have also tried using Product.SubscriptionInfo.Status.updates. Updates do not come in on app launch when a renewal happens when the app is not running. But I do see updates come in when calling AppStore.sync(). This is unlike Transaction.updates, where nothing happens when calling AppStore.sync(). This is not an acceptable workaround, as auto-renewals should be automatic and transparent to the user; not force them to "Restore Purchases".

I agree that the loss of individual fields is a major downside of MKPlacemark and CLPlacemark being deprecated. Now they are embedded in MKMapItem as additional opaque "context" with no information as to what they are. Here's what's lost: CLPlacemark's postalAddress.street is now only available as part of the strings in MKMapItem's fullAddress (in address or addressRepresentations) Example: "Street Rd & Avenue Rd" in "Street Rd & Avenue Rd, Cupertino, CA 95014, United States" Similarly, CLPlacemark's administrativeArea (the "state" in the US) is only available as part of the strings in MKMapItem's cityWithContext or fullAddress. It's also not clear if this context will always be the "state", it may be something else per the documentation ("The city name along with the country name, to provide additional disambiguating context.") Example cityWithContext: "Cupertino, CA" There are no equivalents to CLPlacemark's subAdministrativeArea (typically a "county" in the US) or subLocality (typically a neighborhood or named area of a city). These values are not embedded in any of the "WithContext" strings that I have seen. This is a major step back in the data we get back from Apple's geocoding systems, and much of the data is still there, just embedded in strings without indication of what is used. Any chance we could get additional individual fields added to MKMapItem to maintain parity with MKPlacemark/CLPlacemark? In addition to the "WithContext" fields that are already there?

I am seeing this too.