User Profile

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?

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?

HelloConsider the following sequence of events:Developer 1 takes package A.ipa, resigns it with his own certificate yielding B.ipa.Developer 2 takes package B.ipa, resigns it with his own certificate yielding C.ipa.Both certificates are developer certificates and the embedded provisioning profile isa developer profile.If Developer 1 or Developer 2 attempt to install B.ipa using their local Mac and iOS device,it fails with 'invalid entitlements'. If Developer 2 attempts to install C.ipa it succeeds.When I print the entitlements using 'codesign -d --entitlements - Payload/***.app' theresults are identical.When I diff the provisioning profiles Payload/embedded.mobileprovision in both packagesthe results are identical.When I print the signature info using 'codesign -dv --verbose=4 Payload/***.app' in bothpackages I see that the 'Authority' shows the correct certificate name. Comparing thename with the information shown using 'Quick look' on the embedded provisioning profileshows that both certificates are included in the profile.To summarize: we have two ipa's with identical entitlements and identical profiles, bothsigned with certificates that are included in the profile, and one ipa fails to install and theother doesn't. The error message 'invalid entitlements' doesn't even remotely make sensein this context. Does anyone have an explanation what exactly could have happened here?The only difference I see between the two ipa's is the certificate that was used to sign.