Thanks, eskimo. I notice another post with a similar issue:. The header file for the framework had the following protocol... @protocol itemSDK <NSObject> - (SDK_RESULT) getAvailableItemList:(NSMutableArray**)itemList; // ... @end I tested this specific API with the "standard pattern" and it does not fail. I will give it a try with the many other SDK interfaces for this framework and see if this can be the best solution. BTW, where is the standard pattern documented as the proper way to pass a value for an AutoreleasingUnsafeMutablePointer?. I found very few examples and most assign an initial value. I reviewed many of the videos from WWDC on unsafe pointers but none cover this particular pointer. Maybe I missed something.

I am having a similar issue but it is with a third-party framework where I cannot change the interface. If you have any further insight or help, please let me know.

Again, thanks eskimo. I tried several other of the APIs using the standard pattern as a solution. This does eliminate crashes but the results returned are not always the same as before when a value was provided instead of nil. In a different, but very similar API call to the getAvailableItemList, an NSMutableArray is to be returned but instead I get a SDK_RESULT value indicating that the invalid parameters have been supplied. If I use the workaround that I have instead (that does crash and provides a non-nil value), then I get a success SDK_RESULT along with the values in the array parameter. So I think each will need to be tested. I just wish I had worked as before without crashing. I have also tried replicating the same crash with sample Object-C code with no success. Do you know if there might be some interoperbility differences with a framework compiled with an older Xcode but used with Swift code under Xcode 14 (with -O)?. I can try and ask the vendor what Xcode they use to build their frameowrk. Based on the warning in the usage sample code they provide...it is not a recent version.

This seems to be resolved in Xcode 15 Beta 2 (yet my bug report in Feedback Assistant remains open with no reply from Apple).

A third query: I only see these warnings using the simulator. We are forced to use the Rosetta simulators as a required third-party library that does not support Apple Silicon (I know, I know...but not my company) is being used. However, debugging on a real device does not show these warnings. There is no mention that the Thread Performance Checker is limited to the simulator. Is that the case? I assume the suppression file would not apply (as it is not local to the device itself). Does the suppression file need to be available as a resource within the app bundle for the simulator to find?

I had previously opened a Feedback Assistant on May 8th (ID: FB13788846). I have attached the requested files.

Although I had accepted the answer from the App Store Connect Engineer (as it does get around the error in Transporter 1.3), it presented a new problem after uploading the app. Without the LSMinimumSystemVersion key in the Info.plist, I get an email from App Store Connect with the following issue: ITMS-90899: Macs with Apple silicon support issue - The app isn‘t compatible with the provided minimum macOS version of 11.5. It can run on macOS 12.0 or later. Please specify an LSMinimumSystemVersion value of 12.0 or later in a new build, or select a compatible version in App Store Connect. For details, visit: https://developer.apple.com/help/app-store-connect/manage-your-apps-availability/manage-availability-of-iphone-and-ipad-apps-on-macs-with-apple-silicon. The app minimum deployment is iOS 14.7. I tried setting the macOS minimum version for the app via the instructions (on App Store Connect - Pricing and Availability page) but I still get the issue email. This happens if I set it to Automatic (11.5) or 12.0. I get the same response regardless of the selected version. If I add the key back in, Transporter 1.3 has the same issue. If I use the key without LS as suggested by the engineer, then I get the email (I assume that this is just not recognized as it is not documented). If I restore the key as documented (LSMinimumSystemVersion) and I use the prior Transporter (1.2.5), all works as it did before (no error and no issue email). I think this is just an error in Transporter 1.3 when using this key as documented. However, the fact that without the key, the setting on App Store Connect is not honored is also of concern. It may have something to do with the app iOS 14.7 minimum deployment...but that had not been an issue when I was able to specify the key in the Info.plist with the prior Transporter app version.

FWIW: I was able to install on a test device using iOS 26 beta and it did not crash as it did in the simulator. My assumption is that the device has the new Preview app installed and the QuickLook API utilizes this via an extension to present the file contents, etc. I do not see the Preview app available in the simulator. It would be great to confirm this and add this to the release notes and verified by an Apple techie.