Post not yet marked as solved
I haven't had the time to file a bug yet, but this might help anyone else who bumps into this...
The problem seems to be triggered by the target being set to be deployed. I'm referring to the Build Settings whose xcconfig equivalents are DEPLOYMENT_LOCATION and INSTALL_PATH, e.g.:
DEPLOYMENT_LOCATION = YES
INSTALL_PATH = $(LOCAL_APPS_DIR)
The deployment location might also play a role, though this is speculation "inspired" by macOS security policies.
In our case, the framework whose default Metal library was not being created, was set up to be deployed to the Frameworks directory for the current user, i.e.
INSTALL_PATH = $(LOCAL_LIBRARY_DIR)/Frameworks
...and this is enough to trigger the failure.
This problem seems to affect more than just the Metal compiler. I noticed it too with the Storyboard compiler for a silly Swift app. Since the app was set to be deployed to $(LOCAL_APPS_DIR) the storyboardc invocation was failing to copy the compiled storyboard to the app bundle.
Whether this is a bug in recent versions of Xcode, or a side effect of these various tools being unable to touch files at those locations, the solution is to add built phases to "do what the underlying compiler is no longer doing" ;-)
Post not yet marked as solved
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. 🤔
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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?
Post not yet marked as solved
...and while we (hopefully) wait for the official word on this, I would like to clarify something for other developers in the same boat:Although the /Contents/Library/LaunchServices/ directory wasn't mentioned or listed in the WWDC presentation, it is in fact recognized by the notarization process. If your submission is approved, you should see the privileged helper tool as one of the entries in the Log File.
Post not yet marked as solved
Thank you, this is great news since it cuts waiting time tremendously.
Post not yet marked as solved
Just ran into the same problem as you. It seems that WKWebView needs a certain NSRunLoop to do its work on, or perhaps it schedules its loading task on a queue that is paused while a modal window is running. Did you ever figure it out?
Thank you! :-) I feel terrible for overlooking that info.
Mike,Are you sure about that? When using float with a 4 component texture, you have an element size of 16 bytes. My underlying texture being 32-bit packed BGRA has a 4-byte element size (a.k.a. pixel).At the moment I am paying the price of copying the texture to a buffer, since no restrictions exist on those. I am just wondering if there is a more efficient way to access those pixels that doesn't require an interim copy to the buffer. It seems crazy that the shading language would not support the most common 2D 8-bit/component texture format out there.
