We have a non-sandboxed app that uses a custom URL scheme to allow redirection of certain tasks from Safari to our app, when installed, and with permission from the user. In the latest Beta of Safari 14 on macOS Big Sur Beta, Safari launches our app in its own Sandbox Container. This obviously breaks our software, which expects and requires a "normal" environment. This is a regression in Safari. It still asks for permission before opening every single custom URL. Users still have to install our notarized software beforehand on their systems in order to access these custom URLs. I tried filing a bug. Tried a DTS ticket. No reply to either. Does anyone know of this problem, and know of a workaround? Our software obviously cannot escape Safari’s sandbox container. At best we can detect it, right now, but our software is broken 😫 For the record, if the user launches our app *before* attempting to open the custom URL, then Safari is more than happy to pass along the URL to the running instance of our software (which is great). But if Safari has to launch our app in order to process the custom URL, our app lives within the confines of Safari’s container.

Installed the Xcode 12 GM on a couple systems, updating from Beta 6, only to discover that it doesn't include macOS 11 SDK. No indication of this particular change in the release notes. Am I missing something obvious? I would imagine that to be the default SDK, if anything... but instead it defaults to the 10.15 SDK? 🤔 Thanks!

I would like to be able to write CIKernels that output a lookup table or other blob of data, to be used by subsequent CIKernels.The data generated by such a kernel is fed to subsequent kernels whose corresponsing sampler input has been tagged with the "__table" attribute to disable colormatching for that input. This is a scenario that already works if one has the ability to allocate the CIImage himself, so that a nil colorspace can be passed. But when asking CIKernel for an output image, it is not possible to request an image without a colorspace associated with it. I'm referring to methods like this:- applyWithExtent:roiCallback:arguments:There are also no APIs in Core Image that would allow you to strip colorspace information from an existing image, AFAIK. (As in "hey I know this recipe is tagged with the working/output colorspace, but in reality it contains values that do not encode RGB at all")If I feed the output image from applyWithExtent:... to another kernel whose sampler has the __table attribute, from my observations it still appears to be colormatched. I can see three possibilities:1) I am clearly missing something.2) The __table attribute no longer has the desired effect, perhaps a regression.3) A new API is needed to cover this usage scenario.Any help is greatly appreciated!Best,Gabe

Hi,My software installs frameworks in the local domain (/Library/Frameworks) that are accessed from third-party apps. Some of these apps are simply code-signed, others are sandboxed. They are obviously signed by other companies, and so far there have been no problems on the part of DYLD in loading and executing code inside our frameworks. The loader is happy to continue looking for our framework outside the app container, in the case of sandboxed apps.What changes are necessary to ensure that our frameworks remain accessible from hardened apps? Hardened Runtime, to the best of my understanding, only allows executables to load code that has been code-signed by the same team, or by Apple. I also think that hardened runtime affects only executables, and yet when I enable the ENABLE_HARDENED_RUNTIME setting in Xcode on my framework targets (via xcconfig) it clearly influences the way they are signed, and suddenly these "hardened frameworks" fail to be loaded by third-party apps, even if these apps aren't yet hardened themselves. In what its perhaps the key to solving this issue, how can one mark non-app targets to enable the library-validation exception? Why would a non-hardened app fail to load code whose only difference may be a simple flag (kill,runtime) in its signature?Maybe I'm wrong to assume that non-app targets deserve any special treatment, but the fact remains that when I enable hardened runtime, our code simply stops being "seen" and loaded by DYLD, with all other variables remaining identical.Thank you!Gabe