Hi Quinn, Absolutely yet. We use productbuild and pkgbuild to make our installer.

Hi Quinn, There is no crash report whatsoever. We know that the FBA is launched as we see it in the Activity Monitor and after a few seconds or so its terminated or quit (?). One work-around we've asked our users to do is to add the FBA as a login item (so its launched automatically). And this work-around works but its getting difficult to tell users to do this as this odd behavior never existed before with macOS.

Thanks Quinn. Will proceed and let you know what we find.

Hi Quinn, We implemented your suggestions and got an extremely useful log of the specific calls that are failing and returning an error. Our code is terminating as we fail to write some critical information into a file that is required by our code. We're looking into whether its a bug on our side or there are some change we have to implement. Thanks.

First of all, thank you for the answers. We went back and figured exactly what was occurring and the condition. Everything we did when I posted my original message was on a newly setup M4 Pro Mac with 15.5 as we like to test things continuously. To investigate further we setup a VM with the same conditions Admin user/Standard user. On the VM everything was working under the Standard user account wherein the System did pop up message saying "Do you wish to grant ABCD" access to the Desktop or Downloads etc folder. We grant access and our plug-ins work as expected. We went back to the actual M4 Pro machine and understood exactly what was occurring. The Admin user was Physically logged into the system though the GUI was not in use. But the Standard User for testing purposes was logging in via Screen Sharing to the M4 Pro Mac. So the System was not popping up "Do you want to provide access to the Desktop etc folder" etc. in this condition to the Standard User. Where did the Message/Window to confirm access to the folder vanish to? The moment the Admin User was physically logged off the Mac, everything started working for the Standard User even under Screen Sharing. This makes us wonder if this is an edge case macOS bug?

We didnt have 2 sessions of our plug-in/Photoshop being invoked. The admin user was just physically logged in for other purposes. So, only 1 instance was running of Photoshop/our plug-in/background process always under the Standard user account. To answer your questions the following is the code we use for finding/launching is below - [[NSWorkspace sharedWorkspace] openApplicationAtURL:app_path  configuration: configuration completionHandler:^(NSRunningApplication* app, NSError* error)   if (error) {              NSArray *directory_path_arr = NSSearchPathForDirectoriesInDomains(NSApplicationSupportDirectory, NSLocalDomainMask, YES);            NSString *filePath = nil;                                            if(directory_path_arr)                              {                                  NSString *directory_path = [directory_path_arr objectAtIndex:0];                                  NSString *filePath = [directory_path stringByAppendingPathComponent: [NSString stringWithUTF8String:(const char *)gAppSupportFolderName]];                                                                    if(filePath)                                     [[NSWorkspace sharedWorkspace] launchApplication:filePath];                             }                             NSLog(@"Failed to run the app: %@", error.localizedDescription);                         }                    }]; Configuration is set to [configuration setPromptsUserIfNeeded: NO] We use TCP/IP sockets to communicate between the plugi-n and our background process.

What we did was go back to the original M4 Pro macOS machine we just configured and went through the process of repeating the steps which allowed us to discover the condition in the first place. Our plug-in is completely loaded into Photoshop process. The faceless background app is launched by our Photoshop plug-in. We poured through all logs and the faceless background app we invoke runs without any errors. Nothing is reported anywhere so the first call openApplicationAtURL succeeds. If we manually launch the background process the result is the same as our original findings. We don’t allow our background app to run more than one instance under the same user.