@Xinto As a workaround, when this happens to me, I use this command to try to clear the archived copies from the LaunchServices database: /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -R -f -u ~/Library/Developer/Xcode/Archives I've been using it in macOS 26.x, but haven't tested it in macOS 27.

What if you run the delete command without sudo? If simulators are per-user, I'd imagine that'd be a problem since root probably does not own the simulators you are looking at.

Based on what I've seen via a debugger, the process spawned to probe resources is separate from the process(es) spawned to manage each container you mount. I've just been treating those idle processes similar to how I would an idle on-demand launch agent or launch daemon which is able to terminate when it's inactive. That is, I ignore it since the system should manage their lifecycle and the process should use very little resources on idle, but I don't depend on them staying alive for any specific period of time (as maybe the behavior could change in some OS update). Maybe an Apple employee can give a more definitive answer, but I'd be surprised if this weren't intentional, as if a user mounts many volumes in close succession, there would be worse performance for no reason if the probing process had to constantly be relaunched and initialized again for each request. In any case, on my own system, I've definitely used my FSKit extension since I last rebooted my machine, but I no longer see any running processes related to that extension. So it does seem that the process is going to terminate on its own eventually, although I don't know the exact criteria for that.

Is the way you're determining that removeItem isn't being called simply looking for the logged line in Console and not seeing it? I see the original code uses logger.info("remove: \(name)") and the info level doesn't appear in Console by default when streaming live logs. It might simply be that the function is actually being called but Console just isn't showing the message. You should make sure that Console > Action > Include Info Messages is selected, or use logger.log/a more severe log level instead.

You might just create a random UUID on first launch and store it somewhere on the device, writing it alongside each record. Or you could use identifierForVendor which should be the same across multiple apps by you (subject to the limitations in the docs), if that is important for this purpose.

[quote='832420021, justinfrombaldwinsville, /thread/832420, /profile/justinfrombaldwinsville'] Also why not record the group labs [/quote] They're already available on YouTube! https://www.youtube.com/@AppleDeveloper/streams

and NEVER once has anyone posted a follow-up that they had the issue resolved. I don't know if the file system engineers are really able to say much about this, but I was curious and found a counterexample where someone solved it via support by searching for "apple notarization error 7000" in the top 3 results (though not on these forums): https://github.com/orgs/tauri-apps/discussions/8630#discussioncomment-12314090

@Systems Engineer made FB23036790, thanks!

@Systems Engineer looks like Feedback Assistant is back up, so I made FB23036931 regarding this Thanks to both of you for the answers!

Just for the record, I'll put the response I got on FB22525990 here: Please [k]now that this is an intentional behavior for the compiler. If there is a witness to the protocol requirement, then it needs to be as available as the requirement. Just dropping the availability constraint because the requirement is optional could easily lead to surprise for other developers, where they think they are witnessing a requirement but actually aren’t.

@ben_roeder I don't think that is the same issue as what was originally described, and I'm not Apple, but I have seen something similar, although I reproduced it after rebuilding the app with Xcode (FB22516139). Maybe this is what you're hitting. I checked the status on my feedback about that and it says a fix is coming in a future OS update, although I'm not sure specifically which beta version, if any, currently has the fix.

