Dear Apple Developer Support team, I would like to request an official confirmation regarding the handling of transaction status in the App Store Server API, specifically for the GET /inApps/v1/transactions/{transactionId} endpoint. As per our current understanding from the official documentation (Get Transaction Info), the API’s behavior appears to be: If a transaction is finalized and successfully processed by App Store, querying this API will return HTTP 200 OK along with transaction details. If a transaction is still in a pending or deferred state (such as awaiting Ask to Buy approval or pending authorization), the API will not return a 200, and instead respond with HTTP 404 Not Found or an appropriate error. Could you please confirm if this behavior is accurate and officially supported? Specifically: Does a 200 OK response guarantee that a transaction is finalized and successfully recorded on App Store servers? In cases where a transaction is pending approval (e.g. Ask to Buy), is it correct that GET /transactions/{transactionId} would return 404 Not Found until the transaction is finalized? We would greatly appreciate your confirmation to align our server-side logic for transaction validation accordingly. Thank you very much for your support! Kind regards, cuongnx

It seems as though using any initializer of SubscriptionOfferView or StoreView will create a memory leak. This can be simply reproduced by adding this to your SwiftUI view: SubscriptionOfferView(groupID: "yourgroupID", visibleRelationship: .all, useAppIcon: true) or StoreView(ids: ["monthly", "yearly"]) Tested on iOS 26 beta 2

Hi :wave: I am not sure that I use it right, I was not able to profile using these events: I am on a M1 Pro machine using macOS 15.5. I just wonder if these events are support on Apple Sillicon.

I’m seeing inconsistent call stacks and usage percentages in the Time Profiler between two Instruments builds: • Xcode 16.0’s Instruments Version 16.0 (16A242d) • Xcode 16.3’s Instruments Version 16.0 (16E140) When I open an old .trace file recorded with the 16A242d profiler in the newer 16E140 Instruments, the call trees and percentage breakdowns no longer match. It looks like the latest Instruments now exposes or collapses different frames (e.g. system libraries, inline code) by default. I rely on these call stacks as a baseline to track performance regressions and verify optimizations over time. Unfortunately, every Xcode/Instruments update changes what I see, making it impossible to compare profiles across versions. My questions: Is there a way in Instruments 16.0 (16E140) to restore the exact call-tree view and percentage calculations that 16A242d produced? Failing that, is there a recommended workflow or tool for capturing CPU profiles in a way that remains stable and comparable, regardless of Xcode or Instruments version? Any guidance on achieving consistent, version-independent performance measurements would be greatly appreciated!

I could use the Metal System Trace before the most recent update, but now whenever I try to profile using the Metal Counter instrument, I get the [Warning] GPU Service reported error: Selected counter profile is not supported on target device. What is the issue here?

I kept CoreLocation’s startUpdatingLocation running for a full day and used Performance trace - PowerProfiler to track the power usage during that time. The trace file was successfully generated on the iOS device, and I later transferred it to my MacBook. However, when I tried to open the .atrc file, I received the following warning: The document cannot be imported because of an error: File ‘/Users/jun/Downloads/PowerProfiler_25-06-16_181049_to_25-06-17_091037_001.atrc’ doesn’t contain any events. Why is this happening? Is there a known issue with PowerProfiler in iOS 26, or am I missing something in the tracing setup? Note: The .aar file and the extracted .atrc file are not attached here, as forum uploads do not support these formats.