Finder Sync Extension develop in macos 14.4 but crash in macos 10.15

If I run the plugin binary directly …

What do you mean by that?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Please reply as a reply. I’m not notified when you reply in the comments. See Quinn’s Top Ten DevForums Tips for this and other titbits.

You wrote:

So I tried to run the plugin binary directly.

That’s not a valid way to run an appex.

The output of a normal direct run is An XPC service cannot be run directly.

Right.

But what's unusual is that its output is illegal hardware instruction

OK. That’s the SIGILL you’re seeing in the crash report. I don’t think it’s actually relevant because running the plug-in directly isn’t a valid option under any circumstances.

So, lemme summarise the actual issue:

• You have an app with a Finder Sync appex.

• Everything works fine on macOS 14.

• But things fail on macOS 10.15.

What are the symptoms of that failure? Not the ‘running the plug-in directly’ failure, but the failure you’re see when you try to use the plug-in in the normal way?

Also, if you try your “simplest APP project + FinderSyncExtension project” on macOS 10.15, does that fail as well?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

The symptom of failure is that the extension is active in the System Plugin Settings panel, but there is no expected response that the plugin has executed.

For example, add the following sample code to the plugin

- (instancetype)init {
    // Set up the directory we are syncing.
    self.myFolderURL = [NSURL fileURLWithPath:@"/"];
    // ......
    return self;
}

- (NSMenu *)menuForMenuKind:(FIMenuKind)whichMenu {
    NSMenu *menu = [[NSMenu alloc] initWithTitle:@""];
   [menu addItemWithTitle:@"Test" action:@selector(testAction:) keyEquivalent:@""];
   return menu;
}

This method expects the finder's file context menu to have an extra option "Test", which is fine on macOS 14, but when I packaged the program for 10.15 no option appeared. I don't know how to know if the plugin is currently activated or running. So I'll try to try to see if it agrees with the normal situation by executing the plugin binary. (And it did run differently than the normal situation)

This problem was able to be reproduced even with the simplest demo I could find, but unfortunately I can't upload the zip file of the project here.

I can briefly describe how to build this simple demo:

1. In MacOS 14.4

2. Create a new app project using the following parameters

1. Add a new Target and select Add Finder Sync Extension, using the following parameters

1. Use the default code, or change it to the above code.

2. Modify the minimum supported MacOS version to 10.15.

3. Compile and run it in macOS 14.4 (remember to activate the extension in the Extensions panel of the System Settings), you can see that the plugin is working properly!

4. Compile the program in macOS 14.4, send it to macOS 10.15 and run the program. Activate the extension in the Extensions panel of the System Settings, but at this point you will see that the extension is not working, even though you activated the extension.

OK. In this case I recommend that you start by adding a ‘first light’ log point to your appex to see if it’s running at all. I talk about this idea, in a very different context, in Debugging a Network Extension Provider.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I tried adding the initialized logs in FinderSync::init and was able to successfully output to Console.app on macOS 14.4, but not on macOS 10.15

Is there any way to determine why it's not running?

OK.

Usually a problem where your appex fails to load completely results in one of two symptoms:

• A crash report showing the appex crash before you get to your -init method

• Some indication of the problem in the system log

Your earlier posts talk about a crash report when you try to run the appex directly. I presume that means you get no crash report when you try to run it normally.

If so, that leaves you hunting in the system log. That’s tricky to do. My usual approach to this is:

1. Set up a VM with just my program. That’ll minimise the amount of other stuff going into the system log, and helps with the next step.

2. Enable the recording of private data.

3. Reproduce the problem.

4. And then immediately trigger a log snapshot like so:

   % sudo log collect --last 5m
   

5. Open that snapshot in Console.

6. And go hunting.

Your Friend the System Log has info and links that you’ll find helpful.

The hard part is step 6. I usually start by searching for any log entries from my process. Even though it never gets to -init, there may be log entries from system components that run before that. If I see any log entries from my process, the last few log entries might offer a useful hint.

If I see no log entries from my process, I start looking for log entries from the system that relate to my process.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I tried your approach and found these exception logs below.

(“com.cxy-test.finder-test.finder” is the bundle id of the test plugin)

There are tons of error logs like this in there：

Failed to create LSPlugInKitProxy object (after sorting) for com.cxy-test.finder-test.finder (956)

But it doesn't tell exactly why the creation failed

Please post those log entries as text rather than a screen shot. Some of them look interesting, but they’re truncated in the screen shot.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Sorry, I should have sent you the logarchive file directly, but the log content is so big that it's still 25MB+ even after I compressed it, so I looked for a site where I could staging the file, here's the link to access it:

https://zippyshare.day/qE1pO7CJTUKbo9a/file

Consider this entry:

type: error
time: 2024-05-28 16:28:08.398561 +0800
process: Finder
subsystem: com.apple.PlugInKit
category: lifecycle  
message: [u 1059AE1C-F58F-43E8-9DC0-C4BCD900F6AF:m 792C329C-69B1-4B30-B494-EEA62BCD0CBE] [com.cxy-test.finder-test.finder(1.0)] Connection to plugin interrupted while in use.