[quote='885813022, DTS Engineer, /thread/824156?answerId=885813022#885813022'] Some of the information here may already be obvious or well understood to you. [/quote] Thank you for taking the time to write all this down. That context is very helpful, especially as I'm not super familiar with the lower level Unix APIs related to this. [quote='885809022, DTS Engineer, /thread/824156?answerId=885809022#885809022'] I don't think that's a safe assumption and, in practice, I think you're very likely to see lots of cases where a lookup ISN'T generated. I don't think a basic "ls" will generate a lookup call and I'd expect/hope the Finder would avoid it at least some of the time. [/quote] Both of those expectations don't The second expectation doesn't seem to be what happens in reality, at least on macOS 15.7.5. I've been testing with a sample file system that has a directory with 10,000 items. When I do a time ls /Volumes/MyFS/dir, I see that a lookupItem call was done for every single item (actually, 2 for each item, e.g. one for file1.txt and another for ._file1.txt, which doesn't exist). And if I open /Volumes/MyFS in the Finder, then it immediately goes wild at making lookupItem calls to the thousands of items in the /Volumes/MyFS/dir before I even open dir (although, I do have the "calculate all sizes" view option enabled in the Finder; when I turn that off, it at least waits until I open dir). Edit: OK, actually, it seems like my shell has added extra stuff to a "default" ls call... it's probably oh-my-zsh or something. When I run it in a plain bash shell, a regular ls doesn't make all those lookup calls. But it also doesn't ask for any of the heavy attributes that lead to my codepath that can instantiate the FSItem object, so that specific case doesn't lead to a leak in my code. These operations (the ls and opening the big folder in the Finder) are really slow, and while a lot of it seems to simply be FSKit overhead (FB21069313), I'm currently trying to optimize my own code to avoid some of the bottleneck on my side. I guess, writing this down, it really looks like the "FSKit overhead" might be the tons of lookupItem calls... so if that's not intended behavior, then yeah, sounds like my assumption wouldn't work and I should be trying to figure out when to prune these objects. [quote='885809022, DTS Engineer, /thread/824156?answerId=885809022#885809022'] That bottleneck either provides the cached object it already has or creates a new object (adding it to the cache) if it doesn't have one, ensuring that there is never more than one object for any given file system object. [/quote] Yeah, I've currently got something like that. I'm currently relying on reclaimItem calls to know when to release my hold on the object from the bottleneck, but I was recently reading my code again and realized that I might be never reclaiming it if the system never actually receives the item! Hence I came to the forums to ask this, to see if this is actually a problem or not. [quote='885809022, DTS Engineer, /thread/824156?answerId=885809022#885809022'] First off, as background context, I have a post on this here which is worth reading. [/quote] Oh hey, that's an answer to one of my previous questions :) [quote='885809022, DTS Engineer, /thread/824156?answerId=885809022#885809022'] As a block storage file system, one thing you should be looking at/planning is to transition to FSVolumeKernelOffloadedIOOperations and away from FSVolumeReadWriteOperations. [/quote] Got it. I do have that implemented, although right now I'm rejecting any request that contains the write flag. I also don't have any of the supporting write functionality (creating files, changing attributes, etc.) done, which is probably going to be the hard part with that.

[quote='885683022, DTS Engineer, /thread/824156?answerId=885683022#885683022'] my expectation would be that iterating the directory with "geattrlistbulk" and a minimal attribute set would avoid any additional lookupItem call [/quote] Oh, I think I was a little unclear in what I wrote. What I was trying to say in "a call to enumerateDirectory of this nature" was that if I call enumerateDirectory with a non-minimal attribute set (i.e. include attributes that need more I/O to fetch) then I see that behavior. But you're right in that iterating over a directory with minimal attributes doesn't generally have additional lookupItem calls in my tests. [quote='885683022, DTS Engineer, /thread/824156?answerId=885683022#885683022'] What kind of filesystem are you working with? [/quote] It's a block device file system. I think maybe "cached data" wasn't the best word for me to use... I'm referring to references I'm keeping to instances of my subclass of FSItem. I have a helper function implemented on my subclass to get the "non-minimal" attributes, so what I'm doing in my enumerateDirectory implementation is checking if I have a reference for the item already, and if so, I simply use that and its helper method. If not, I create a new instance of the FSItem, then proceed. (If there are only minimal attributes that don't need any more I/O requested, then I don't do anything with these FSItems.) My question is more so, if I'm creating a new FSItem in enumerateDirectory like that (for the purpose of getting those "non-minimal" attributes), can I assume a lookupItem call is going to follow, and thus giving the system a chance to later reclaim that FSItem? Or should I be throwing away my reference to the FSItem if I created it inside enumerateDirectory? It seems like it would be a bit wasteful if I threw away an FSItem made in the enumerateDirectory call if I know there's going to be a lookupItem call shortly after asking for it, although I don't see a guarantee that that would be the case. [quote='885683022, DTS Engineer, /thread/824156?answerId=885683022#885683022'] That's particularly true on macOS where your I/O is page oriented, so the minimum cache unit is 16Kb (one page). [/quote] Oh? Does this mean it's not good to pass lengths smaller than 16KB to e.g. metadataRead, and what its docs are referring to when they say "This method doesn’t support partial reading of metadata?" It's often the case that I've been using 4KB, and things seem to run fine, although right now I only have reading implemented, so I don't know if that causes a problem later if I implement write.

Thanks, Quinn and Kevin! I was going to see if I can do a full test of this before I make a release with requestedMountOptions included, but it looks like the availability version has been updated, so I think it's going to be a moot point by the time macOS 26.5 releases. In any case, interesting read as always.

You might also want to try reporting this at https://security.apple.com/reports, which has an option to report malware/phishing. I've never reported malicious App Store/TestFlight builds there, but in my experience filing other types of security bugs there, you often get more info about what is happening to your report and/or a better chance of a response than you do with Feedback Assistant.