Problem solved! I created a small sample project with a similar construction which just worked: Even async functions could access the class property, while my StoreManager received the following error: Passing closure as a 'sending' parameter risks causing data races between code in the current task and concurrent execution of the closure. By defining StoreManager class as a @MainActor, access to the mentioned property is possible across threads. All asynchronous / delaying work is done in threads, so I'm fine with forcing the StoreManager to the main thread, no performance impact can be observed. I assume (!) my sample code was just working as its functions were located in a UIViewController, residing on the main thread anyway. But that's only an (educated) guess...

Hi Quinn, [quote='820522022, DTS Engineer, /thread/772090?answerId=820522022#820522022'] It sounds like you have a mix of Swift and Objective-C, and some of those clients are in Objective-C. Is that right? [/quote] Exactly! Actually, most of those clients are currently Objective-C classes because StoreKit2 as Swift-only is the main reason to migrate StoreManager. I totally agree to your mention of a "snapshot" - that's what I meant when calling the array a kind of cache, for the lack of better words: It only provides the "point-in-time" state of purchased products, and all clients are notified via NSNotificationCenter when their data was updated. Access to the array property is always in sync calls without blocking / waiting for any asynchronous call to finish.

Just to close this thread: DTS has confirmed the mentioned behavior and there is no solution. Currently, system-wide default UTIs are given priority - a different approach might be to prefer UTIs defined by installed apps. A bug report is required to request an architectural change - how likely this might be. I won't pursuit further as I've filed a very similar request a decade ago regarding macOS...

Apple DTS has confirmed that there is no supported way to programmatically set the active NSColorList in an NSColorPanel. The sort order of color lists will be further addressed following my bug report - I won't hold my breath. The TSI has been refunded...

FYI, the issue of NSColorLists being randomly ordered in NSColorPanel was already reported as an issue in October 2023 (FB13311179), still open and uncommented.

My mistake - I hadn't covered an edge case well (NSString operations with paths). Problem solved.

Did you check out the "accepted reply"? Works for me...

I just installed Xcode and the iOS 13.7 simulator on my Intel Mac Mini: After switching the simulator to "show always" it can be selected as a Run Destination and works. Looks like these "older" simulators are not listed on Macs running with Apple Silicon, like my 14" MBP. I'd consider this a bug...

I have a related issue which just drives me nuts: For all my iOS projects only simulators running iOS 16.4 are listed as Run Destinations ... although I've installed the iOS 13 simulator and corresponding entries are listed under "Devices & Simulators". I've toggled "Show run destination" from "Automatic" to "Always" with no avail. Deployment target is e.g. iOS 13, and I'm running Xcode Version 14.3 (14E222b). As a current bypass I'm booting up the simulator manually and install apps by "xcrun simctl install booted <path to signed .app>" to allow some basic testing, but that's no sustainable solution. Any help is much appreciated! Mattes

RADAR filed (FB10874409)...

I'm in the same boat ... at least this thread confirms that it's not my code failing (after 2h testing). Any news? I might file a bug report, although I already have a queue of ignored ones...

Thanks for your reply, Rich, really much appreciated! Providing a freemium app I'm fine with removing the receipt validation at launch. IAP processing is handling a missing receipt now gracefully like no purchase (doing nothing), and the "Restore Purchases" option pulls the receipt ... so I'm good for now. Nevertheless it has a smell that the sandbox environment is not acting like production, and testing cannot be done with full code coverage. In addition - as Brigitte mentioned - the exit(173) is still documented as the proposed step when no receipt is present - especially to check for a legit app at launch. DCAppAttestService cannot cover this for existing apps with support of older macOS versions (like mine).

Here we go again: Just changed my IAP validation code and the app is reported as damaged after exiting with 173 and no receipt is delivered. Xcode Version 13.4.1 (13F100) on macOS Monterey 12.4 (21F79). Apple, it sucks...!

Working again without any code change at May 18th, 8:15 pm CEST: obviously Apple has fixed the backend, but no official confirmation of the issue, no response on bug reports, no corresponding system status … Apple, please work on your developer community management.

Working again without any code change at May 18th, 8:15 pm CEST: obviously Apple has fixed the backend, but no official confirmation of the issue, no response on bug reports, no corresponding system status … Apple, please work on your developer community management.