FinderSync extensions gone in macOS settings

We also see that our Finder sync extension does not run on its own in MacOS Sequoia. The OS should notice and load the .appex from plugins directory within the .app. But it doesn't do so. Running plug-in kit command (pluginkit -mAD -p com.apple.FinderSync -vvv) lists the extension but it is not enabled. If I manually enable it (pluginkit -e "use" -I "my plugin id") by using pluginkit command, then the plugin is loaded by OS and it runs fine.

It's been months. Does anyone care? Is there any other solution? My App can't open now. What can I do

Hello,

Just pinging to ask what has happened to this one? I expected this to be resolved before the official of Sequoia (despite seeing it not being solved in numerous betas, I still hoped the official release would change that), but it isn't. I don't see any changes in this regard in macOS 15.1 Developer Beta either.

Will this be fixed? Is there any feedback / bug report already filed? Do I need to "waste" my DTS ticket for this (although I don't see how it would change anything)?

Quinn “The Eskimo!”, can we please have an update on this?

I haven't directly tested this but, per the engineering team, apps should be able to enable a FinderSync extension by using EXAppExtensionBrowserViewController in their app to present the approval API. Once approved by the user, the extension should work the same as it has in the past.

If that doesn't work, then please file a bug and then reply with that bug number.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Kevin,

It may be I don't understand things very well and terrible state of ExtensionKit documentation doesn't help my case, but I don't think your proposal will work. I actually tried it and it didn't work, but like said, I'm not sure if I did everything right.

First of all, EXAppExtensionBrowserViewController is part of ExtensionKit, wheres FinderSync extensions have nothing to do (at least on the highest level) with that framework.

Secondly, as I understand it (and I'm not sure about it and again, terrible state of documentation doesn't help), EXAppExtensionBrowserViewController is supposed to be used to list and enable/disable extensions hosted/embedded in OTHER applications, which has NSExtensionPointIdentifier matching custom extension points declared by OUR application.

But here, we actually have problem with OUR application, which is a host/container of FinderSync extension, with NSExtensionPointIdentifier = com.apple.FinderSync. It is the responsibility of some OTHER application (defining com.apple.FinderSync extension point) to provide user interface to list and enable/disable FinderSync extensions. And that has being done by System Preferences / System Settings application, until Sequoia.

What I did:

1. I left my application, hosting a FinderSync extension, just as it is, but tried to show EXAppExtensionBrowserViewController. I got an "empty" window, just saying "Select extensions for customizing FIleUtils:" (FileUtils is my application name), without any following list of extensions (and applications hosting them).

2. I even tried something crazy, trying to declare my "custom" extension point com.apple.FinderSync in the .appextensionpoint plist file (copied during build phase into ExtensionKit Extensions destination) and then show EXAppExtensionBrowserViewController. The result was the same; "empty" window, just saying "Select extensions for customizing FIleUtils:", without any following list.

And we actually need a window, which would say Select extensions for customizing Finder:, since that's the application (declaring extension points) which our FinderSync extension (bundled into our application) wants to customize. And for that purpose we have +[FIFinderSyncController showExtensionManagementInterface], which worked fine before Sequoia.

Please let me know if I should do something similar to enable FinderSync extension using EXAppExtensionBrowserViewController. But as far as I understand how ExtensionKit works, that's not the way to go.

Anyway, I've filed a bug/request/whatever and this is the feedback reference number: FB15249290

It may be I don't understand things very well and terrible state of ExtensionKit documentation doesn't help my case, but I don't think your proposal will work. I actually tried it and it didn't work, but like said, I'm not sure if I did everything right.

First of all, EXAppExtensionBrowserViewController is part of ExtensionKit, wheres FinderSync extensions have nothing to do (at least on the highest level) with that framework.

ExtensionKit is what's actually does all of the loading and management of all extensions (including FinderSync) and my original suggestion actual came from one of their engineers. Unfortunately, yes, you're are correct that it won't work. I'm looking any other way to enable the extension but I haven't found any yet and I'm not optimistic that I'll find one.

That leads to here:

Anyway, I've filed a bug/request/whatever and this is the feedback reference number: FB15249290

Thank you. Bug reports are really important when it comes to an issues like this.

My major recommendation here is that any developers who is having issues with this file a bug and then post the bug number here. As part of that bug report, I'd recommend including the specifics of the product you're using it in, not simply the fact that it's broken. Bug reports are not simply about reporting specific issues to us, they're also (and, in this case, primarily) about documenting the problems the the bug is causing so we can properly prioritize work.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

I'm looking any other way to enable the extension but I haven't found any yet and I'm not optimistic that I'll find one.

One can use /usr/bin/pluginkit.

As part of that bug report, I'd recommend including the specifics of the product you're using it in, not simply the fact that it's broken.

I believe I gave correct and sufficient description of the problem here. There's nothing special about the "product using it", it's just an application hosting a FinderSync extension and we need a way to manage those extensions, like any others.

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.

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.

Yes and no. A few different points to be aware of:

• It's certainly not something I would assume will work "forever" and architect your app around.

• It works when through terminal or when run by a non-sandboxed app, but it will not work when launched by a sandboxed app.

• It does work today and the team is very aware that it's currently the only option on macOS 15.0. Given that reality, I expect it to continue working at least until this issue is resolved.

Is there some assurance that Finder Sync Extensions are at least not being phased out and will continue to be supported?

Finder Sync Extensions have not been deprecated and are fully supported on macOS 15.0. The issue here was entirely unintentional and primarily a side effect of other changes, not the extension point itself.

Having said that, it's also true that file sync use case FinderSync Extensions were designed address has been largely replaced by the newer (and superior) replicated file provider architecture. From that perspective, I'll say two things:

1. Cloud/File Sync applications should be moving over to the file provider, assuming they haven't already, as it's simply a "better" overall architecture.

2. If there is something that's preventing you from using file provider and/or you're using FinderSync outside of it's recommended use case, I would strongly recommend filing bugs and enhancement requests documenting what you're using it for today and what changes or improvements you'd like to see in the future. This is both to document that the technology is still useful and to help us understand how it's being used, given that it's original role has been replaced by a different technology.

FBA #FB15300624 even if it's just a "me too" report.

Thank you!

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

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.

… it's also true that file sync use case FinderSync Extensions were designed address has been largely replaced by the newer (and superior) replicated file provider architecture.

I'd like to comment on this. It's true that current documentation says:

Use this framework when you need to synchronize the contents of a local folder with a remote data source. Then provide visual feedback to the Finder…

However, the initial documentation was't that strict:

Finder Sync supports apps that synchronize the contents of a local folder with a remote data source. It improves user experience by providing immediate visual feedback directly in the Finder

The word "supports" doesn't imply a limitation (English is not my first language, so I may be wrong). I believe many other developers understood it the same as me, especially considering the fact that Finder Sync extensions provide a way to add custom menu items to Finder's contextual menu. I think most developers saw it as a sort of continuation of old CMPlugin API from MacOS (yes, the capital 'M') 8/9 days, which was available until Mac OS 10.6 Snow Leopard. It's seen as a way to extend Finder's capabilities, by executing custom operations (not limited to "synchronize the contents of a local folder with a remote data source") on files selected in Finder.

I think I know about 50 - 60 applications embedding Finder Sync extensions at the moment, and only a dozen of them actually "synchronize the contents of a local folder with a remote data source", mostly coming from huge and well known cloud providers (Dropbox, Google, Microsoft…). All others, mostly coming from independent Mac developers, offer some custom operations of files selected in Finder, nothing related to any sort of syncing. I believe MR_Noodle's case is the similar one, "outside of its recommended use case".

Taking the above into consideration, I think it'd be a huge mistake for Apple to discontinue and deprecate Finder Sync extensions without providing functionally equivalent replacement. That would break a lot of third party Mac software and render those applications completely useless. I say that because I'm starting to think that's actually going to happen. First we had "Finder Extensions" settings section missing in System Settings on Ventura (it was there in the early versions, but disappeared in the latter ones), leaving "Added Extensions" as the only place to manage Finder Sync extensions on Ventura and later. And now "Added Extensions" is missing as well. Similar actions on Apple's part in the past usually meant deprecation of technology and I'm afraid this is such case, but I really hope it is not!

I'd appreciate if this comment is somehow passed to people in charge of future development directions of macOS and that they will seriously consider what was said here. Thanks a lot!

In the meanwhile, until Apple hopefully fix the issue and put settings section back into System Settings application, if you don't want to kick-off terminal and use pluginkit, you can try FinderSyncer (https://zigz.ag/FinderSyncer - no inline link, since "This domain "https://zigz.ag" is not a permitted domain on this forums" 😐)

I have a few Finder extension apps. None of them do any kind of syncing. All of them add actions to Finder via a custom toolbar button and/or context menu items.

It's been a long time and I do remember them being introduced as "Finder Sync Extensions." At some point I thought they were renamed to "Finder Extensions." I still have a Mac running macOS Monterey and in System Preferences the section is called "Finder Extensions" not "Finder Sync Extensions."

My interpretation of this was that this was an acknowledgement that these extensions may not be related to syncing (and do not necessarily have to be related to syncing). I do hope I'm not wrong about that, being that there are so many "Finder extensions" like this on the Mac App Store that were approved.

Just to chime in as far as pluginkit goes, I have an outside the Mac App Store app that has been using this for years to re-enable a Finder extension after a software update (if the extension was enabled prior to updating) because a software update would cause the extension to automatically disable after the app was replaced (forcing the user to go back into Settings). So pluginkit in my case was needed to avoid customer support emails like "I updated the app and now the Finder extension is broken). PluginKit doesn't help Mac App Store / sandboxed apps though as already mentioned but hopefully pluginkit won't be removed because it still serves a purpose...

Far as my Mac App Store sandboxed apps go, I had them all enabled before updating to Sequoia and they still appear and work. But new customers purchasing on Sequoia can't enable them? And existing customers that had them enabled can't disable them unless they are wizards and know how to use pluginkit from Terminal?

@Macho Man ***** Savage, you can achieve all things (and much more) pluginkit does more elegantly using private NSExtension class. It works from sandboxed applications as well, but you can't distribute in the Mac App Store for obvious reasons. And when it comes to extension enabling/disabling, it's just one line of code, giving you both the boolean result of the operation and an NSError instance in case the operation failed.