Our app contains several 3rd-party dylibs, which we've successfully bundled in our app and signed for Developer ID distribution many times. I just added a new 3rd-party dylib (libusd_ms.dylib, built from source) which expects to find a directory of resources (directory name "usd") in the .app/Contents/Frameworks directory. So I added the directory to my Copy Frameworks Build Phase with Code Sign On Copy checked. Debug and Profile builds work as expected. Archived builds have the directory in /Frameworks. Checking the problem file (schema.usda) with codesign-d confirms it was signed in the Archive. But exporting the Archive to disk for distribution gives "Code Signing Failed" and points me to IDEDistributionPipeline.log, which reports: 2023-01-19 21:20:11 +0000 /var/folders/v3/j6lzlhcx34j_4v5w9_ztmfp80000gp/T/XcodeDistPipeline.~~~UzBjEy/Root/Applications/Reflex.app: code object is not signed at all In subcomponent: /private/var/folders/v3/j6lzlhcx34j_4v5w9_ztmfp80000gp/T/XcodeDistPipeline.~~~UzBjEy/Root/Applications/Reflex.app/Contents/Frameworks/usd/usdShade/resources/usdShade/schema.usda I confirmed by running codesign -d that the copy of that file in this "pipeline" folder is not signed, but how do I fix that if I've signed the original of the file in my app bundle? Xcode 14.2 on macOS 13.1

We are developing a graphics app that uses OpenGL extensively. We've developed a crash issue since we switched to CALayer-based OpenGL rendering per Apple sample code CALayerEssentials. When certain of our OpenGL layer-containing windows are moved between two screens, the app crashes (on Catalina). I replicated the issue in a pared-down, updated version of CALayerEssentials. In our version, because we will have multiple OpenGL views sharing resources, we use a shared context. Is there something we can do differently to avoid the crash while still sharing OpenGL resources? // You would typically override this method if you needed to specify a share context to share OpenGL resources. // This is also an ideal location to do any initialization that is necessary for the context returned -(CGLContextObj)copyCGLContextForPixelFormat:(CGLPixelFormatObj)pixelFormat { #if 0 // ORIGINAL SAMPLE CODE // Default handling is fine for this demonstration. CGLContextObj superContext = [super copyCGLContextForPixelFormat:pixelFormat]; return superContext; #else // OUR VERSION TO SHARE OPENGL RESOURCES // THIS LEADS TO CRASH WHEN WINDOW IS MOVED BETWEEN SCREENS if (!_dfContext) { _dfContext = [super copyCGLContextForPixelFormat:pixelFormat]; } return _dfContext; #endif } Our pared-down and updated version of CALayerEssentials source may be downloaded here. Here's the backtrace: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 GLEngine 0x00007fff3eb701a2 gleLookupHashObject + 13 1 GLEngine 0x00007fff3eb6fe3e gleBindTexture + 59 2 GLEngine 0x00007fff3eb6fdc6 glBindTexture_Exec + 405 3 com.apple.QuartzCore 0x00007fff3fbd8a0c CA::(anonymous namespace)::IOSurface::framebuffer() + 84 4 com.apple.QuartzCore 0x00007fff3fbd8907 CA::(anonymous namespace)::IOSurface::attach() + 83 5 com.apple.QuartzCore 0x00007fff3fbd8461 CAOpenGLLayerDraw(CAOpenGLLayer*, double, CVTimeStamp const*, unsigned int) + 1868 6 com.apple.QuartzCore 0x00007fff3fbd7b3a -[CAOpenGLLayer _display] + 580 7 com.apple.QuartzCore 0x00007fff3fb3bcad CA::Layer::display_if_needed(CA::Transaction*) + 757 8 com.apple.QuartzCore 0x00007fff3fb19fca CA::Context::commit_transaction(CA::Transaction*, double) + 334 9 com.apple.QuartzCore 0x00007fff3fb18bb4 CA::Transaction::commit() + 644 10 com.apple.AppKit 0x00007fff315f42f1 __62+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayLink]_block_invoke + 266 11 com.apple.AppKit 0x00007fff31d12c20 ___NSRunLoopObserverCreateWithHandler_block_invoke + 41 12 com.apple.CoreFoundation 0x00007fff341f17bc __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 13 com.apple.CoreFoundation 0x00007fff341f16ec __CFRunLoopDoObservers + 457 14 com.apple.CoreFoundation 0x00007fff341f0c84 __CFRunLoopRun + 884 15 com.apple.CoreFoundation 0x00007fff341f02b3 CFRunLoopRunSpecific + 466 16 com.apple.HIToolbox 0x00007fff32e0baad RunCurrentEventLoopInMode + 292

I've recently noticed that use of NSSavePanel in our macOS application causes one or more warnings to the console, like this: WARNING: <NSSavePanel: 0x171a466d0> found it necessary to prepare implicitly; please prepare panels using NSSavePanel rather than NSApplication or NSWindow. WARNING: <NSSavePanel: 0x171a466d0> found it necessary to start implicitly; please start panels using NSSavePanel rather than NSApplication or NSWindow. WARNING: <NSSavePanel: 0x171a466d0> running implicitly; please run panels using NSSavePanel rather than NSApplication. We are running the save panel modally, as supported by NSSavePanel.h: NSSavePanel * panel = [NSSavePanel savePanel]; [panel setTitle:@"Record Movie"]; ... NSModalResponse rtn = [panel runModal]; In other code, we use RunModalSheetForDialog() which gives a similar warning: <NSSavePanel: 0x7f9c70224810> running implicitly; please run panels using NSSavePanel rather than NSApplication. Why these warnings, and what can I do about it?