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

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!

I'm interested in the same thing. Deprecated APIs let me get a single screenshot that spanned multiple displays, and the resulting image stitched them together in their appropriate size and relation to each other. Seems like with ScreenCaptureKit, I have to take an image of each display individually, and if I want the composite image, I'd need to stitch it together myself? Can anyone comment on this?

@eskimo - thanks for this tech note! On the table in the section labeled "Deploying a content filter provider", there is a row stating that starting in iOS 15, these can be deployed as an app extension with the restriction of "Screen Time apps". I can't figure out what this means. Can you elaborate? Specifically I'm trying to determine if an NEFilterDataProvider can be installed on iOS outside of a MDM supervised/managed device, on a normal user device protected by Screen Time. The use case is not a large organization, school or enterprise, but is it possible to make an app that filters network content that parents can install on their kids device which is managed via Screen Time? Is there any documentation you can link to for this use case? Thanks so much!

@ilis544 I finally got a reply back from DTS, and they provided a working solution. Here's the relevant part, for you and future googlers - I can confirm the workaround mentioned below fixed the issue for my app: "This isn’t due to a bug with Swift Concurrency, but a side-effect of how System Extensions work, with an easy solution. Your intuition about a simple test case with the Simple Firewall sample project was correct, so I was using that project built with Xcode 14.3.1 and testing on macOS 11.4 to reproduce and test solutions. Speaking generally of Swift Concurrency, when an app is built with Swift Concurrency code that needs to back deploy, Xcode detects this and deploys the library supporting back deployment to a standard location inside of the app bundle so that any binary inside of the app bundle can refer to that singular copy of the library. This library is weakly linked, which means that at process launch, if the system doesn’t locate the library in one of the standard locations, the system doesn’t abort the process launch due to a missing library. In the crash here, the top frame is: 0 libswiftCore.dylib 0x00007fff2cdacdc7 swift::ResolveAsSymbolicReference::operator()(swift::Demangle::__runtime::SymbolicReferenceKind, swift::Demangle::__runtime::Directness, int, void const*) + 55 This is the Swift runtime failing to locate a symbol it needs for a some code that is executing, including in other scenarios outside of Swift concurrency. While there have been real issues that Apple has addressed with Swift Concurrency that have this frame in the crash report, what happened here is that the system couldn’t locate the Swift Concurrency symbol because we never loaded the library, because the system couldn’t find it. Since the library is weakly linked, this wasn’t a crash on launch. System extensions are unique compared to other types of extension points because the copy inside your app is inert and not executed. When the system extension activates through the user consent process, macOS copies it from your app to a location under /Library/SystemExtensions, and then executes this copy. When the system extension process launches, the search mechanism to locate the Swift Concurrency back deployment library doesn’t find it, because the library is in a shared location inside of your app bundle but outside of the system extension files are are copied. There is no mechanism for connecting the copied system extension back to its original copy inside the app for this library loading purpose, so there is no way for the system to locate the library inside of the original app bundle. The solution here is two build settings on the system extension target: Set ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES to Yes. This will copy the Swift Concurrency library into the System Extension during the build. This means there will be two copies, one in the standard location for the app for any concurrency needs in your app code, and a second copy inside the system extension for its own needs. Ensure that LD_RUNPATH_SEARCH_PATHS is not overridden. It should have its default value of $(inherited) @executable_path/../Frameworks @executable_path/../../../../Frameworks. This second build setting is to make sure that Xcode inserts /usr/lib/swift into the right place in the search path list the system uses to locate libraries, so that on newer systems which have the Swift Concurrency library built into the macOS, your app uses that copy instead of the back-deployment library. To confirm the search list order on your system extension, you can run otool -l, and ensure that /usr/lib/swift is listed first of the multiple LC_RPATH entries."

@Polyphonic thanks, I appreciate the reply, truly. So are you saying that 17+ days between responses is expected considering the busy period DTS is experiencing? Are other developers waiting that long as well?

@eskimo @ilis544 I guess I can also add this: since I first posted this, I modified my filter-side network extension code to remove every single async await (basically to be an empty FilterDataProvider), and rebuilt, notarized, and tested on Big Sur -- no crash. Then I added one single Task { ... } and tried again, it immediately crashed. So I'm pretty much totally confident it's a swift concurrency back deployment issue. I told the TSI engineer that I'm almost certain they could repro using the SimpleFirewall sample app from "Filtering Network Traffic". All they'd need to do is add a single Task with an os_log or something, build in release mode, and test on a machine running Big Sur.

I can’t say whether jaredh159 opened a TSIs for this; if they did, it’d be nice if they could post a summary of their conclusions here. I did open a TSI, but because of WWDC and some personal time off, not much progress has been made yet. The only thing notable so far is that I was asked to retry with Xcode 14.3.1 (I had been on 14.2, because I hadn't upgraded to Ventura). I did retry with 14.3.1, but the same crash manifested the exact same way. Still waiting for a response to that. I'll update this thread if there's anything useful I find out.

@eskimo -- you're the master of arcane, scantily documented, dusty corners of the OS, and working magic with obscure C apis. any thoughts/help here?

for what it's worth, the most helpful article i've found on this topic is here: https://scriptingosx.com/2020/02/getting-the-current-user-in-macos-update/

@Claude31 Thank you very much, that was my issue.

Also running into this problem, with a React Native project that compiles fine in Xcode 12. Is this a Swift 5.5 change? An Xcode 13 issue?

This is driven by the right specification. You’re getting generic text because you’re using kAuthorizationRuleAuthenticateAsAdmin, which is what I’m trying to steer you away from. If you use a custom right you can customise this. Aha, yes, that makes sense. Really appreciate it, thanks!

@meaton Thanks for this, I appreciate it. I'm still struggling to implement this. I'm having a hard time finding ANY documentation for audit_token_to_ruid, so I'm fumbling in the dark a bit here. I did find this thread - https://developer.apple.com/forums/thread/122482, and so I'm trying code like this: swift private func auditTokenT(_ token: Data?) - audit_token_t? {  guard    let token = token,    token.count == MemoryLayoutaudit_token_t.size   else { return nil }      return token.withUnsafeBytes { buf in    buf.baseAddress!.assumingMemoryBound(to: audit_token_t.self).pointee  } } /* ... */ let token = auditTokenT(flow.sourceAppAuditToken) /* `flow` is a NEFilterFlow */ let ruid = audit_token_to_ruid(token) With this code, Xcode is not showing any compiler errors or warning, but when I try to build I get: Undefined symbol: _audit_token_to_ruid I tried importing Darwin, Darwin.bsm, but no dice. Do I have to do something special for this function to be available? If so, would you mind explaining what it would be?

Ok, so in addition to what eskimo posted above, the below seems to be working using the higher-level SFAuthorization class, although it seems to be less configurable (for instance I don't think you can change the message "Your App wants to make changes"), so YMMV: swift func authenticateAsAdmin() - Bool { guard let authorization = SFAuthorization.authorization() as? SFAuthorization, let right = NSString(string: kAuthorizationRuleAuthenticateAsAdmin).utf8String else { /* or maybe throw an error */ return false } do { try authorization.obtain(withRight: right, flags: [.extendRights, .interactionAllowed, .destroyRights]) } catch { return false } return true } Furthermore, I figured out that one of my problems was I forgot to check if my app was in sandbox mode, in which case these API's don't work and you only get vague permission denied errors.