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.