Okay, I made it working exactly as I wanted, so I'd like to inform all people participating here, but also others who might see this while searching for similar content. The first stumbling block was making sure the application can actually send Apple Events in the first place. And in that regard I admit I should've listened better to @Etresoft and I apologize to him for not listening more carefully and dismissing his remark about "hoops so that the app can actually send Apple Events" too easily. It turned out that, even though the application is NOT sandboxed, com.apple.security.automation.apple-events entitlement is mandatory in the entitlements file. I couldn't assume it would be necessary even for a NON-sandboxed app, but it is. From my experience with executing AppleScript from another, sandboxed, application I remember that defining com.apple.security.automation.apple-events in the entitlements file and NSAppleEventsUsageDescription in the Info.plist file always go together and that's the case here too. So, if either com.apple.security.automation.apple-events = YES or NSAppleEventsUsageDescription is missing, macOS/TCC won't even prompt you to allow the application to "automate" other application, effectively blocking sending Apple Events (hence, executing Apple Script). The annoying thing about the code above is that it will execute without any error, not giving any clue as for what went wrong. Once this first hurdle was jumped over, the application started sending Apple Event(s) to Finder, I only needed to figure out how to make it do what I needed. The following thing was to use -descriptorWithFileURL: when creating AE descriptors for files. Using -descriptorWithString: and passing file's path resulted in the event silently failing. Finally, the last piece of the puzzle was how to instruct Finder where to copy files. I was struggling to figure out which AEKeyword should be used to pass the destination URL descriptor to the event descriptor. Not passing the destination URL or doing so with the wrong keyword resulted in Finder making file duplicates at the same destination as sources, adding them copy 2, copy 3… in file names, just like making duplicates in Finder's UI. keyAETarget sounded like a logical choice to me, but that turned out to be wrong. Since no other keyword definition seemed logical to me, I had to turn to reverse engineering of AppleScript execution, as per @The Eskimo advice, and figure out what the to parameter of Finder's duplicate command in AppleScript actually translates into in Apple Events. It turned out it translates into the AEKeyword of value 0x696e7368 and using the HFSType constants, that would be 'insh'. It turned out it's defined as keyAEInsertHere. I also took some time to dig into some very old header files in (pre Mac OS X ) MacOS and I found out that constant being defined as keyAETo. Once this all was put in place, the code above worked fine and behaved exactly as I wanted: in case there were already existing files in the destination, Finder would present its conflict resolution panel. Even passing NSAppleEventSendAlwaysInteract | NSAppleEventSendCanSwitchLayer as options when sending the event wasn't necessary, just passing simple 0 was enough. I hope this was helpful, I thank you all for help and suggestions you gave while trying to solve this problem.

@DTS Engineer, Not to discount any of that but it seems to me that if you're able to get NSUserAppleScriptTask working you could write a slightly more complicated script that checks for files in the destination before saving and then takes appropriate action inside of the script. The Finder defines an 'exists' verb in its dictionary that should be very helpful for that sort of thing. Right, and it sounds like a very sensible thing to do. However, as I've mentioned at the very beginning of my initial post, I need to programmatically invoke exactly the same behaviour of Finder as if a user copies files in it using standard UI-based methods. "Why is that?" discussion is out of the scope of the question. I appreciate your effort to help, I really do, but the solution you suggested isn't what I need.

@Etresoft, Well there's still the Apple Events capability in "Signing & Capabilities". You have to provide a message to the user about why your app needs AppleEvents. I'm not sure what happens if that's missing. I don't remember from when I've done it previously, but I think OS just offers some default message presented to the user. I'm going to go ahead and disagree on that point. But I assume you're only talking about the end result for your use case. I haven't tried it, but "osascript" just executes scripts, without providing any extra functionality to control them. Since the plain script exhibits the undesirable (for me) behaviour with already existing files, I assume using "osascript" would result in the same. Are you sure that's even possible? So I think your suspicions here are likely unfounded. I'm not sure, but for the beginning, I first need to programmatically make Finder to react. And at the moment I'm not able to, due to all the explanations I provided in the initial post. I don't understand why it's so important to use the Finder. Writing your own conflict resolution UI would be a lot easier than writing anything in AppleScript. Like in my previous response, discussion "why?" is out of the scope of the question. Like I've said, I know how to write code to copy files using various and all available currently functioning, stable and non-deprecated APIs. But I need what I asked for, and that's using Finder like it's being used by a regular user. I know it sounds strange, but that's how it is. That's why I mentioned it at the very beginning to save you from spending time offering me what I don't need. Again here, I appreciate your effort to help, but the solution you suggested isn't what I need. At this moment I need to know how to use NSAppleEventDescriptor (or AESendMessage() for what it matters) to make Finder copy files. Or a straight answer that it isn't possible.

Have you jumped through all the hoops so that your app can actually send Apple Events? Here is some old documentation that might be a good starting point: https://developer.apple.com/library/archive/qa/qa1888/_index.html The application isn't sandboxed, so I didn't add any additional entitlements and it should not matter. Moreover, if it was sandboxed I'd expect some kind of error in the console regarding sandboxing limitations, as it usually happens in such cases. But in this case, everything is silent (but doesn't work). NSAppleEventsUsageDescription should not matter either, but even with that added, nothing changes. Any new code that relies on AppleScript is risky. Apple is already transitioning to Shortcuts. And Apple has begun to be much more aggressive about deprecating and discontinuing technologies, pretty much all of which are much recent than Apple Events. I realise all that. However, I don't see why I wouldn't use it while it's still there and hasn't been deprecated yet. I can't switch to Shortcuts yet, as I need to support some older OS versions. In older apps where I still did such things, I had good success with running the "osascript" command-line tool with carefully constructed parameters. This approach works the same way as when executing AppleScript script with NSUserAppleScriptTask (or otherwise) and I've mentioned in my initial post why such approach isn't working for me in case files with same names already exist at the destination.

Also, just to mention that I tried the same above code, but creating URL-based descriptors for source and destination, instead of text-based ones. So, instead of: [NSAppleEventDescriptor descriptorWithString:[url path]] using [NSAppleEventDescriptor descriptorWithFileURL:url] The outcome was exactly the same.

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