Investigating this further, I found that running screencapture -xio ~/Desktop/test.png from within the Terminal.app results in the same "Continue To Allow" loop as I'm experiencing in my app (Sequoia b4). That cannot be the desired behavior, can it (bug report filed: FB14480958)? As for ScreenCaptureKit, I am looking into it, and it does have window capturing abilities sort of reminiscent of screencapture's, but it's way clunkier, in my opinion. And it does not allow for selecting a portion of a screen to be captured (drawing a rect around the area to be captured) as far as I can tell).

Just to keep documenting this, macOS Sequoia b4 still has this same issue. It also affects Automator, and Shortcuts, when running a shell script calling screencapture in them - it won’t work.

[quote='796641022, DTS Engineer, /thread/760112?answerId=796641022#796641022'] OTOH, if you’re only seeing this with your current code that relies on the screencapture, I don’t have a great path forward for you. [/quote] I understand. So what's the best way forward for replacing screencapture's selective screenshot UI? Is there a replacement for this, some asynchronous method I could call that returns the selected screen rectangle, or the selected window ID? Or do I really have to re-implement all this myself now - and re-invent the wheel - if I want to continue to sell my app on the Mac App Store (if that is even possible with public APIs, as I don't think, just as a random example, the window-highlight I get when pressing the space bar during screencapture is publicly available)? If the latter is the case, is there a temporary entitlement I could request for my app to give me more time to develop such a UI so my app continues to function in case I can't manage to develop such a replacement in time for Sequoia?

[quote='796423022, DTS Engineer, /thread/760112?answerId=796423022#796423022'] Looking at your bug, it seems that some fixes shipped in 15.0b3. However, you indicate here that you’re still seeing the problem in b3. Is that correct? [/quote] Yes, that is correct. I've submitted a sample project with the bug report demonstrating the issue. Perhaps it's in conjunction with me using the screencapture CLI (which I use mainly for the purpose of not having to reimplement its window-selection and on-screen-crosshair-position-and-size drawing UI). Maybe it also has to do with the new System Integrity Protection for App Group containers? (can't quote the same post twice, apparently, so in reply to your: "DevForums allows you to edit a post for a short time after creating it." Oh, ok, thanks for clarifying. I just (wrongly, apparently) remembered being able to edit for longer. All good then.

the main reason I'm using the screencapture CLI is for its "interactive" area-drawing and window-selecting UI. Reimplementing this myself (highlighting windows when the space bar is pressed, drawing the selection rectangle and size/position crosshair info directly onto the screen, etc), is way out of proportion just for not using the screencapture CLI.

(Feedback ID: FB14071922) P.S.: Is editing not a thing anymore in these forums?

Alright, here's an update. It does work, after all. Just not when launched from Xcode. When you launch it manually from Finder, though, the items in the Dock's menu will show up and work. My thanks to Tom Swift over on Mastodon for letting me in on this secret.

This is what I mean, just in case I wasn't clear:

still the case on macOS 14.4b5(23E5211a)

I've submitted it to TestFlight and App Review, and as expected, it's taking a very long time in "In Review" (and very likely leading to a rejection). I hope this'll get fixed before 14.4 is released.

hm, it works when I add group.com.apple.screencapture to the XPC's App Groups, but I very much doubt it'll make it through App Review.

doesn't work when run from Shortcuts.app, either, as a "run script"

still the case in macOS 14.4b4 23E5205c

Issue still exists under macOS Sonoma 14.4b23E5196e (Feedback ID: FB13208235)

macOS 14.2 apparently has brought no fix for this.