We are working on a screen capture app. I have provisioning setup for a developer id certificate for do direct distribution and a distribution certificate for Mac Store distribution;
I submitted the app to the store with the distribution certificate provisioning active. We need to add documentation so while we are waiting, we decided to distribute the app directly and this is where the problems come in.
I made the developer id certificate and archive->exported the app. Then I manually stapled the app with "xcrun stapler staple Madshot360.app". I created a dmg file with the exported app.
The problems are;
- The app captures screen area with ScreenCaptureKit. A prior version of the app used a development certificate. When a user runs this new developer id cert app. the macos gets confused because it doesn't connect the new version to the already permissioned older app version. The user has to manually delete the old permission and then restart the app so the new version creates a new record which can then be enabled. This is confusing for the user since the permission says the app is enabled but it really isn't. We experimented with IT using a command line to delete the old app permission. That did not remove the old permission but now the user can't delete this record at all. What can I do to force the removal of a permission that is broken. The command we ran was this.
"sudo tccutil reset ScreenCapture com.madwire.Madshot360"
- The app used to display it's normal warning that screen recording needed the users permission. This is the permission I talk about above. Now there is a second permission screen that states the following;
"Madshot360" is requesting to bypass the system private window picker and directly access your screen and audio. This will allow Madshot360 to record your screen and system audio, including personal or sensitive information that may be visible or audible. Allow, Open System Settings.
This is basically what the normal alert does. Why the second window and how can I stop it from appearing when the user has already allowed it. Is it because the binary is distributed directly from my computer?
Summary:
- What can I do when a permission is broken? Is there a command that IT can use to remove any old permissions before installing the app. This app is to be used internally.
- Is there a command line that will remove a specific app's permission before installing the app? Remember, the command line I showed you basically further broke the permissions for this app.
- What is causing this second warning dialog to be displayed?
I see two issues here:
-
A conflict between development-signed and distribution-signed code
-
That second alert
Lemme tackle them in the reverse order.
That second alert is the result of additional privacy hardening on recent versions of macOS. The simplest way around it is to use ScreenCaptureKit’s picker UI. Presenting that UI puts the user is in direct control over what you’re allowed to capture, and thus there’s no need for the system to present an additional alert.
If that doesn’t work for you then you pretty much have to live with that second alert. The only exception to that rule is that, if you’re building a screen sharing app, you can request the com.apple.developer.persistent-content-capture entitlement.
Coming back to your development- vs distribution-signed code issue, yeah, that’s annoying. The fundamental problem here is that development- and distribution-signed don’t have mutually compatible designated requirements. I talk about that in depth in TN3127 Inside Code Signing: Requirements.
Notably, App Store and Developer ID signed apps do have mutually compatible DRs, so you only have this problem on machines where you’ve run the development-signed version of your app. Most folks don’t run development-signed code on a wide range of machines, so it’s easy to fix problems like this by hand.
In terms of how you automate this, the only option I’m aware of is tccutil. Apropos that you wrote:
Hmmm, that’s weird. The ScreenCapture service is system wide, so I woulda thought that resetting it using sudo is the right option. Are you able to re-run this test without using sudo?
FYI, I do this sort of testing in a VM. That way I can take a snapshot of the VM before it’s ever seen my app and restore from that snapshot between tests. That’s the best way to reproduce issues like this, because it ensures that test N doesn’t change the state of the system in a way that affects tests N+1.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"