Thanks, my feedback report # is FB11845080.

Update, back to square 1... After switching code signing setting to Run Locally and back to Developer, and cleaning, the xcodebuild test command succeeds from the Terminal with this target. Still fails on Xcode Cloud however, including after a clean environment.

Additional info: I discovered that this is not just an issue with Xcode cloud, I can reproduce by just trying to run the testing target from the command-line locally, with xcodebuild -scheme (XCTest-scheme-name) test I get the same error shown above, which does not occur when I run the Test action from the IDE. In this case it's looking for the test file in the Debug .app build in derived data - and the file is actually there. Any suggestions? Is this a code-signing issue?

Many of us would like this! I'm mainly interested in use on Mac in NSImage, but it's the same issue - clearly NSImage has the capability since it can be created from an asset, why isn't it possible from loose .svg resource or svg NSData?

I think I answered my question by searching for "macos sandbox entitlement font auto-activation" online... I came across a troubleshooting article on limitations of Suitcase auto-activation, which won't work for Sandboxed apps (including Pages etc.), which unfortunately this forum won't let me post a link to for some reason. (Can't post the search link either, gah). So it would seem that auto-activation for sandboxed apps is unsupported. I will file a feedback request to ask for an entitlement for this feature, it's an important use case for designers that have large collections of fonts and Sandboxed apps shouldn't be denied the ability to leverage it. A global font auto-activation entitlement would make sense for apps that use typography in significant ways.

Also a follow-up: could there be an entitlement needed for auto-activation to work from a Sandboxed app?

Oh I also tried CTFontManagerSetAutoActivationSetting(kCTFontManagerBundleIdentifier, kCTFontManagerAutoActivationEnabled); which is supposed to set "global auto-activation", but no difference in behavior.

Thanks @edford for the answer - I was able to get it working as expected with my existing project by just adding the guards you mention to my source, so the symbols were not referenced for the not-yet-supported arm64 architecture - I used #if defined(__x86_64__)

After experimenting a bit I'm concluding that this just isn't really a use case supported by the weak-linking mechanism. It looks to me like any time you're embedding a framework in your bundle, the Xcode build sequence is going to try and link its symbols, and if it's a universal app this will mean for both architectures. There's no workaround here even if you're doing things like setting different search paths and bundle locations for x86 vs. arm64. I think to make this work we would need a 'stub library' implementation of the framework for arm64 to get us past the link errors, but I'm still not confident the right thing would happen at runtime (which is, x86 would link with the x86 framework, arm64 would behave as if the optional framework is missing). If anyone from Apple or with expertise can confirm this conclusion, that would be appreciated! And this question then becomes, more generally, what's the approach to have a universal app make use of a library/framework only available for one architecture - is XPC the only way?

Posting a reply to my own question here in case others encounter the same... While I'm not certain about the underlying design or when a non-precomposed RGBA setting would be possible or valid for a bitmap CGContext, that configuration turned out to not be needed. I'm now using this code to generate my CGContext - it's sRGB color space, and the alpha value is set to premultiplied. I was concerned this would mean I would somehow need to do some premultiplied calculation for the use of semi-opaque colors in my drawing code, but this turns out not to be the case - I can obtain an image with a transparent background, and also set partial alpha values in colors set for fill or stroke while drawing, and everything works properly. if let colorspace = CGColorSpace(name: CGColorSpace.sRGB) {       if let cgc = CGContext(data: nil,                     width: Int(pixelWidth),                     height: Int(pixelHeight),                     bitsPerComponent: 16,                     bytesPerRow: 0,                     space: colorspace,                     bitmapInfo: CGImageAlphaInfo.premultipliedLast.rawValue |                     CGBitmapInfo.byteOrder16Little.rawValue |                     CGBitmapInfo.floatComponents.rawValue) { ... So my answer in a nutshell is, if you want to use a bitmap CGContext for use in a Mac app with RGB color space that includes transparency, you can just use sRGB color space and premultiplied alpha values for the bitmapInfo parameter.