@DTS Engineer Kevin, I've just installed 24C5073e and I can confirm both Finder Sync and File Provider extensions show in now joined subsection titled "File Providers". I like the new title, the previous one (in old System Preferences application) was "Finder Extensions", which was a bit confusing, since there was (and still is) a separate "Finder" subsection. [FIFinderSyncController showExtensionManagementInterface] also works, showing the correct sheet in the System Settings window. Thanks a lot for pushing this and for right satisfactory resolution! 👍🏻

@DTS Engineer Kevin, thanks a lot for eventually tracking down the submission, your intervention apparently helped to get the application approved only a few hours after I got notified about this message. I was absent during the weekend and didn't get to thank you earlier. I didn't really wanted to bother you with that, I assume you're hands are full even without me whining.I was only wondering if there is/was any way to contact the review team, while the application status is "In Review". Once again, a huge thanks for getting the approval so quickly!!!

macOS 15.1 was officially released one or two days ago. Unfortunately, but not surprisingly though, this issue (stated in the subject line of this thread) is not fixed. Finder Sync extensions setting is still missing from the System Settings application. And heaven knows if and when it will be back. Like the poster above said straightforwardly… If Apple is going to remove/deprecate, just let us know so we can stop banging our heads against the wall I'd just add, and not waste our time, effort, nerves and other resources on doomed technology. I really don't remember any Apple's API/Framework/library being treated like this by it's mother company, without any prior warning of being deprecated and stop working. I just want to mention again that my application is still in the review process on Mac App Store (MAS), ten days after the submission. After initial response that "Finder extension does not appear in the System Preferences on macOS 15" (oh really, doesn't it?!) and after I explained to reviewers the situation, pointing them to dozen resources, including FB15249290 and this thread, and also explaining how to enable/disable extensions using pluginkit, I got a response that after rejection, my application got back into "In Review" status and that… Your submission’s review will require additional time as we take this new information into account. We do not require any further information at this time. Once we have thoroughly reviewed your submission, we will either contact you in App Store Connect to communicate any issues found, or your submission will be approved. Ten days have passed since. I don't know if other developers submitting applications with embedded Finder Sync extensions experience the same. Maybe they've given up on MAS… MAS is now full of application which all of a sudden became potentially nonfunctional. I'm fully aware this is not the right place to ask this question, but I'll risk it anyway… Does anyone know if one can send messages and ping MAS reviewers while the application is in "In Review" status? There's no "Reply to App Review" option, available during "Rejected" status, only "Cancel Submission" is available.

I simply have to create another post, just to show how rather ridiculous this situation with Finder Sync extensions settings missing in Sequoia has become, just because an event triggering me to make this post happened while I was typing the other responses above. And it perfectly fits into the title (and the subject) of this discussion. So, I have an application, which embeds a Finder Sync extension. The application is distributed in three different variants: non-sandboxed, sandboxed and Mac App Store (MAS) version. When I update the application, I roll updates for all three variants (naturally, MAS version takes a bit longer to become available, due to review process). The previous update happened on September 6, 2024, before Sequoia was officially released. I had no problems with the review process, the submission was reviewed and accepted very quickly. Today I wanted to update the application, and I did so for the MAS variant as well. It was in the review process for a couple of hours, when I started typing two very long responses, which you can see above. While typing the second one, I received an email from Apple Store Connect review team, telling me that "there's an issue with my submission". And what the issue is, I will fully quite here (with some bold emphasis of my own): Guideline 2.1 - Performance - App Completeness Issue Description The app exhibited one or more bugs that would negatively impact App Store users. Bug description: Finder extension does not appear in the System Preferences on macOS 15. Next Steps Test the app on supported devices to identify and resolve bugs and stability issues before submitting for review. So now, according to the Apple Store Connect reviewer, the Finder Sync extensions settings missing from System Settings in Sequoia is a bug in MY application! I can't imagine that it can get more ridiculous than this! Or does that mean Sequoia isn't even supposed to support Finder Sync extensions and the fact they work in it is just a lucky coincidence? @Kevin, I understand that your "role is primarily about communicating with us, not bring information "back" to Apple. While you can and do work very closely with your engineering teams, that's not your primary role". But please, I would appreciate very much if you can do anything to increase the priority of this one. I think all this doesn't help either users, or developers and in retrospect, it doesn't help Apple either. And such review from qualified (I would hope) reviewer from Apple really drags down the confidence in the chosen platform to develop for (macOS) and people supporting it from the company creating and maintaining the platform. Thank you very much in advance.

Continued from the previous post… CURRENT BUGS Bug numbers? I have to admit that the current state of Finder Sync extensions work pretty well for me. The only two problems I have are inability to monitor "iCloud Drive" folder and fight over which extension shows an icon badge for files in case more extensions monitor the same folder(s) I also admit Apple was very responsive to some initial feedback I filed (not bugs, more feature requests). For example, the first version in macOS 10.10 Yosemite was very limited when it came to menu items, which extensions could provide in Finder, the menu items could have only a title and an image. On my (and probably others') suggestion, menu items got submenu, tag, indentation, state… Still, even though I reported it in early macOS 10.10 Yosemite, we had to wait until macOS 10.11 for those additions. But at least, we got them. There was also a bug (FB6006515), which happened during the transition to macOS 10.11 El Capitan, which I unfortunately noticed quite late in 10.11.3 and it was quickly fixed in 10.11.4. But I also filed a couple of feedbacks (one bug and some feature requests) and nothing has been done with them ever since. Here they are (chronologically ordered): FB5736785 - created on October 27, 2017 (seven years ago), at the time the Feedback Assistant wasn't the thing, hence recreated from the radar ID 35220999. There's a status update from November 2, 2017, saying that the issue is a duplicate of another one and hence will be closed. It was never closed, nor resolved/implemented. I pinged it twice, in August 3, 2021 (three years ago, four years after initial creation), nothing. Triggered by this discussion thread, I pinged it again on October 12, 2024, let's see if something happens this time. FB9476028 - created on August 9, 2021 (four years ago). Never received any feedback or update. Now that I understand what the original usage scope for Finder Sync extension was, I kind of understand why this doesn't work; it's about "iCloud Drive" special folder. Since Apple's own syncing extension, with a custom extension point, operates on this folder, it's kind of understandable that Apple doesn't want other extensions to mess with it. Still, it'd be nice to get a status back as closing the issue with, or making it work, now that Apple knows Finder Sync extension have much broader scope of usage ;-) FB9449243 - created on August 3, 2021 (four years ago). Never received any feedback or update. Also related to "iCloud Drive", so it's kind of understandable now why it doesn't work/ But it's be nice if it worked, now that Apple knows Finder Sync extension have much broader scope of usage ;-) FB15473186 - created on October 12, 2024. I created this one encouraged by you @Kevin, saying that we should provide as much feedback as possible to improve the current state of the matters and that all feedback will eventually be looked into. This one is just an enhancement request, for some better and more user friendly functionality of the menu items provided to Finder from Finder Sync extensions. FB15482977 - another one created on October 12, 2024, due to above mentioned encouragement. I admit this one is quite specific and it would come VERY HANDY for the product I have, but it also may help other Finder Sync developers with similar needs, which I don't know about. It concerns the case when extension wants to provide many menu items back to Finder. That may require a lot of time and cause glitches in the UI. In case those many menu items are organized hierarchically in submenus, there could be a way to avoid delay and create each submenu on Finder's request. That's it (for now ;-))

