My non-cloud Developer ID certificate will expire soon, and my account also has a cloud-managed Developer ID Certificate. My Mac application build workflow uses Archiving, so the cloud cert should be fine for that. But my workflow also signs bundled apps, such as Sparkle framwork's Autodupate app, using the codesign tool. Is it correct that codesign only uses certificates from the local Keychain, and so cannot use a Cloud-managed Developer ID certificate? Before I manually renew the non-cloud Developer ID certificate, I want to make sure I'm not missing some easier method. Thanks.

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?