I just discovered xcresulttool - provided with the Xcode Command Line Tools. It does an amazing job generating a JSON report of warnings/failures. The tool requires a xcresult file path - my issue is that xcodebuild build does not produce an xcresult file so I can't find a way to generate a similar report for that action. My use case is simple - in my CI job, I want to report back on specific failures during builds and tests. I run xcodebuild build-for-testing and then later xcodebuild test-without-building. If there is a failure during the test phase, I can easily parse the issues from the JSON report in xcresult. However, if there is a failure during build, there is no result file to parse from. What is more confusing is that if you run xcodebuild test (build and test in one command) compilation errors are put in the xcresult file and you can read them just fine with xcresulttool. Is there any way to get a failure report from xcodebuild build actions without parsing stdout/stderror? I am aware of 3rd party tools such as xcpretty or xcbeautify - I would like to avoid anything that requires parsing the output.

Looking for a dynamic table that displays the latest supported CLI versions with the version of macOS. Specifically, is CLI 15.3 supported on Ventura 13.7.8? More generally, what is the lastest version of CLI supported on macOS <version_goes_here>

With the latest (26) version of Apple's developer tools, is there a way to manually attach a debugger (other than lldb) to an iOS app launched with "devicectl device process launch --start-stopped"? In the past, this was possible via the ios-deploy third-party tool (now defunct), which provided a debugserver port. This information is notably missing when using devicectrl – although the process ID of the launch process is provided, and the tool is clearly aimed at letting you launch and attach to processes from the command line. lldb can, of course, attach via its built-in support for this using the device set of commands. But I'm explicitly looking for a way to attach my own debugger via the GDB-compatible debug proxy.

After upgrading to macOS Tahoe 26.0.1, I encountered an issue where the debugger could no longer display standard C++ library types such as std::map, std::string, and other std:: containers. Instead, the debugger simply showed: Summary Unavailable 🧪 What I Tried • Switched from the default LLVM compiler to GDB to check if it was a debugger-related problem — no improvement. • Cleaned and rebuilt the project — the issue persisted. ✅ Solution Downgrading Xcode to version 16.4 immediately resolved the issue. According to Apple’s official Xcode support documentation, Xcode 16.4 is compatible with macOS Sequoia 15.6 and later, which includes macOS Tahoe 26.0.1. This suggests that the problem may be caused by a compatibility issue in the latest Command Line Tools bundled with newer versions of Xcode. 💡 Takeaway If you encounter the same problem: 1. Try downgrading to Xcode 16.4 or reinstalling the corresponding Command Line Tools. 2. Make sure your debugger (LLDB or GDB) is correctly linked to the appropriate SDK version. Hopefully this helps anyone experiencing the same issue!

Opened a FB already (FB20928652) but wanted to check here if anybody has seen similar or has better workarounds. xcresulttool merge appears to crash immediately after launch in Xcode 26.1 (and in 26.2b1). It does so regardless of any inputs passed in; the crash appears to be during argument parsing before any other logic is run, so it's not contingent on inputs. Working example from 26.0.1 (passing in arbitrary strings for a minimum-reproducible-case, so we expect to see an error message) : % /Applications/Xcode-26.0.1.app/Contents/Developer/usr/bin/xcresulttool merge --output-path a b c Error: File or directory doesn't exist at path: b. Usage: xcresulttool <subcommand> See 'xcresulttool --help' for more information. The same example crashes in 26.1: /Applications/Xcode-26.1.0.app/Contents/Developer/usr/bin/xcresulttool merge --output-path a b c zsh: trace trap /Applications/Xcode-26.1.0.app/Contents/Developer/usr/bin/xcresulttool merge Again, this does crash in real use cases as well, the arbitrary strings are just for quick reproduction. The stack trace appears to be during argument parsing (which from a quick look, did indeed change between 26.0.1 and 26.1). On 26.1+, garbage data seemingly gets passed to AbsolutePath.init. * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 * frame #0: 0x00000001002c6748 xcresulttool-26.1`normalize(absolute:) frame #1: 0x00000001002c6438 xcresulttool-26.1`AbsolutePath.init(_:) + 28 frame #2: 0x000000010005a2c0 xcresulttool-26.1`Merge.run() + 372 frame #3: 0x000000010005b180 xcresulttool-26.1`protocol witness for ParsableCommand.run() in conformance Merge + 12 frame #4: 0x000000010011d3e4 xcresulttool-26.1`dispatch thunk of ReadableStream.close() + 16 frame #5: 0x000000010000148c xcresulttool-26.1`main + 156 frame #6: 0x00000001804d5d54 dyld`start + 7184 The only workaround we've found is to keep using 26.0.1's copy of xcresulttool, though that's obviously not ideal.

On macOS Tahoe 26 activating GUI apps from command-line often fails. It launches the app but not brings to the foreground as expected. For example, running the following commands in Terminal is expected to launch Pages and bring it to the foreground. open /Applications/Pages.app or osascript -e `tell application "Pages" to activate` Moreover, they sometimes not return in Terminal. These commands worked as expected until macOS 15 but no more in macOS 26. The tricky part is that this failure doesn't happen 100% of the time; it occurs randomly. However, since multiple users of my app have reported the same symptoms, and I can reproduce it not only with my app but also with apps bundled to macOS, I don't believe this is an issue specific to my environment alone. I’ve already filed this issue: FB21087054 Open version: https://github.com/1024jp/AppleFeedback/issues/87 However, I’d like to know if any workaround exists or my understanding is wrong, especially for case with osascript.

