macOS 26.1 Tahoe on ARM: FinderSync extension does not work

Question

Created 6d

Replies 3

Boosts 2

Participants 2

When running the currently latest version of macOS (26.1) on a machine with ARM CPU (I could not reproduce the issue with Intel-Based machines) Finder Sync extensions do not work any more in general.

Steps to reproduce the problem:

In Xcode create a new macOS App project with default settings (in my case I chose XIB for the UI and Objective-C as language, and disabled testing, but that should not make any difference)
In Xcode add a new target / "Finder Sync Extension" to the project with default settings, this adds a new Finder Sync Extension with example code to the app.
Run the application and open Finder and navigate to "/Users/Shared/MySyncExtension Documents"
In the system settings ("Login Items & Extensions") enable the extension (Listed as "File Provider").
On systems where it is working, in the context menu of that folder an entry "Example Menu Item" will appear. On systems where it does not work it is missing.

Some findings:

Adding the *.appex with "pluginkit -a" registers the extension as expected, it is then visible in the system settings, removing it with "pluginkit -r" is also reflected in the system settings.
"pluginkit -m -i <extension identifier>" returns the extension on systems where it is working (assuming it is registered while this command is executed), on systems wehre it is not working, nothing is returned, regardless of the registration state.
When enabling the extension in the system settings nothing more happens, there is no process started for the extension (unlike as on systems where it is working), and thus no context menu entries and no badges are displayed in Finder.
Restarting Finder or the system does not help.

Any ideas what I could be missing here?

Boost

Answer 1

DTS Engineer OP

Apple

2d

When running the currently latest version of macOS (26.1) on a machine with an ARM CPU (I could not reproduce the issue with Intel-based machines), Finder Sync extensions do not work anymore in general.

Have you filed a bug on this and, if so, what is the number?

Any ideas what I could be missing here?

Have you reproduced this on dedicated test machines (where nothing else is installed) or is this only happening on end-user machines?

I have a post here that talks about this in more detail. What typically causes this is "nesting" FinderSync extensions. Also, are you specifically placing contents in "/Users/Shared", or was that just a convenient location you selected for testing purposes? That particular directory is not one I'd recommend any developer really "use", as the combination of open permission (so "everyone" can modify it) and a "known" location (so all sorts of "random" apps could be interacting with it) means that it isn't really a location you can "trust".

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0

Answer 2

dhoelzl OP

2d

Thank you for your quick response!

Yes, I have already filed a bug, it's number is FB20947446.

We can reproduce the issue on "normal" end user machines where nothing special is installed or configured.

One particular machine where the problem occurs is a MacBook Pro, 13-inch, M1, 2020 with 16 GB of memory and macOS Tahoe 26.1.

One machine there the problem does not occur is a MacBook Pro, 16-inch, 2019, 2.3 GHz 8-Core Intel Core i9 with 32 GB of memory and Tahoe 26.1.

"/Users/Shared" is the default path which is used in the Xcode template when creating a Finder Sync Extension. I thought that for reproduction purposes it would be good to just use that as it is to make sure that there is no mistake on my side. And I assume that the template should work by default.

The location that is used in our product where the problem also occurs is located in the current user directory, where I suppose that it is common to place files that should be synchronized, for which purpose the Finder Sync Extension is designed.

What exactly do you mean with "nesting" FinderSync extensions?

Thank you and regards, Dominik

0

Answer 3

DTS Engineer OP

Apple

1d

Yes, I have already filed a bug, it's number is FB20947446.

OK. The engineering team hasn't had a chance to look at it yet, but I can immediately tell you that they're going to need a sysdiagnose from the machine where the failure is happening.

"/Users/Shared" is the default path which is used in the Xcode template when creating a Finder Sync Extension.

Oh. I can see why they used that in the template (it's basically the only "user path" they can guarantee exists), but that's still not... ideal.

However...

I thought that for reproduction purposes it would be good to just use that as it is to make sure that there is no mistake on my side.

...it should work fine for basic testing, particularly on a dedicated test machine.

The location that is used in our product where the problem also occurs is located in the current user directory, where I suppose that it is common to place files that should be synchronized, for which purpose the Finder Sync Extension is designed.

OK, that's fine. However, not that the Finder Sync Extension point has basically been replaced by replicated file provider for apps doing "sync".

What exactly do you mean with "nesting" FinderSync extensions?

This happens when one FinderSync extensions target directory is inside the target directory of another FinderSync extension. The typical case here is a app that's trying to act as a "general" extension for the Finder, so it targets a "broad" directory like the users home director or even "/". A extension which uses a designated directory inside the users home folder is now "nested" inside the other extension.

The problem with this is that it doesn't really work. The Finder makes no attempt to account for this, so one of the extension is not going to work inside that nested directory.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0