FinderSync extensions gone in macOS settings

@milke Indeed. I just wanted to add how I'm using pluginkit in an app outside the Mac App Store since Kevin made this point about pluginkit when asked if it was a valid workaround:

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.

I use pluginkit, and have been for years for the reason I described in my previous post. It wouldn't be good for devs if they deprecated it without replacing it with something that could achieve equivalent functionality. I just wanted to put that out there in the universe.

As far as my sandboxed Mac App Store Finder extensions go, there is no workaround and I'm in the same boat as everyone else. I can only explain to users how to enable the extension in Terminal or recommend the FinderSyncer app (or write my own which I do not want to spend time doing right now).

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?

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.

If you view the original post this answer looks like it's the accepted answer (I don't think the OP marked it as the accepted answer). But it looks that way and is badged "Apple recommended."

Since this suggestion didn't work the answer shouldn't be pinned to the original post and badged Apple recommended IMO.

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.

The word "supports" doesn't imply a limitation (English is not my first language, so I may be wrong).

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

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. For example:

• It only allows on FinderSync extension to "control" any given directory and doesn't handle that nesting very well. Having an "outer" FinderSync extension will prevent extensions from working properly in child directories.

• There are many directories where it simply doesn't work, notably "/Applications/".

I'm well aware that the extension point was used for much broader use cases, but I also thing it was pretty clear from the APIs general behavior that it wasn't really designed for that.

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'm not going to talk about our future plans but the reality is that the FinderSync extension is not a particularly "good" part of the current system. As a tool for cloud syncing apps (again, it's primary role), it's been completely replaced by a superior API (Replicated File Provider). 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 fulfil.

That leads to here:

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.

I've already discussed this with the engineering team, 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. Speaking for myself, it's far easier to argue that an issue need attention when I can point to a set of bugs on that issue.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

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

I think that's a very important point to understand here. My goal here is to help you understand how are system works and to help you make good development choices. My role is primarily about communicating with you, not bring information "back" to Apple. While I can and do work very closely with our engineering teams, that's not my primary role That lead me to here:

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 what happened there. The bug was actually looked at and marked as a duplicate by the engineering team on 9/26, and I'm not sure why that wouldn't have been immediately visible to you. Note that this is exactly what I (and you) wanted to happen, as the bug it was dup'd is to the existing bug which is being used to manage this issue.

Again, the key point to understand here is that the reason for filing most bugs isn't to "tell us" about the problem. The reason to file bugs is to document that the problem you're having so that we can properly assess how wide spread the issue is and the level of damage it's creating.

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.

Bug numbers?

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.

The term "support" in this context means "this is who the API was created for". Your right that nothing prevents you from using it for other contexts, however, the reason that kind of language is included is to tell let you know what user cases the system has committed itself to supporting.

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

A critical issue to understand here is that, by necessity, Apple has to focus on how an issue impacts users, not individual apps. A bug that breaks 1 app with 100 million users is a much bigger problem (for us) than a bug that breaks 100 apps with 100,000 users.

I think that says enough about how developers outside Apple understood the scope of usage for Finder Sync API.

I want to be clear about what my concern here actually is. At a personal level, I have no particular objection to apps using FinderSync extensions to implement clever and intersting things. I'm also not surprised that this occurred. Finding new and creative ways to user out APIs to do things that they weren't really intended to do has a long and illustrious history.

My concern here is with the idea that our documentation wasn't clear about what this was "for" and that using it outside of that space carried a certain amount of risk:

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.

Our documentation was and is very clear about how we expect this extension point to be used. The first sentence of the document that originally introduced and still acts as it's primary documentation source 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. "

Then later:

"Make sure the Finder Sync extension point is appropriate for the functionality you plan to provide. The best Finder Sync extensions support apps that sync the contents of a local folder with a remote data source."

And also:

"Finder Sync is not intended as a general tool for modifying the Finder’s user interface."

Particularly with that last point, I'm not sure how this could have been any more clear.

Having said all that...

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.

I don't think it's inherently unreasonable to want the Finder to provide an API that supports the kind functionality FinderSync has provided. I'd like to make sure great product continue to work well on macOS.

