I'm also interested in this, I'd like to be able to detect music playing and pause it for a task, then resume it after. Would you mind sharing how you simulated the play/pause media key?

Hola Quinn, Thanks for the terrific reply. It’s hard to say without more context. Most notably, why are you escalating privileges in the first place? One of the many things App Wrapper does as part of it's process is to ensure correct permissions on the files within the application bundle, but it fails when the customer doesn't have permission to alter to the permissions of a file. Another task it does it does is to strip ACLs and Xattrs, sometimes customers have screwed up ACLs that prevent the ACLs from being removed, and/or prevent xattrs from being removed. In this case, these actions can be done via API or via system commandline tools. No. The point of SMJobBless is that you can avoid the installer package. If you already have an installer package in play, there’s no need for SMJobBless. The package can install a launchd daemon directly. That's good to know, as I don't use an installer package for my apps, and it means I misunderstood some aspects. That depends on how you look at it. The problem with AEWP is that there’s no secure link between the code asking to elevate privileges and the code that’s run with elevated privileges. SMJobBless fixes that. I kinda guessed that when I saw how complicated it was to interact with the helper, v.s. just using AEWP. I don't know if it's really that necessary for my current needs. However it looks like it might be the only recommended choice. However, its design, where the privileged helper tool retains its privileges, certainly engenders some security risks. You must write that code securely. This scares the crap outa me, as it makes me afraid that I do something wrong, I put my customers at risk, I guess you could say that with all the mechanisms we've discussed, but this feels like a big red flag. Thanks Quinn, you've given me some more information to ponder. I still currently don't know which direction to take, but hopefully after some percolation, I'll make be able to make a better decision. Sam Rowlands p.s. I guess you've seen the appreciation thread happening on Twitter :)

I have been able to get SKReceiptRefreshRequest working, but it's a PITA because it is asynchronous, so it can pop-in while the user is working in the app, which means you can't just terminate any more and must think of how to handle the app's flow for the App Store DRM.

Thank you Quinn, The reason this creates some complication is that I and several others are used to wrapping for App Store Submission, and before we "Submit for Review", move the application to the Applications folder and launch it, just to give it a final check (including the receipt). I've been trying to see if I can test the receipt verification code when using "Apple Development" but it doesn't work, I think there is a failure somewhere with testing receipts in general as I see others having problems testing receipts at the moment. As for TestFlight, as a Mac only developer, I've never used it before and therefore I need to learn how to interact with it. However I'd feel more comfortable being able to test our apps locally before submitting it to a testing service, especially things like the receipt verification. let infoCF = try secCall { SecCodeCopySigningInformation(meStatic, [], $0) } let info = infoCF as NSDictionary let entitlements = info[kSecCodeInfoEntitlementsDict] as? NSDictionary Thank you for this code snippet. I have been using the same API with SecStaticCode to read the application after it has been signed (a sort of code sign diagnostics tool), I am sorry to have to ask, but I don't currently see how this can tell me if the macOS knows this is signed with a profile or not as (in my tests) this API returns the apps Entitlements regardless. I've looked through "SecCode.h" at the constants listed under "SecCodeCopySigningInformation" to see if there's a key, but it is not obvious to me. However if the rule of thumb is that "Apple Distribution cert + provision profile + certain entitlements" == "can't be run locally", then I guess I don't really need to know at this point. Thank you for taking your time to assist me. You must be getting tired of me asking questions and sometimes clearly not understanding things.

Addendum: So for this time around I was able to actually figure out the crashing! ProvisionedDevices - When using the "Apple Developer" certificate and provision profile, the machine being used for testing must be registered at Apple and included in the Provision Profile. Am still not able to test with a Apple Distribution certificate and matching profile, it also does not include a ProvisionedDevices section. I'll keep at it, nice to finally get somewhere.

Hi Quinn, It's been a while and I am sorry for the late response, I've had other things and I've also been trying to discuss this with other developers, it seems like it is something that I am doing wrong because no-one else appears to be running in to it :( So in summary, adding a Provisioning Profile to the application doesn't cause a problem, until the keys from the Provisioning Profile are added to the applications entitlements, keys such as "com.apple.application-identifier" or "com.apple.developer.team-identifier". I have tested it with both the "Apple Distribution" and "Apple Development" certificates. I have also removed the Provisioning Profile from the application and I of course get the same crash, so my guess is that I'm not inserting it correctly into the application. It is added to the root of the "Contents" subfolder of the application bundle and is called "embedded.provisionprofile", which is done BEFORE any code signing. So this raises two questions. Do I need to provide some extra information at signing time to notify code sign to use the profile? Is there a way that the Security framework can tell me that it knows the profile is there, some sort of validation?

Thank you Quinn for your help. On a hunch I tried CFEqual to compare the two certs and it appears to do what I want... Sorry that I took up your time, if only I tied this earlier.