User Profile

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.

I have been using the offline shader compiler for mac successfully, by first runningxcrun -sdk macosx -find metalwhich returns the path to the shader compiler executable:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metalRunning this executable with -std=osx-metal2.0 successfully compiles the shader.Repeating the same procedure for ios withxcrun -sdk iphoneos -find metalreturns the exact same executable path. Running the executable with -std=ios-metal2.0(or any other of the ios strings) produces the error messageerror: cannot execute tool '/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/metal/ios/bin/metal'The ios subdirectory is missing on my mac. I use OS X 13.6 and XCode 10.1. What is happening here andwhere can I get all missing files to compile shaders for ios offline?

Hello everyoneThis is more or less the same question as inhttps://forums.developer.apple.com/message/292933#292933where noone answered. Now I have the very same problem: I am attempting to test ourapp store application in a sandboxed environment. The app returns 173 if no receipt is thereand the system should then prompt a login, where I can provide credentials and afterwardsthe system should download the receipt and restart the app. All this worked for me and suddenlyit stopped working. Now the app just exists with 173 and no login prompt is shown.Here is a post of someone who claims that there exists (existed?) an OS X bug which preventsthe login window from appearing:https://apple.stackexchange.com/questions/227739/why-have-my-apps-from-the-store-suddenly-started-exiting-with-code-173The suggested solution (delete and redownload) doesn't work for me. Since I am sideloading with'sudo installer -store -pkg <pkgname> -target /', I tried delete/re-sideload and it didn't fix the problem.Does anyone know more about that bug that prevents the login window from appearing? What triggersthat bug? Is there a workaround that works in a sandboxed context as well?Of if it is not due to the bug, what other reasons could there be why the system doesn't proceedafter receiving 173? Does it validate something in the app bundle?

Hello everyoneThe documentation on fences in Metal is very limited and we are having difficulties to figure out how to use them correctly in more complicated setups. We use heaps thus fences are mandatory according to the documentation. Here are some questions for which we currently don't have answers and we would be interested to hear other opinions.A) Does the exact location of updateFence/waitForFence in the encoder matter?The documentation states:"Fences are evaluated at command encoder boundaries. Waits occur at the beginning of an encoder and updates occur at the end of the encoder."This could be read as 'place them wherever you like (except for the one rule stated in the docs), we will make sure the evaluation happens at the boundaries'. After having had a look at the disassembly of these functions I have some doubts that things work that way in practice. These functions go immediately down to the driver which then immediately inserts a token into the current command stream. This doesn't prove anything but it is suggestive.B) Do fences work across command buffers in the same queue?Apparently yes, there are samples using fences with multiple command buffers. On the other hand I have found differing opinions on forum threads.There is certainly some complication since waits apparently only consider those updates which were encoded prior to the wait. With multiple command buffers this scheme only makes sense if we think of multiple command buffers as being chronologically ordered, which is indeed the case when they are part of the same queue, the order being given by the order of commits. If all this holds then the conclusion would be that fences only work (if at all) across two command buffers in one direction, namely with updates in the first submitted command buffer and the corresponding waits in the second commited command buffer. Does all this make sense?C) What exactly can potentially execute in parallel, making fences a necessity?On our iMac Pro we have tried to force a situation where parallel execution leads to corrupted results due to missing fences. Our tests involved render encoders and blit encoders but no matter what we did, the later encoder was always executed strictly after the former, even if we artificially made the first encoder last much longer than the second (i.e. by adding a large loop to the shader). If all encoders would run strictly after each other, then fences would be superfluous. But since the fence API exists for all three encoder types there must be situations where multiple encoders can run in parallel. We first thought that different encoder types could potentially run in parallel but for render/blit encoders this doesn't seem to work on our iMac Pro. Has anyone observed such parallel execution on Macs? On iOS we know that vertex and fragment shader of two consecutive encoders can run in parallel, but we don't know about blit and compute encoders.One reason for this question is obviously that we would like to exploit the possibility of parallel execution across encoders, i.e. by allowing texture uploads (blits) and render passes to work in parallel. We know that Unreal Engine has a sophisticated fencing setup exactly to allow such asynchronous blits, therefore we would be interested to know which hardware/drivers supports these kind of async blits. It's also important for testing purposes. Our code without any fences runs perfectly glitch-free on multiple Macs so far, but if there is any hardware with more parallel execution things can change quickly and we will need to test the code on such hardware.

Hello everyoneWe are having a strange problem occurring on our Late 2013 iMac (NVidia 775M) and whichdoesn't occur on other Mac's we have tested. When we use Frame Capture to analyze ourMetal-based app we observe vertex shader execution times which are way too high, even for trivialshaders that only process a couple of vertices.We can even reproduce this issue with Apple's MetalBasic3D sample. Again the vertex shadertime is reported to be several times higher than the fragment shader time, even though onlya handful of vertices are processed.I would be interested to know whether anyone having a similar Mac can confirm our findingsby running Frame Capture and observing the vertex shader load with any Metal app. Of coursewe would also be very interested to learn whether anyone with the same problem has founda way to solve it.We are using pretty recent versions of OS X and XCode (10.13.5 / 9.4).

We use z-pre pass in our application. It is well known that z-pre pass requires both shader passes to produce the exact same results for the position. In OpenGL this can be enforced using 'invariant gl_Position'. We have not found anything like that for Metal. We have observed that in iOS the z-pre pass does not work correctly when the shaders are compiled with fast math enabled (it works in iOS with fast math disabled and it works in OS X in both cases). Disabling fast math is too much of a performance penalty to be acceptable. Therefore we currently don't know how to solve this problem. Any suggestions and pointers are highly appreciated.