We need guidance regarding the Python runtime bundled with Apple Command Line Tools. Environment: macOS Tahoe 26.5.2 (25F84) Xcode 26.6 (17F113) Device type: Mac Command Line Tools Python path: /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/ Version confirmed locally with: /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/bin/python3 --version Output: Python 3.9.6 Our vulnerability-management platform, Qualys, reports this Apple Command Line Tools Python runtime as vulnerable under QID 387170, referencing CVE-2022-4303 and CVE-2023-0286. The detection points to: /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/Resources/Python.app My understanding is that this runtime is bundled and managed by Apple as part of Command Line Tools, and that manually replacing or modifying this framework is not a supported remediation path. Installing a separate standalone Python version also does not remediate the finding at this Apple-managed path. Could Apple or the community confirm the supported approach for this scenario? Specifically: Is Python 3.9.6 intentionally bundled with the current Command Line Tools release for this macOS/Xcode version? Has Apple applied security fixes or backports to this bundled Python runtime that are not reflected in the upstream Python version number? Is updating Command Line Tools/Xcode the only supported remediation method for this component? Is manually replacing or modifying the bundled Python framework unsupported? Is there any known mitigation or official guidance for vulnerability-management exceptions while waiting for an Apple-provided update? I have also filed this through Feedback Assistant: FB23893693. Any official Apple guidance or reference to existing documentation would be very helpful, as we need to provide an auditable response to our internal security and audit teams.

Using rvictl with iOS 27 beta3 doesn't work anymore. RVICTL reports a successful creation of the remote virtual interface, but the interface rvi0 fails to spawn. rvictl -s Starting device [SUCCEEDED] with interface rvi0 rvictl -l Could not get list of devices iPhone 16 pro iOS 27 Beta3 macOS 27 Xcode 27 beta Confirmed that the command still works on iOS 26.6 on an iPhone 15 Pro.

Hi Team, If I want to create a command line app in swift which needs to be invoked using sudo, will I be able to sandbox this app?

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.

Environment • macOS 27 beta 2 • Xcode 27 beta • Apple Silicon Mac Summary After upgrading to macOS 27 beta 2 and Xcode 27 beta, an old iOS 18.5 simulator runtime remains registered internally but cannot be removed. There appears to be an inconsistency between different CoreSimulator commands. Observed Behavior xcrun simctl runtime list only reports the current runtime: == Disk Images == -- iOS -- iOS 26.1 (23B86) - 0753590B-CF3F-4944-899E-4F70698DB87C (Ready) Total Disk Images: 1 (7.8G) However, xcrun simctl list runtimes -j still reports an additional runtime: identifier: com.apple.CoreSimulator.SimRuntime.iOS-18-5 SimulatorVersion: 18.5 Build: 22F77 bundlePath: /Library/Developer/CoreSimulator/Volumes/iOS_22F77/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.5.simruntime runtimeRoot: /Library/Developer/CoreSimulator/Volumes/iOS_22F77/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.5.simruntime/Contents/Resources/RuntimeRoot The runtime is reported as: "isAvailable": true The runtime no longer appears anywhere in Xcode. Attempting to remove it using the documented command fails: xcrun simctl runtime delete 22F77 Output: No runtime disk images or bundles found matching '22F77'. No matching images found to delete Using the runtime identifier also fails. The corresponding MobileAsset still exists: /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime/ It contains: c0d3fd05106683ba0b3680d4d1afec65f098d700.asset Its Info.plist contains: SimulatorVersion = 18.5 Build = 22F77 Another asset exists for the current runtime: SimulatorVersion = 26.1 Build = 23B86 The directory /Library/Developer/CoreSimulator/Volumes/iOS_22F77 exists as an empty directory. It appears to become active only when CoreSimulator queries the runtime. The runtime asset is no longer referenced by /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime/com_apple_MobileAsset_iOSSimulatorRuntime.xml Expected Result After upgrading Xcode/macOS: • old runtimes should either be removable through xcrun simctl runtime delete or • they should no longer remain registered if Xcode has already removed them. Actual Result Different CoreSimulator commands report different runtime states. simctl runtime list only reports iOS 26.1. simctl list runtimes -j still reports iOS 18.5 as available. The old runtime cannot be deleted using the official command. The MobileAsset remains on disk and occupies storage, but there appears to be no supported method to remove it. Notes This looks like CoreSimulator's runtime registry and the runtime deletion mechanism have become inconsistent after upgrading to macOS 27 beta 2 and Xcode 27 beta.