Again @Kevin, I'd like to stress how much I appreciate your feedback here. If we disagree on something, it's not a reason to turn this into a heated discussion. ABOUT DOCUMENTATION I really apologize, but I have to touch the subject of documentation once again, I promise it will be for the last time… It may very well be that I didn't get it quite right because of not being a native English speaker. Or maybe even more so because I really liked the existence of old CMPlugin (macOS 10.6 Leopard or older) and hated when it was discontinued (but I admit, it was discontinued for good reasons) that I perhaps immediately saw Finder Sync as a sort of its revival. Those things might have influenced a lot my ideas of potential usage for Finder Sync. But I still maintain that the documentation wasn't clear about its ONLY INTENDED usage (remote content/data syncing). Yes, the very first sentence of the original document says: In OS X, the Finder Sync extension point lets you cleanly and safely modify the Finder’s user interface to express file synchronization status and control. But why the "synchronization status and control" necessarily has to mean remote content/data syncing? Why can't it be, for example, synchronization and control with file's git status in the repository it resides in? Yes, later it says: The best Finder Sync extensions support apps that sync the contents of a local folder with a remote data source. Okay, I don't care about "the best" extension, I care about ones, which do the job they're intended to do. Yes, it also says: Finder Sync is not intended as a general tool for modifying the Finder’s user interface. But the very first paragraph also clearly says: Finder Sync does not add features to a host app. Instead, it lets you modify the behavior of the Finder itself. And that's what the majority of Finder Sync extensions do, they "modify the behavior of the Finder itself" by providing some additional features/operations users can invoke on files selected in Finder. I'm bragging about all this just to show that we can keep "analyzing" the language and semantics of the documentation and every person would understand it in some different way. The fact that majority of Finder Sync extensions currently available do things outside of Apple's ONLY INTENDED scope says enough about how developers understood the documentation, or even at the expense of completely ignoring the docs, where they saw extensions' best use cases. Or let's say it like you did, all those developers were creative. But the current reality is the existing scope of usage, which is much broader than Apple (apparently) originally intended it to be. So the question now is whether Apple wants to keep this ecosystem of "wrongly used" Finder Sync extensions and hopefully enhance it and make it even better and more thriving, or completely slash it, by deprecating and discontinuing "FinderSync Framework" and the API, now that File Provider Framework is available for the "intended usage". And if slashing it, if any replacement with the same or better functionality will come along. ABOUT THE "BUG" WHICH STARTED THIS THREAD It's very simple. The bug is Finder Sync Extension settings missing from System Settings application in macOS 15 Sequoia. I've already submitted it like FB15249290 and informed you here. I see the current status says: Recent Similar Reports: Less than 10 Resolution: Potential fix identified - For a future OS update This sounds encouraging, I only wonder what a "potential fix" really means, how huge that potential is? As well as what "a future OS update" will be. I still don't see any changes in the latest developer beta version of macOS 15.1 and I only hope that future update won't be macOS 16.0. But I've already been burned before, when some bugs actually waited for the next major OS version to get fixed. Anyway, I even wonder now if this was just a bug, or a deliberate decision. It seems just too big of an omission to be an error. I'm afraid it is a sign of slow deprecation and discontinuation of Finder Sync extensions. Another worrying sign, leading to the same conclusion, is that now, when you try to file a feedback using Feedback Assistant, if you choose to file a feedback on "Developer Technologies & SDKs" and for the platform choose "macOS" in the "Which technology does your report involve?" drop-down menu, there IS NOT File Sync Framework listed! There is File Provider Framework and many other frameworks available on macOS, but not Finder Sync! And then we go back to the question what are Apple's plans for the whole ecosystem of 3rd party Finder Sync extensions available at the market. Will they be slashed? Will something else come to replace the needed API? Like @Macho Man said, I react like this because I was burned before in the similar way. Continued in the following post…

