We've been getting missing API declaration errors when submitting our app to App Store Connect for review. As SDK providers, while we have attempted our best effort to declare which APIs are being called in our Privacy Manifests, it's difficult to determine what we are missing especially with multiple libraries. Only the app container is raised as the offending target, so how do we determine which dependency or even which API call is causing App Store Connect to flag errors, so we can properly declare usage in our Privacy Manifests?

Just wanted to clarify some expected behaviors here. It seems that there are two distinct behaviors for Live Activity flows for freshly installed apps. When you start a Live Activity for the first time and the user hasn't yet clicked on Allow/Don't Allow in the activity interface, there are two different sequences: Starting a Live Activity locally Request a Live Activity locally via Swift Live Activity starts .pushTokenUpdates is immediately triggered, even if the Allow/Don't Allow buttons appear under the Activity UI Starting a Live Activity via push-to-start Send a push-to-start notification to launch a Live Activity Live Activity starts .pushTokenUpdates is not triggered, and .pushToken returns nil. If a user clicks on Allow in the Activity UI, only then is .pushTokenUpdates triggered.

Looking at some of the latest release notes, it appears that lowest supported version is iOS 15.0 for all versions of Xcode 16. Considering that Xcode 16 is the minimum version for submitting apps to the App Store, I would assume that means that Apple expects apps to be on 15.0+. However, knowing that you can manually override this setting in Xcode, there seems to be a lack of clarity on what the true minimum is. Looking at the App Store, it appears there are some apps that can go back as far as iOS 12.0. Is there a definitive way to know what is the true minimum that the App Store accepts?

In the push documentation for Live Activities, there's an option to send an accompanying alert for your Live Activity push updates: "alert": { "title": "Delivery Update", "body": "Your pizza order will arrive soon.", "sound": "example.aiff" } When attaching this to the payload, we get a ping + sound with the updated Live Activity UI, which differs from the standard Live Activity push without an alert attached (which is a silent update). I've also been able to verify that this alert arrives in the Apple Watch as a standard notification but not on the iPhone. I've discovered this separate thread, which seems to confirm the same behavior, but since the documentation isn't super clear on what the expected behavior is, I wanted to verify, is it expected that on the iPhone, we should only get a ping for the Live Activity widget UI and not a standard push notification alert in addition to that?

It seems that in iOS 18.5+ built with Xcode 16.4+, there has been a breaking change since 18.4 with 16.3 within WebKit and how the navigationAction.sourceFrame property is initialized when implementing the decidePolicy delegate method. The flow goes: Implement a WKNavigationActionDelegate with decidePolicy Call WKWebView.loadHTMLString("some-string", baseURL: nil) Upon loading the HTML content, read the value of navigationAction.sourceFrame within the decidePolicy method of the WKNavigationActionDelegate On iOS 18.4 (and below) with Xcode 16.3 (and below); navigationAction.sourceFrame is <uninitialized> On iOS 18.5+ with Xcode 16.4+: navigationAction.sourceFrame is already initialized and is equal to navigationAction.targetFrame It appears that this change was made between minor versions of Xcode and is unexpected behavior of a minor version. Not only was this not called out in the release notes for Xcode 16.4 and iOS 18.5, but it's technically also a breaking change to the WebKit API. Can we get insight on why this change was made and what Apple's policy is on breaking changes between minor versions of Xcode/iOS?