Just recently, any pkg file that I create with pkgbuild will install the Payload's application as a zero-byte file in the /Applications directory. This has been working for years without issue for me. Here are the commands I am using with company specific items replaced: pkgbuild --analyze --root MyApplicationRootDirectory standalone.plist plutil -replace BundleIsRelocatable -bool NO standalone.plist pkgbuild --identifier MyIdentifier --version 1.0 --install-location /Applications --root MyApplicationRootDirectory --component-plist standalone.plist --sign 'Developer ID Installer: MyCompany (MySignId)' --timestamp installer.pkg Any ideas on what could be causing the issue? I have verified the following: The application being added to the pkg is both signed and notarized using the correct Developer ID Application certificate. The resultant pkg file is both signed and notarized using the Developer ID Installer certificate. Verified the pkg contents using "pkgutil --expand" to dump the contents. Verified the pkg's Payload contents by extracting the data using "cat Payload | gunzip | cpio -1". This results in an application file that is a binary match for file added in the "pkgbuild --root" argument. My application is the only file within the directory passed to the "pkgbuild --root" argument. There are no warnings in the System Settings / Privacy & Security Panel when running the package installer. I have a valid Mac Developer account. I am building the application and the pkg file on the same computer. Thank you for any insight.

I'm trying to manage multiple Command Line Tools versions side-by-side (e.g., 16.2 and 26.2). I renamed the CLT directory to /Library/Developer/CommandLineTools-26.2.0 and set: xcode-select -s /Library/Developer/CommandLineTools-26.2.0 or DEVELOPER_DIR=/Library/Developer/CommandLineTools-26.2.0 Both result in: c++: error: unable to find Xcode installation from active developer path "/Library/Developer/CommandLineTools-26.2.0" It appears CLT only works at the fixed path /Library/Developer/CommandLineTools, unlike Xcode which can be at any location. Is this by design? Is there a supported way to use multiple CLT versions in parallel, similar to how multiple Xcode versions can coexist?

Prior to iOS 26.0 we were able to download specific simulator runtimes from the command line by using a command like xcodebuild -downloadPlatform iOS -buildVersion 18.0 This is described in the documentation here. This no longer works for 26.x. If I run the following command: "xcodebuild -downloadPlatform iOS -buildVersion 26.0" it fails with the following error: "Finding content... iOS 26.0 is not available for download." If I omit the -buildVersion flag it will download the latest version, currently 26.2, but if I try and specify 26.2 as the buildVersion I still get "iOS 26.2 is not available for download". This behavior has been confirmed on Xcode 26.2. Perhaps related, it appears these runtimes are also no longer being made available for download on https://developer.apple.com/download/all

I am using macOS’s /bin/date command, both in Terminal and via AppleScript (do shell script). I noticed inconsistent behaviour with the %N format specifier for nanoseconds: • On some Macs, date +%s%N returns numeric nanoseconds as expected. • On other Macs, the same command returns a literal N or fails when coerced to a number. • This occurs across different macOS versions and on both Intel and Apple Silicon machines. My understanding is that macOS ships BSD date, which does not officially document %N. I am trying to determine: 1. Is %N in /bin/date officially supported on macOS, and if so, on which versions? 2. If %N is not supported, what is Apple’s recommended, portable method for obtaining sub-second or millisecond timestamps in shell scripts or AppleScript across all macOS versions?

I have an orphaned asset folder taking up 9.13GB located at: /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime/c0d3fd05106683ba0b3680d4d1afec65f098d700.asset It contains SimulatorRuntimeAsset version 18.5 (Build 22F77). Active Version: My current Xcode setup is using version 26.2 (Build 23C54). I checked the plist files in the directory and found what seems to be the cause of the issue: The "Never Collected" Flag: The Info.plist inside the orphaned asset folder explicitly sets the garbage collection behavior to "NeverCollected": <key>__AssetDefaultGarbageCollectionBehavior</key> <string>NeverCollected</string> The Catalog Mismatch: The master catalog file (com_apple_MobileAsset_iOSSimulatorRuntime.xml) in the parent directory only lists the new version (26.2). Because the old version (18.5) is missing from this XML, Xcode and mobileassetd seem to have lost track of it entirely. What I Have Tried (All Failed) Xcode Components: The version 18.5 does not appear in Settings -> Components, so I cannot delete it via the GUI. Simctl: xcrun simctl list runtimes does not list this version. Running xcrun simctl runtime delete 22F77 fails with: "No runtime disk images or bundles found matching '22F77'." Manual Deletion: sudo rm -rf [path] fails with "Operation not permitted", presumably because /System/Library/AssetsV2 is SIP-protected. Third-party Tools: Apps like DevCleaner do not detect this runtime (likely because they only scan ~/Library or /Library, not /System/Library). Has anyone found a way to force the system (perhaps via mobileassetd or a specific xcrun flag) to re-evaluate this folder and respect a deletion request? I am trying to avoid booting into Recovery Mode just to delete a cache file. Any insights on how AssetsV2 handles these "orphaned" files would be appreciated.

I'm trying to authenticate to a git host using SSH keys stored in 1Password. I have ~/.ssh/config with mode 600 set with a symlink: Host * IdentityAgent "~/.1password/agent.sock" But ssh-add -l shows no identities. If I set $SSH_AUTH_SOCK, ssh-add -l works just fine. I'd love to not have to do this, though. Why doesn't ssh-add seem to read ~/.ssh/config? The built-in version is OpenSSH_10.0p2, LibreSSL 3.3.6. I've searched fruitlessly for an answer anywhere else.

After having built the SwiftUI project numerous times from Xcode and allowing the plugins after the first build post install using xcodebuild -scheme <SchemeName> build fails with: The following build commands failed: Validate plug-in “SwiftLintBuildToolPlugin” in package “swiftlintplugins” Validate plug-in “OpenAPIGenerator” in package “swift-openapi-generator” How are we supposed to grant the plugins permission to run in the CLI? Everything I'm getting from Gemini is for packages, not apps.