Hello We are developers of a long-running game series and now reports have started to come in that users who install any of our previous games from the Mac App Store on OS X Sequoia are shown a popup claiming "The exit(173) API is no longer available". It's actually a lie, the mechanism is still there, the receipt generation still works and the game still runs afterwards. But the popup is confusing to users therefore we need to update the code. Apparently the replacement for the old receipt generation mechanism is AppTransaction which does not exist for Objective C. We have attempted to use it using the Swift/ObjC interoperability and failed so far. The problem is that we need to call async methods in AppTransaction and all our attempts to make this work have failed so far. It seems as the actor/@MainActor concept is not supported by Swift/ObjC interoperability and without those concepts we don't know how to pass results from the async context to the callers from ObjC. The lack of usable information and code online regarding this topic is highly frustrating. Apple really needs to provide better support for developers if they want us to continue to support the Mac platform with high quality games and applications on the Mac App Store. We would appreciate if anyone can cook up a working sample code how to use AppTransaction in ObjC. Thanks in advance!

Hello all We would like to use AMD's FidelityFx Downsampler in our custom game engine and we are having difficulties to correctly implement it for Metal due to its use of the globallycoherent keyword. We have done extensive search online but have not succeeded in finding an answer. What we have found is the largely undocumented 'volatile' keyword, so we were hypothesising that marking a texture with 'volatile' (which implies 'device volatile' since it's a texture) could have the same effect but we are far from convinced it would work. Does anyone have insights into this?

Hello everyone I am testing receipt validation for an app to be submitted to the mac app store. After starting the app a login window popped up and I entered my regular apple id before realising I need to enter an apple id associated with a sandbox account. Now I can't get the login window to show again when starting the app, it seems as I am permanently (or temporarily?) logged into the sandbox account on the mac. How can I log out from the sandbox account? Is it even possible? Does the account time out after a while so that I just need to wait?

Running 'tccutil reset microphone' gives the error message 'tccutil: Failed to reset microphone'. The same command worked in the past. Deleting the TCC.db files didn't help. In the console there is an error from the tccd daemon saying handle_TCCAccessResetInternal: Invalid Service Name: kTCCServicemicrophone(Service name is invalid on this platform) Any ideas?

Hello I have an executable (not an app bundle) which accesses the microphone. When I run it in XCode it crashes with "[access] This app has crashed because it attempted to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSMicrophoneUsageDescription key with a string value explaining to the user how the app uses this data." The required key/value is present in the Info.plist. I can also embed it into the binary and verify the presence of the key/value pair with otool. If I run the executable outside XCode (Terminal, Finder) no problem occurs. That's even true if I don't embed the Info.plist. The situation is really absurd: running outside XCode WITHOUT the microphone usage key doesn't crash, running inside XCode WITH the microphone usage key does crash. XCode itself does not ask for microphone access, even after clearing permissions with 'tccutil reset Microphone'. 1) How can I solve the crash issue in XCode? 2) Why does the executable not crash outside XCode without embedding an Info.plist containing the microphone usage key?

We have observed renderCommandEncoderWithDescriptor() crashing when multiple threads are executing this method at the same time. The MTLCommandBuffer is different for each thread so we would expect no threading issues, as the documentation states that 'Command queues are thread-safe and allow multiple outstanding commandbuffers to be encoded simultaneously'. The callstack showed something very curious: the driver (AMDRadeonX5000MTLDriver on a iMac Pro) attempted to do a 'fast color clear' at that point and it seems to use blit operations to do that. This is unexpected, actual GPU work should never been done prior to committing the command buffer. Does anyone have insights into this? Could this be a driver bug?

We recently enabled Hardened Runtime in our Mac app and now it is rejected in the App Store:Guideline 2.4.5(v) - Performance:Your app requests keystrokes access from the user during operation of launch of the app.Next StepsTo resolve this issue, please confirm that you are using:- NSEvent.addLocalMonitorrather than- CGEvent.TapCreate.The problem is: we don't call CGEventTapCreate(). I verified this by printing all symbols in all executables with the 'nm' tool. The rejection message is clearly not sufficient for us to resolve the problem. Does anyone have insights here? Are there additional undocumented triggers for this type of rejection?