A couple months ago, I got an error when attempting to deploy our app to App Store Connect (see error further below). I used the CLI command xcrun altool --upload-app, and I was trying to upload a new version 1.0.26 build 0, when the previous uploaded version was 1.0.25 build 2 (so the new version is definitely a higher number). I later tried to upload a version 1.0.27 build 1, and that still failed. Note that I have an identical staging app, and I was able to go from 1.0.25 build 2 to 1.0.26 build 0 just fine there. And I have never had issues with version incrementation in the past for either our production or staging app. What could be going wrong here? Here are the error logs: 2026-04-30 23:18:19.430 ERROR: [ContentDelivery.Uploader.6000012404C0] The provided entity includes an attribute with a value that has already been used (-19232) The bundle version must be higher than the previously uploaded version: ‘0’. (ID: 71a9077b-807a-476c-b8a2-04cb8357bc32) NSUnderlyingError : The provided entity includes an attribute with a value that has already been used (-19241) The bundle version must be higher than the previously uploaded version. status : 409 detail : The bundle version must be higher than the previously uploaded version. Failed to upload archive at '[MyApp].ipa'. source : pointer : /data/attributes/cfBundleVersion id : 71a9077b-807a-476c-b8a2-04cb8357bc32 code : ENTITY_ERROR.ATTRIBUTE.INVALID.DUPLICATE title : The provided entity includes an attribute with a value that has already been used meta : previousBundleVersion : 0 previousBundleVersion : 0 iris-code : ENTITY_ERROR.ATTRIBUTE.INVALID.DUPLICATE 2026-04-30 23:18:19.431 ERROR: [altool.6000012404C0] Failed to upload package. 2026-04-30 23:18:19.431 ERROR: [altool.6000012404C0] The provided entity includes an attribute with a value that has already been used (-19232) The bundle version must be higher than the previously uploaded version: ‘0’. (ID: 71a9077b-807a-476c-b8a2-04cb8357bc32) NSUnderlyingError : The provided entity includes an attribute with a value that has already been used (-19241) The bundle version must be higher than the previously uploaded version. status : 409 detail : The bundle version must be higher than the previously uploaded version. source : pointer : /data/attributes/cfBundleVersion id : 71a9077b-807a-476c-b8a2-04cb8357bc32 code : ENTITY_ERROR.ATTRIBUTE.INVALID.DUPLICATE title : The provided entity includes an attribute with a value that has already been used meta : previousBundleVersion : 0 previousBundleVersion : 0 iris-code : ENTITY_ERROR.ATTRIBUTE.INVALID.DUPLICATE

This idea is based on a few key points: GNU Coreutils has essentially become the de facto standard with the widespread adoption of GNU/Linux. Apple has been attracting modern developers by being 'Linux-like' (via POSIX-compliant), especially since Linux has largely won the race in the general-purpose Unix-like OS space. Adopting uutils would allow scripts to run much more seamlessly across macOS and Linux. uutils is compatible with GNU Coreutils, and its MIT license avoids the strict restrictions associated with GPLv3. By aligning base commands more closely with Linux, I think this would give macOS another compelling advantage over WSL2 for developers.

Hello, everyone! I've discovered a bug similar to libstdc++/115939 in GCC. This bug exists for a while. Did someone face it too? I'd be glad to accept any advise. Thank you in advance!

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?

I am running Tahoe 26.4.1 on a MacBook Air, M4, 2025. In System Settings, I have an item heading of Software Update Available. Clicking on that brings up "Command Line Tools for Xcode 26.4". The only available choices are to Update Now or Cancel. In the past, I was developing a game, but have quit working on that, and deleted Xcode and Command Line Tools. Wanting the "Command Line Tools ..." line to disappear from System Settings, I called Apple Support, and at their request have followed the steps in "https://developer.apple.com/documentation/xcode/installing-the-command-line-tools" to delete this entry in System Settings, namely the 2 sudo's in that article under the section "Uninstall the command line tools". This did not cause the "Command Line Tools for Xcode 26.4" line in System Settings to disappear (as I was told by Apple support that it would, because I would be deleting the receipt). In Terminal, I did indeed receive a response of "No receipt for 'com.apple.dt.commandlinetools' found at '/'.". I have called developer support, but the individual I spoke with had no useful guidance on how to finish this issue, except to post to the Forum. I would appreciate any guidance on how to delete the "Command Line Tools ..." entry from System Settings.

Issue - Falcon application is intermittently not detected using system_profiler command Use case - We are trying to fetch the list of installed applications on macOS using the system_profiler command. While this works for most applications, we are observing inconsistent behavior with the Falcon application — it is sometimes detected as installed and sometimes missing from the results, even though it is present on the system. This inconsistency is causing issues in reliably tracking installed security software. Command used - /usr/sbin/system_profiler SPApplicationsDataType

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.

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'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.

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?

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.

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.

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.

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>