Orphaned 9GB Simulator Runtime in /System/Library/AssetsV2 - Cannot Delete (SIP protected)

Question

Created Jan ’26

Replies 27

Boosts 16

Views 8.6k

Participants 22

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.

Screenshot 2026-01-17 at 3.34.54 AM.png

Answered by DTS Engineer in 881507022

matthewruzzi wrote:

Report a bug

Exactly!

See Bug Reporting: How and Why? for lots of hints and tips about filing effective bug reports.

Also, if you do file a bug, please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Answer 1

Novalab11 OP

Aug ’26

I filed Feedback Assistant report FB24424949 for this issue.

On macOS 26.6.2 (25G83) with Xcode 26.6 (17F112), Apple-signed simctl removed iOS 18.4 (22E238) and iOS 18.5 (22F77), but both re-registered from their SIP-protected MobileAssets after a normal restart and the CoreSimulator DYLD cache rebuilt. No manual filesystem deletion or SIP change was used.

Posting the feedback number as requested by Apple DTS so this reproduction can be associated with the existing reports.

Answer 2

Mason_Boom OP

6d

I have filed a bug report FB24870526 for this issue as well. There seemed to be no resolution to this bug in this forum besides disabling SIP (which I do not want to do.)

On macOS 27.0 (26A428) with this issue occurring on Xcode 27.1 beta (27A9269), Xcode 27.0 (27A266a) and Xcode 27.2 beta (27B5019j).

I was able to verify that even after a successful deletion of a runtime via the Xcode GUI, that "xcrun simctl runtime scan-and-mount" will repopulate the now orphaned runtimes. I assume that Xcode itself occasionally runs this command which is why the runtimes will eventually repopulate in the list.

I was also able to verify that despite xcrun simctl runtime delete [ID] succeeding and xcrun simctl runtime list showcasing the given IDs status as "Deleting" before being removed from the list when rerunning the command a moment later, that the size on disk du -sh does not change nor does the files listed under ls -alF.