The best way you can help ensure that is by filing bugs telling the engineering team what you're currently doing with it and what you'd like it to handle better. If you've filed bug on this already, then please post the bug numbers here.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Like @mike I do appreciate your response. I especially appreciate your other responses on several issues on other posts and to me specifically in an DTS incident. I think it helps us all become better developers (we all don't have degrees from Stanford after all). I did have a few knee-jerk reactions reading some of the responses here. I decided to take a deep breath and think on it a bit before replying.

I appreciate that you confirmed the original issue reported here (that the "Finder Extensions" section has completely disappeared from System Settings) is indeed a bug and not intended behavior. This was done without prior warning. If you do deprecate an API without introducing a feature equivalent replacement, this isn't the way to do it.

I think it is reasonable that others inquired about the future of Finder Extensions in response to all this. I don't think it is particularly helpful to point out that the intended use of an API is not what Apple expected. I know you probably didn't mean it that way but when you read it, it could feel like a cop out. "You were holding it wrong the entire time, so if the section in Systems Settings disappears that's on you." Again I don't think that's how YOU intended it to come across. But that's how developers could feel, reading it (at least initially). I think you were recommending that you move to a newer API (which if we could, we would but that newer API doesn't support what we are doing).

I consider App Development to be a creative field and I think you touched on this in your previous post. The fact that developers are quick to ask if this bug is a sign of future deprecation speaks to the fact that they have probably been burned before.

Apple has to focus on how an issue impacts users, not individual apps. A bug that breaks 1 app with 100 million users is a much bigger problem (for us) than a bug that breaks 100 apps with 100,000 users.

This makes a lot of sense. We all have to prioritize issues and user impact is very important. However, I've reported countless bugs over the years (many of which are low-hanging fruit which you should be able to fix in 15 minutes but often never get fixed). While I don't have 100 million users, I imagine that such low hanging fruit impacts a lot of regular users across many apps (many of whom don't even know how to report bugs to Apple). You can't reasonably expect us to keep filing bugs if you seem to never fix them, at least not in a timely manner (presumably because we don't have millions of users).

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…

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 ;-))

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.

Okay, I don't care about "the best" extension, I care about ones, which do the job they're intended to do.

Yea I mean, that's an opinion. So much archived documentation. Think this thread got a little off-topic from the initial reported issue.

>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?

Yeah I don't understand why they have to speak to us in riddles. They either added the section back in System Settings and it'll be fixed in the next update, or they did not. There is not really anything in between here (though I recognize in more complicated cases you may not know with 100% certainty whether a bug is fixed or not). I don't see a fix mentioned in the Beta release notes, though.

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!

Ouch. It's been hard lately to get maintenance updates through App Review on the Mac App Store lately. Extremely frustrating.

It's a real bummer when you hit a system bug that blocks you from doing what you need/want to do and you have no idea if/when they'll ever fix it. Some bugs are so bad you'd assume they just fix them right away but you would often be wrong. They broke AVSpeechSynthesizer in iOS 17 and never fixed it (maybe they did in iOS 18 but I don't think I want to use that API anymore..given how they treated apps using it). I thought for sure they'd fix AVSpeechSynthesizer quickly because so many apps use it, but they didn't. Never got a response back on my bugs. TSI quickly got shut down with "no workaround available." A similar story. I got plenty of stories.

You'd think a change that removes an entire preferences section would be easy to revert and would be fixed quickly. You got apps in the Mac App Store now that when purchased, can't work. Apple hasn't pulled all the Finder Extension apps from the Mac App Store. Presumably a bug that would cause users to purchase a non-functioning app (on Sequoia) at no fault to the developer would be considered a priority.

If we added the total downloads of every app on the Mac App Store together we're still probably less than Facebook so our prospects are looking pretty grim here.

I'm just learning about FinderSync and decided to start up a test project, ran straight into this issue with Sequoia today. If I file a Feedback Assistant, should I reference https://feedbackassistant.apple.com/feedback/15249290 ?

If Apple is going to remove/deprecate, just let us know so we can stop banging our heads against the wall. 😵‍💫

A good read on how these settings have "changed" over the years.

https://fileutils.com/blog/sync-my-finder/6

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.