As of macOS 26 beta 3 NSOperatingSystemVersion seems to report the major version as 26, even for apps built against the macOS 15 SDK.

I've now learned that this happens because the prev-lang:kbd NVRAM value is somehow not persisted during the initial language choice/installation. This is tracked by FB16623415 As a workaround, to get consistent behavior for automated recovery operations, doing an explicit sudo nvram prev-lang:kbd=en:-8569 before booting into recovery seems to do the trick.

@darkpaw I am a developer, and I'm using developer tools and technologies, specifically Virtualization.framework, to run macOS VMs, automating the OS installation for testing the software I develop. (You are assuming I added tags randomly, which I did not. Thanks).

Filed FB16512709

Observing UIScreenBrightnessDidChangeNotification as a proxy to the headroom updating seems to work.

[quote='806791022, torarnv, /thread/765060?answerId=806791022#806791022, /profile/torarnv'] What infrastructure would this be? I know of open, but are there others? [/quote] I tried to launch an executable with open --stdout /tmp/stdout --stderr /tmp/stderr -W ./foo --args bar baz but that doesn't seem to give the expected result: The executable is launched via Terminal.app, instead of directly (like an application bundle would have) The --args are not propagated to the executable. Presumably they are passed to Terminal.app, which ignores them (?) The executable's stdout/stderr is not written to the files. Presumably it's the output of Terminal.app that gets written to these files (?). Is there a way to launch an executable via the Launch Services APIs or otherwise, that: Passes on arguments Propagates stdout/stderr Waits for the executable to end ? Perhaps via launchctl bsexec? Or registering another application as the default handler of public.unix-executable instead of Terminal, which does the above?

Thanks Quinn! The use-case here is UI testing, but not necessarily though xcodebuild, so any magic that xcodebuild does internally to handle being launched from a SSH session would not help in the general case. The general case would be a suite of app bundles or standalone executables, launched via e.g. CTest. For example test-window-positioning.app which would be launched by executing test-window-positioning.app/Contents/MacOS/test-window-positioning and checking its exit code. [quote='806773022, DTS Engineer, /thread/765060?answerId=806773022#806773022'] Running GUI code in an SSH session is always a bad idea. [/quote] The original Technical Note TN2083 lists some cases of why running GUI code from an SSH session is a bad idea (such as not being able to interact with the Dock), but these cases seem to work fine in macOS 12-15. Do you know of any concrete cases where this will be an issue? Knowing these will help analyze the potential risk of current solutions based on SSH sessions. [quote='806773022, DTS Engineer, /thread/765060?answerId=806773022#806773022'] However, modern versions of macOS [1] provide the infrastructure that makes it possible to cross sessions, that is, starting code in the GUI session from the SSH session. [/quote] What infrastructure would this be? I know of open, but are there others?

Of course the responsible process of the test suite will be different in the two cases, either ci-agent-runner if launched via a Launch Agent, or sshd-keygen-wrapper if launched via SSH. Let's assume for this topic that the test suite is launched disclaimed, making it its own responsible process regardless of the parent process hierarchy.

The end goal is to automate UI testing in the general sense, in a way that does not result in false positives/negatives due to running in a slightly different environment than what an end user would. Most CI/CD tools (GitHub, GitLab, CircleCI, Jenkins, etc) provide some sort of runner/agent that acts as the parent process of the test suites being run (which can be implemented via xcodebuild, CTest, GoogleTest, etc.). Sometimes these runners/agents are launched as LaunchAgents, and sometimes they are running on a separate machine (host), and use SSH to run the command on the "worker node" (VM). The latter (using SSH) has the advantage that it simplifies provisioning and CI integration quite a bit. It also matches the situation when a developer is investigating a CI test failure, as they will typically SSH into the CI node and run the test there. Having the two situations run the test in a similar fashion is advantageous. So if running UI tests via SSH is close enough to what would be the environment when run via a LaunchAgent that would be great. If that's not the case, then some details on why this is problematic (in practice) would be appreciated, to be able to analyze the impact and importance of moving existing CI solutions over to a different approach. Thanks!

I have yet to find where macOS stores the state that I've extended the screen capture period by another week/month. It doesn't seem to be stored in the TCC databases. If there was a place I could adjust this programatically (with SIP) disabled, it would help a lot.

The UUID behavior is also described here https://forums.developer.apple.com/forums/thread/737416

Filed FB14587785 to track the confusing situation of the UI reflecting granted permission, while not working in practice.

Thanks Quinn! Sorry for hijacking the thread 😬

I've tried to reproduce this using the minimal sample from the Triggering the Local Network Privacy Alert, but launctrl load ~/Library/LaunchAgents/foo.plist doesn't bring up any privacy dialog. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple/DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>org.foo.test</string> <key>ProgramArguments</key> <array> <string>/Users/admin/foo</string> </array> <key>RunAtLoad</key> <true/> <key>KeepAlive</key> <false/> </dict> </plist> foo.m: https://gist.github.com/torarnv/7db4278860d06dce49179322031f8cea

Using launchctl load to load the launch agent successfully brings up the permission dialog. And accepting the permission is reflected in the Settings app for the executable. However there doesn't seem to be any change recorded in the global or user-specific TCC database (TCC.db). And the CI agent complains about not having a route to the host it's trying to reach. With Console.app reporting: runningboardd _executablePath = /Users/qt/ci-agent runningboardd Resolved pid 811 to [osservice<org.qt.io.ci-agent(501)>:811] runningboardd [osservice<org.qt.io.ci-agent(501)>:811] is not RunningBoard jetsam managed. runningboardd [osservice<org.qt.io.ci-agent(501)>:811] This process will not be managed. runningboardd [osservice<com.apple.nehelper>:179] query resolved to [osservice<org.qt.io.ci-agent(501)>:811] nehelper No team ID found for (bundleID: a.out, name: ci-agent) nehelper Got message for: ci-agent (TEAMID.a.out PID 811) nehelper Path /Users/qt/ci-agent for PID 811 matches existing rule nehelper Local network allowed by preference for ci-agent (a.out) nehelper Local network allowed by preference for ci-agent (a.out), but received prompt. Clearing cached UUIDs and restarting session. nehelper +[NEProcessInfo copyUUIDsForExecutable:]_block_invoke: failed to get UUIDs for /Users/qt/ci-agent