Thanks for the clarification. The helper (which is the XPC server in this case) is indeed the process which is the login item so I'll look into the example you sent.A couple of quick questions, though:- My app is not sandboxed. Aside from the first step in the README which won't apply to me, are there any other caveats?- Will this work when the app is first installed or anytime the helper is killed? The helper will be launched manually by the outer app and not via login items.

Ok, was having various problems with it until I started using LSRegisterURL as SMLoginItemSetEnabled wasn't launching my helper. Things seem a bit more convoluted now but at least I have a working version so I know it's possible. Not fond of "hidden" login items, preferring to have an explicit entry in the login items user interface but I guess you can't have everything.

Note that the app isn't sandboxed.Will doing 'launchctl remove' do the same as SMLoginItemSetEnabled? I have been doing that and it doesn't seem to work. Is there some cache somewhere I can ****?

Thought having a quick commandline thing I could call to fix it as needed would be more convenient. Also, just curious.Also, it seems that what triggered this recently was that a code path changed. Previously, SMLoginItemSetEnabled was being called every time to unregister before registering but that a changed mixed things up such that it wasn't always the case.Thanks.

NM. Seems like one of the answers in this thread did the trick: https://developer.apple.com/forums/thread/66418 In particular, the part about editing ~/Library/Preferences/com.apple.security.plist and removing the extra entries. codesign is now down to a second or under.

Thanks. I've filed it as FB8600589. It's unfortunate there's no workaround though. Since I need to support existing macOS versions, my only choice seems to be creating another process just for posting notifications and having it be non-XPC so I can name it something reasonable.

The next major release of my product is delayed because of this issue. And this definitely seems like a bug in the OS itself and not dependent on specific products. An OS feature has basically gone missing. Is pluginkit a valid workaround? I mean, it works, but I don't know if it's something that will be revoked without an official fix. Is there some assurance that Finder Sync Extensions are at least not being phased out and will continue to be supported? FBA #FB15300624 even if it's just a "me too" report.

Many thanks for the clarification/assurance. Admittedly, I am using it outside of its recommended use case so will file an FBA once the feature is out in production.

Thanks for the response. Seems like a weird oversight. In any case, filed FB15370199. BTW, which method would you recommend in the meantime? I suspect the scraping but wanted to double-check.

Whoops, edited my post before seeing yours. Will look into that. Thanks!

Ok, quick check and it works. Many thanks to both of you!

I'm basically monitoring everything. The files I'm interested in can be located most anywhere so I'm watching every filesystem. Most users aren't seeing this behavior so I'm trying to figure out why it's acting like this for the ones where it is happening. I don't think my bundle is set up to have any icons overridden.

To clarify, I realize I'm using things out of their recommended context, as mentioned in this thread here: https://developer.apple.com/forums/thread/756711?answerId=806555022#806555022

User reports that it's being replaced with a generic document icon. They claim it's everything in the sidebar. I'll see if they can provide a screenshot.

Icons are the generic document icon (page with bent corner). User says that after a Finder restart, all the icons are ok except for one (which one seems to change) which changes after a few seconds. Dragging a file over any of the icons changes them to a generic icon as well.