That suggests that your plug-in has crashed. Looking back up the log I see this:

type: default
time: 2024-05-28 16:28:08.390424 +0800
process: finder
subsystem: com.apple.PlugInKit
category: lifecycle  
message: Hello, I'm launching as euid = 501, uid = 501, (persona not available)

That’s your plug-in starting up. Indeed, it’s the first log entry from your process, pid 1043. If you then filter for all log entries for pid 1043, you see this:

type: default
time: 2024-05-28 16:28:08.397731 +0800
process: finder
category: <Missing Description>
message: No Info.plist file in application bundle or no NSPrincipalClass in the Info.plist file, exiting

That seems bad. I recommend that you check your NSExtensionPrincipalClass property.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Below is the info.plist file content of the demo that can be reproduced, I see that there is NSExtensionPrincipalClass in it.

Is it because there is a difference in the info.plist specification between the 10.15 system and the latest one?

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>BuildMachineOSBuild</key>
	<string>23E214</string>
	<key>CFBundleDevelopmentRegion</key>
	<string>en</string>
	<key>CFBundleDisplayName</key>
	<string>finder</string>
	<key>CFBundleExecutable</key>
	<string>finder</string>
	<key>CFBundleIdentifier</key>
	<string>com.cxy-test.finder-test.finder</string>
	<key>CFBundleInfoDictionaryVersion</key>
	<string>6.0</string>
	<key>CFBundleName</key>
	<string>finder</string>
	<key>CFBundlePackageType</key>
	<string>XPC!</string>
	<key>CFBundleShortVersionString</key>
	<string>1.0</string>
	<key>CFBundleSupportedPlatforms</key>
	<array>
		<string>MacOSX</string>
	</array>
	<key>CFBundleVersion</key>
	<string>1</string>
	<key>DTCompiler</key>
	<string>com.apple.compilers.llvm.clang.1_0</string>
	<key>DTPlatformBuild</key>
	<string></string>
	<key>DTPlatformName</key>
	<string>macosx</string>
	<key>DTPlatformVersion</key>
	<string>14.5</string>
	<key>DTSDKBuild</key>
	<string>23F73</string>
	<key>DTSDKName</key>
	<string>macosx14.5</string>
	<key>DTXcode</key>
	<string>1540</string>
	<key>DTXcodeBuild</key>
	<string>15F31d</string>
	<key>LSMinimumSystemVersion</key>
	<string>10.15</string>
	<key>LSUIElement</key>
	<true/>
	<key>NSExtension</key>
	<dict>
		<key>NSExtensionAttributes</key>
		<dict/>
		<key>NSExtensionPointIdentifier</key>
		<string>com.apple.FinderSync</string>
		<key>NSExtensionPrincipalClass</key>
		<string>FinderSync</string>
	</dict>
</dict>
</plist>

I see that there is NSExtensionPrincipalClass in it.

Indeed.

I had another look at that error, and also looked at the context in which it’s generated, and it’s tied to the AppKit startup sequence. The code that generates the error is literally within NSApplicationMain. Note that the error says NSPrincipalClass but that’s nonsense for an appex; in an appex the right property is NSExtensionPrincipalClass.

The startup sequence for an appex is somewhat different from the startup sequence for an app, and it’s definitely evolved over time. My best guess as to what’s causing this problem is that modern versions of Xcode are failing to generate code that’s compatible with the legacy boot sequence used by macOS 10.15.

Do you know when this ‘broke’? That is, what was the last Xcode version where you were able to build a 10.15 compatible Finder Sync extension?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

My system version is 14.4 and xcode version is 15.4.

I tried downloading xcode 14.3.1 and xcode 13.4.1 but none of these versions work on my system.

Is it possible to make it compatible with 10.15 systems by manually adjusting the info.plist contents?

I tried downloading xcode 14.3.1 and xcode 13.4.1 but none of these versions work on my system.

Right. If you want to run older versions of Xcode, you need a machine running on older version of macOS. The table on Developer > Support > Xcode shows how these correlate.

To avoid messing up my main machine I usually run tests like this on a second machine. I typically use a VM for this.

Is it possible to make it compatible with 10.15 systems by manually adjusting the info.plist contents?

It’s hard to say without knowing what’s actually causing the problem.

I see three paths forward:

• If you really need to support 10.15, you’ll have to do a bunch of work to investigate this yourself, as I’ve been outlined upthread.

• Alternatively, you could file a bug against Xcode 15. That’s easy to do, but it means you can’t make progress until the bug is resolved.

• You could drop 10.15 support.

ps If you do file a bug, please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I tried installing an older version of xcode on a 10.15 VM and created a simple finder sync extension. The comparison revealed an extra piece of information in the info.plist of the program compiled from the old xcode on 10.15

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    // ....... other .......
    <key>NSPrincipalClass</key>
    <string>NSApplication</string>
</dict>
</plist>

I tried to add this information to the info.plist file of the previous project and it worked fine with the lower version! Thanks for helping me troubleshoot and fix this!