Having the same problem. Was already setting setDraggingSourceOperationMask:forLocal: but still doesn't work: the -[filePromiseProvider:writePromiseToURL:...] method isn't being called. This started happening with the most recent macOS Big Sur Beta, must be a regression?

macOS Big Sur Beta 9 mostly fixes this problem, with a strange exception. The reason you may not be able to reproduce the problem is that maybe your customer hasn't had a chance to update to Beta 9 yet. In Beta 9 when our non-sandboxed app is launched as a result of a custom URL invocation from Safari, it gets the correct UNIX/POSIX environment (home folder, system folders, etc). BUT, for unclear reasons, the sandbox container ID as reported by the process’s environment variable APPSANDBOXCONTAINER_ID is still Safari’s. This seems extremely unusual, as if the fix is only partially there. Unclear what else may be different about an app that runs under a different app’s Sandbox Container ID. 🤔

You are not alone in being unable to update to Beta 4. On my DTK, when clicking Update Now, the progress bar goes quickly up to a fifth, then abruptly fails with an error claiming that the download failed. Had a problem more similar to yours on an Intel Mac too (it would advertise two updates, one for Beta 4 and one for the full version). If yours is an Intel Mac I would recommend unenrolling from beta updates, then enrolling again. Try installing the full Big Sur beta if that is an option. The incremental update to Beta 4 bricked my Mac and had to go into Recovery Mode.

Try re-signing the FxPlug framework with your own identity (the same one you are using to sign the target, which may be different in Debug/Release configuration).So... disable automatic code signing in the Copy Files phase, where you are probably copying the FxPlug framework to its final location inside your bundle. Next, add a build script which resigns that framework with your own identity:codesign --force --timestamp --options runtime --sign "${CODE_SIGN_IDENTITY}" "${BUILT_PRODUCTS_DIR}/${FRAMEWORKS_FOLDER_PATH}/FxPlug.framework"As a side note, I have "Code Signing Inject Base Entitlements" ON in my Debug configuration, and OFF for Release. I'm not sure what’s going on on your system, but I don't think that option is *directly* affecting your ability to load the filters. It is more a case that when you have that option on, a bunch of stuff that doesn't pass GateKeeper validation gets a free pass.

Hi hateom,In most cases, you should never have to explicitly add that entitlement to your targets. AFAIK Xcode automatically injects that entitlement when you begin a Debug session for that target. And since you don't need software that you are debugging to be notarized, this is perfectly fine. (I assume you are already codesigning to run locally)From my experience, as long as:- you are using the most recent version of FxPlug and PlugInManager, embedded as appropriate inside your PlugInKit container- you are codesigning with the hardened runtime flag- your loadable code is linked against a recent version of the macOS SDKYou should be able to build plugins that are loaded by Final Cut Pro / Motion and that can be notarized.

Hi Frank,Thanks for all the help. Unfortunately disabling color correction at the CIContext level doesn't quite solve the problem I was set to solve. Our overall image computation does need color management. It is only lookup tables to store intermediate results that shouldn't go through the color conversion process. Someone did point out to me that it has been a very long time that the __table qualifier hasn't had any meaning to Core Image. It is parsed without errors, but it is ignored since the Core Image implementation that shipped with OS X 10.11. This is noted in the Core Image kernel language docs.It is also possible to sort-of disable color correction for a specific input to a kernel if you happen to know what color space its values were encoded in. You simply pass that same color space to kCISamplerColorSpace, turning the color management pass to a no-op.And though this does not match my usage scenario, you can also evaluate (render) a CIImage to a surface (IOSurface, Metal texture, etc.), which gives you a chance to re-create another CIImage from that data and omit the colorspace. We’ve used render destinations and the latter technique before, but the AFAIK the API really does seem to lack a clean way to accomplish what many of Apple’s own built-in kernels are doing, that is: use kernels to create intermediate results that do not encode RGB values, to be consumed by later kernels.

Hi Frank,Unfortunately it does not work. It seems that the NSNull value in the dictionary is simply ignored. The resulting sampler still thinks it should color match (my input image is one of the desktop pictures that ships with Catalina, hence the Display P3 profile):<CISampler: 0x60000000c980> samplemode linear extent=[0 0 6016 6016][-1 -1 6018 6018] affine [1 0 0 -1 0 6016] extent=[0 0 6016 6016] opaque colormatch DisplayP3_to_workingspace extent=[0 0 6016 6016] opaque CGImageRef 0x104e14460(717) RGBX8 6016x6016 alpha_one extent=[0 0 6016 6016] opaqueAny other ideas?