@Kevin, I hope my response won’t sound like beginning of some argument. I understand you present the case from the point of view of Apple product and DTS engineers and I appreciate very much your input and everything you post here. However, I really feel an urge to comment on some of the points you made in your latest post. I'm trying to present the point of view of a small independent developer, who adopted Finder Sync API for certain reasons and built some software around it. As a general, rule this kind of language in our documentation should be read as "use it for this, don't use it for other things". I don’t know how the documentation “should be read”, I just know that to me it sounds like not putting limitations on usage of Finder Sync API to remote content/data syncing only. I may be wrong about it, but my estimation is that the current ratio of still maintained third party applications embedding Finder Sync extensions is about 6 to 7 agains 1 in favor of those, which don’t do anything related to remote content/data syncing (and that includes all content/data syncing applications before they adopted File Provider API). I think that says enough about how developers outside Apple understood the scope of usage for Finder Sync API. I understand that intentions of Apple engineers might be different, but the reality is quite different and Finder Sync API has created the whole ecosystem of third party applications embedding these extensions, which do nothing related to remote content/data syncing. I'm well aware that the extension point was used for much broader use cases, but I also think it was pretty clear from the APIs general behavior that it wasn't really designed for that. I have to disagree with “it was pretty clear from the APIs general behavior that it wasn't really designed for that” here. Again, it doesn’t matter what the intention was, it matters how people actually use it. Most of them see and use it as a way to extend Finder’s “capabilities”. Let me try to elaborate even further… Finder Sync API is rather small and simple. It consists of two classes (one acting only as an abstract class, meant to be subclassed and used as the entry point to extension execution) and one protocol. All of them comprise of less than a dozen of methods. None of those methods has to do anything with syncing remote content/data. While almost every class and method name, as well as their functionality, in File Provider API clearly shows API's intended use scope, the whole Finder Sync API is about monitoring local directories (that Finder “enters” and “exits”), adding badges to icons displayed in Finder and adding menu items to files selected in Finder. Nothing, absolutely nothing of this is in any way related to syncing remote data/content. The only thing related to (any kind of whatever) syncing in Finder Sync API is its name. The methods in the API simply “beg” to be used to add Finder functionality with icon badges and additional menu items. And like I’ve pointed it out at the beginning of this long reply, it seems that the vast majority of developers use it that way. … but the reality is that the FinderSync extension is not a particularly "good" part of the current system. I don’t know the internals of the current system to comment whether Finder Sync extension is “good part” of it or not. All I’m trying to say is that Apple, apparently unintentionally, created the whole ecosystem of applications using the API outside of its “originally intended” scope, just because the scope wasn’t clearly communicated (I still maintain that strong opinion), neither in the documentation, nor in the API functionality. As a general mechanism for extending the Finder, it's never been a particularly good solution, as that's a role that it was simply never designed to fulfill… While that may be true at a surface level, anyone whose actually tried to use it as a general "expansion" mechanism will very quickly notice that it significant issues and limitations. I agree with the examples you've stated here, but as a third part application developer, I think Finder Sync does a pretty good job in extending Finder’s functionality, apart from some obvious things (some of which you mentioned), like two or more extensions fighting over which one will present its icon badge if they monitor same directories and, as mentioned, inability to monitor certain folders ``(/Applications,iCloud Drive, actually ~/Library/MobileDocuments and some others). There are some points of improvements and I’ve already filed some bugs/requests, but they seemed to be completely ignored (some for years) and now, seeing how Apple engineers see Finder Sync API and how it "should be used", I’m not surprised. The fact is, Finder Sync API scope of usage is way broader than Apple initially intended (apparently). It seems the vast majority of developers see it as a way to extend Finder’s functionality. Therefore, if it isn’t “good part” of the system, PLEASE make it so (whatever that means). Or if you don't want or it isn't possible to do and you want to deprecate and discontinue it, PLEASE provide “good part” replacement with the same (and possibly more) functionality. The minority of Finder Sync extensions currently available on the market are and will be migrating to File Provider API, because they can and that API is meant for them. But if Finder Sync API is gone, the rest majority of available Finder Sync extensions will die with it as well. After all, the vibrancy and longevity of a computing platform depends on the availability of versatile third party software solutions. I think it’s in nobody’s interest to kill something (without providing equivalent replacement) that contribute to that vibrancy and versatility. …but the most useful thing you can do here is filing bugs and enhancement requests describing what you're actually doing and how you'd like things to work. This is the point to document what you're doing and why it's important so the engineering team can make the right decisions about how this should work going forward. Bugs are critical here, as they provide they're the concrete documentation the engineering team uses to decide what to prioritize and focus on. I completely agree with this and I've already filled a few bugs enhancement requests for Finder Sync API, but so far they have been ignored. However, I will continue doing so. However, the initial reason for this thread is not any functionality of Finder Sync API, but the missing settings for those extensions in System Settings application in Sequoia. I've filed such bug/enhancement request already, FB15249290. So far, it's been completely ignored for more than 10 days, I haven't been notified whether at least it's a duplicate of some other request.

I'm not sure how it works, I think only the initial poster (the owner of the thread) and possibly forum admins can recommend/unrecommend answers. But this one is clearly wrong and the recommendation should be removed.

Should the original answer recommending https://developer.apple.com/documentation/extensionkit/exappextensionbrowserviewcontroller?language=objc be unmarked as the Apple recommended correct answer in this thread? No, it doesn't work. See Kevin's response to me regarding that.

@KyleYe, see here for more information.

@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.

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" 😐)

… 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!

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.

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