help with "App is Requesting to Bypass System Private Window Picker" alert

I have a macOS app in production, supporting all macOS versions since 10.15 (Catalina) thru Sequoia. One aspect of the app's functionality is to screen capture the entire screen, including all windows.

Starting with Sequoia, my users are receiving a scary system alert saying:

"SomeApp" is requesting to bypass the system private window picker and directly access your screen and audio. This will allow SomeApp to record your screen and system audio, including personal or sensitive information that may be visible or audible.

I have several questions and concerns about this alert. First of all, as a developer, this is frustrating, as I am using documented, long-standing system APIs, and made no change to my code to cause this warning. Second, nothing in my app records audio in any fashion, and yet the user is made to think I am trying to furtively bypass security controls to record audio, which is absolutely false. The alert seems to be due to the screen capture feature, which is one of the main features of the app, which the user explicitly requests and grants permission for.

But to get to the point of the question: is there any definitive documentation anywhere describing exactly which API's trigger this alert? I can't find first-party information from Apple, so I'm kind of guessing in the dark.

Searching the internet for all the info I can find (mostly from blog posts of developers and beta-testers), it seemed like the culprit in my code was probably a call to CGWindowListCreateImage, so I spent some time forking the code paths in my app (since I still support back to 10.15) to use the more modern ScreenCaptureKit APIs on systems that support it. But the alert is still appearing, despite not calling into that API at all.

Is there a way of calling the modern ScreenCaptureKit APIs that also triggers this alert? As an example, I'm using a snippet like this to get the shareable displays I need

do {
  try await SCShareableContent.excludingDesktopWindows(
    false,
    onScreenWindowsOnly: false
  )
  return true
} catch {
  return false
}

is it possible that this code is triggering the alert because I'm not excluding desktop windows and asking for all windows?

to sum up, I (and I'm guessing others) could really use some definitive guidelines on exactly which APIs trigger this alert, so that we can migrate and avoid them if possible. can anyone provide any guidance on this? Thanks in advance!

Answered by DTS Engineer in 806962022

Right. I do see that alert with my code. I missed this yesterday because it only shows up when you click the Test button for a second time. So the first click generates the alert from my post and the second click, which is the one that’s actually going to return real data, returns the alert from yours.

AFAIK there are two ways to avoid that alert:

  • Via the Persistent Content Capture (com.apple.developer.persistent-content-capture) entitlement. As noted in the docs, this is specifically intended for screen sharing products.

  • Present the system picker UI, SCContentSharingPicker. This lets the user choose what they want your app to access on a case-by-case basis.

Apple has received a lot of feedback about this new restriction, from both developers and users. If neither of the above work for your product, I encourage you to file your own feedback describing your specific use case.

Please post your bug number, just for the record.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

But the alert is still appearing, despite not calling into that API at all.

Hmmm, I need to be clear about what alert you’re talking about. Consider this snippet, which captures a screenshot of the main display:

@IBAction
private func testAction(_ sender: Any) {
    Task {
        do {
            print("will capture")
            let sc = try await SCShareableContent.current
            
            guard let display = sc.displays.first else {
                print("did not capture, no  display")
                return
            }

            let filter = SCContentFilter(display: display, including: [])
            let image = try await SCScreenshotManager.captureImage(contentFilter: filter, configuration: .init())
            print("did capture, image: \(image)")
        } catch {
            print("did not capture, error: \(error)")
        }
    }
}

When I run this code on macOS 14.6.1, I got this alert:

“Test765103” would like to record this computer's
screen and audio.

Grant access to this application in Privacy & Security
settings, located in System Settings.

[Open System Settings] [[Deny]]

When I run it on macOS 15.0, I get exactly the same alert.

Is this the alert that concerns you?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks so much for taking the time to reply.

The alert you quoted is not the one I'm concerned about, I have no problem with an initial system prompt to grant access. The alert that is concerning me is the one that says:

"SomeApp" is requesting to bypass the system private window picker and directly access your screen and audio. This will allow SomeApp to record your screen and system audio, including personal or sensitive information that may be visible or audible.

Which then shows to options: "Allow for one month" and "Open System Settings". Here's a screenshot:

After my initial post yesterday, I created a brand new macOS app to try to get a minimal reproduction. I started a new project with Xcode, and only made changes to the generated ContentView.swift file as shown below, and I get the same alert about "bypassing" and recording audio. Here's the code:

import ScreenCaptureKit
import SwiftUI

struct ContentView: View {
  var body: some View {
    VStack {
      Image(systemName: "globe")
        .imageScale(.large)
        .foregroundStyle(.tint)
      Text("Hello, world!")
    }
    .task {
      guard let shareable = try? await SCShareableContent.excludingDesktopWindows(
        false,
        onScreenWindowsOnly: false
      ) else {
        return
      }

      for display in shareable.displays {
        let image = try? await SCScreenshotManager.captureImage(
          contentFilter: SCContentFilter(
            display: display,
            excludingApplications: [],
            exceptingWindows: []
          ),
          configuration: SCStreamConfiguration()
        )
      }
    }
  }
}

This shows me that it's not that I'm using a deprecated API that produces this misleading alert, it's something else, and I'm looking for clarity and documentation on what causes it, and how it can be avoided.

To be clear, the alert is only on Sequoia, and it should be reproducible with the code above.

Again, really appreciate the help!

Accepted Answer

Right. I do see that alert with my code. I missed this yesterday because it only shows up when you click the Test button for a second time. So the first click generates the alert from my post and the second click, which is the one that’s actually going to return real data, returns the alert from yours.

AFAIK there are two ways to avoid that alert:

  • Via the Persistent Content Capture (com.apple.developer.persistent-content-capture) entitlement. As noted in the docs, this is specifically intended for screen sharing products.

  • Present the system picker UI, SCContentSharingPicker. This lets the user choose what they want your app to access on a case-by-case basis.

Apple has received a lot of feedback about this new restriction, from both developers and users. If neither of the above work for your product, I encourage you to file your own feedback describing your specific use case.

Please post your bug number, just for the record.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Quinn, once again, thanks for the reply and the detailed response.

I didn't know about the Persistent Content Capture entitlement, thanks for that link. However, my app does not meet the criteria, it's not a remote-control app, so I can't apply for that entitlement without lying about the purpose of the app, which I'm not willing to do.

The second workaround is not possible either, the entire purpose of the feature is to capture the entirety of all displays and all windows, so presenting a case-by-case picker would be inappropriate, frustrate the user, and kill the desired functionality.

I'm hopeful Apple will reconsider it's position here. I understand wanting to protect naive users from security risks, it's an admirable goal. But this seems like the wrong approach, and there are many use cases where this hinders the real goals of users. I'll file some feedback and comment back with the bug number.

update: https://feedbackassistant.apple.com/feedback/15360079

help with "App is Requesting to Bypass System Private Window Picker" alert
 
 
Q