sorry, should not have used the print. actually use Logger. Regardless, it never logs and the class reloads (resetting all variables to default). MyDockTilePlugin is run by the system's com.apple.dock.external.extra.arm64, if it is relevant.

Yes, that works. Discovered if not sandbox app, then the main app's UserDefaults can be read by CFPreferencesCopyAppValue in NSDockTilePlugin. In both cases, this is reading ~/Library/Preferences/.plist. If similar plist exists in the ~/Library/Containers/... it is not used. Is there a way the main app can check and read if there is a sandboxed version of the plist? Is there no way to communicate to the NSDockTilePlugin from the main app with notifications? This way I don't need the sandbox exception. Unrelated, but a deal breaker, in the same NSDockTilePlugIn class implementing func dockMenu() -> NSMenu? {} does display a dynamically generated NSMenu. However NsMenuItems' action: #selector(selectItem(:)) and @objc func selectItem( sender: NSMenuItem) { /* never called */ } doesn't fire. Instead the NSDockTilePlugIn plugin is reloaded. How do I capture the NSMenuItem.action?

Was this question answered? That is a way to share data between a sandboxed app and its Dock Tile plugin? If it helps, I only need need one way from app to Dock Tile plugin. Tried CFPreferencesCopyAppValue using the main app BundleID. Tried posting to NSWorkstation.shared.notificationCenter but Dock Tile plugin either returns nil or never receives notification. App Group isn't a option for Dock Tile plugin (it's built and included as a bundle)

also having crash in Xcode if I leave it open (either just open, or running a debug session searching for an intermediate memory leak). MacBookPro, M1 Pro. Xcode 15.0.1 and macOS 14.1.2. Translated Report (Full Report Below) Process: Xcode [2834] Path: /Applications/Xcode.app/Contents/MacOS/Xcode Identifier: com.apple.dt.Xcode Version: 15.0.1 (22266) Build Info: IDEApplication-22266000000000000~15 (15A507) App Item ID: 497799835 App External ID: 860559424 Code Type: ARM-64 (Native) Parent Process: launchd [1] User ID: 501 Date/Time: 2023-12-04 13:01:29.5210 -0800 OS Version: macOS 14.1.2 (23B92) Report Version: 12 Anonymous UUID: 94D9A24C-E6F8-6B77-2714-5078DBEBF8C7 Time Awake Since Boot: 180000 seconds System Integrity Protection: enabled Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000001, 0x0000000189fbe244 Termination Reason: Namespace SIGNAL, Code 5 Trace/BPT trap: 5 Terminating Process: exc handler [2834] Application Specific Information: BUG IN CLIENT OF LIBPLATFORM: os_unfair_lock is corrupt Abort Cause 15708772 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_platform.dylib 0x189fbe244 _os_unfair_lock_corruption_abort + 88 1 libsystem_platform.dylib 0x189fb9788 os_unfair_lock_lock_slow + 332 2 Foundation 0x18b1633f4 NSSetLongLongValueAndNotify + 84 3 DVTFoundation 0x104643910 closure #1 in DVTCoreDevice.endPreparationOperation(::) + 96 4 DVTFoundation 0x1045d2a48 thunk for @escaping @callee_guaranteed () -> () + 28 5 DVTFoundation 0x104577330 DVT_CALLING_CLIENT_BLOCK + 16 6 DVTFoundation 0x104577cf0 __DVTDispatchAsync_block_invoke + 48 7 libdispatch.dylib 0x189dddcb8 _dispatch_call_block_and_release + 32 8 libdispatch.dylib 0x189ddf910 _dispatch_client_callout + 20 9 libdispatch.dylib 0x189dedfa8 _dispatch_main_queue_drain + 984 10 libdispatch.dylib 0x189dedbc0 _dispatch_main_queue_callback_4CF + 44 11 CoreFoundation 0x18a0ab15c CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE + 16 12 CoreFoundation 0x18a068a80 __CFRunLoopRun + 1996 13 CoreFoundation 0x18a067c5c CFRunLoopRunSpecific + 608 14 HIToolbox 0x1945e4448 RunCurrentEventLoopInMode + 292 15 HIToolbox 0x1945e40d8 ReceiveNextEventCommon + 220 16 HIToolbox 0x1945e3fdc _BlockUntilNextEventMatchingListInModeWithFilter + 76 17 AppKit 0x18d842c54 _DPSNextEvent + 660 18 AppKit 0x18e018ebc -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 716 19 DVTKit 0x1033e8a9c -[DVTApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 300 20 AppKit 0x18d836100 -[NSApplication run] + 476 21 DVTKit 0x1033e7cbc -[DVTApplication run] + 60 22 AppKit 0x18d80d3cc NSApplicationMain + 880 23 dyld 0x189c110e0 start + 2360

I couldn't figure out how to do either one. So, after downloading, I simply open a Finder window with the update highlighted. I'll leave it up to the user to figure out the rest.

Turns out it has nothing to do with main.swift. I have a dictionary defined as dict : [ CGWindowID : NSWindow]. if you do dict.removeValue(forKey: key)?.close() this double deallocates the NSWindow if dict[key] was the last strong reference. Found this by instead of Run in Xcode, you do Profile and select Zombie and I found that this NSWindow reference count goes to -1. oops.

Nope, same crash as before....

Should have said "Status menu item" instead of "menu item". Regardless, changed main.swift to this: import Cocoa let app = NSApplication.shared let delegate = AppDelegate() withExtendedLifetime(delegate, {         app.delegate = delegate         app.run()         app.delegate = nil   }) seems to fix the occasional crash. This just forces a hard link to AppDelegate() so it doesn't get deallocated, apparently.

You can figure out which Desktops go with which Screens by comparing their CGRect (be careful, some CGRect has the vertical axis direction flipped- see https://entonos.com/index.php/2021/05/20/which-cgrect-was-that/). However, I have yet to figure out which Space corresponds to which Desktop (or vice versa). The best I've found is to ask CoreGraphics if a Desktop window is currently on screen. You then know that Desktop is on the current Space. Of course, you don't know which Space you're actually on.

There doesn't appear to be any public API to do this. Searching GitHub, there are some codes that do this, but they are using non-public API (e.g. using CGSCopyManagedDisplaySpaces)

let window : NSWindow? = nil ... window?.collectionBehavior = .canJoinAllSpaces // window will be in all Spaces window?.collectionBehavior = .moveToActiveSpace // when window is activated, move to active Space window?.collectionBehavior = .stationary // Expose doesn't affect window, so it stays visible and stationary, like the Desktop window window?.collectionBehavior = .managed // window participates in Spaces and Expose (i.e. normal window). there are other options....

Thanks for your response. https://feedbackassistant.apple.com/feedback/9824294 By definition the bug only occurs occasionally. Gave a link to the code and the line to comment out to get the problem to appear. Unfortunately, there is no deterministic way to reproduce.

One clue is when the code starts, it always captures the Desktop background images correctly. It seems to fail only when the NSWorkspace.activeSpaceDidChangeNotification is sent. Introducing a block for 0.25 seconds seems to insure the image capture succeeds. Would prefer a better option than blocking.