Thank you. Particularly for the step-by-step, very informative. The algorithm should have insured arrangements[name] is not nil well before func restore was called (therefore no test to confirm). Appreciate your time and efforts- never fun looking at another's code. Also understand your concerns about concurrency. They are valid.

That's what I did. It resolved to a line which tried to use the object to access the AppleScript. Before Apple's change, it could not reach that code. I create the object which loads AppleScriptObjC/script on the .userInteractive queue. I then dispatch back to the main queue. There I test if the object is nil or if there is a problem calling the script. If so, I display error sheet and quit. Otherwise, UserDefaults is loaded and startup finishes accordingly. These tests to check if AppleScriptObjC/script correctly loaded failed to work. Messy, but worked for over five years, until now. btw, the picture of the Devices and Simulations is out-of-date along with the instructions. I did cli. You have the crash report, GitHub has the actual source for that version in Releases. Uploaded .dSYM also. (https://github.com/com-entonos/Desktop-Icon-Manager/releases/tag/4.5.1) Appreciate the interest,

With all due respect, I think this is the same issue. bwill found his code was hanging if he didn't load AppleScriptObjC on the main thread. He did not crash most likely because he was waiting for the load that never happened. In my case, the algorithm 'insured' AppleScriptObjC was loaded before use and so I never tested if it was actually loaded. My app requires access to an AppleScript to do anything else. It appears bwill was using AppleScript for two rather minor things. In other words, I crash because I assumed there would be no problem loading. In my case, I think that is correct (if it doesn't load, the app is useless). I could capture the problem, but it makes more sense to crash so a Crash Report can be generated. That is, in this case the Crash Report did tell me AppleScriptObjC was still loading- something that should not have happened. Regardless, the solution was to load AppleScriptObjC and script on the main thread. Afterwards, the script can be used from any thread. Thanks,

No, crash. Report at end. 'atos' told me it was the 'restore' function and the line was using the script when the crash occurred. Logically, AppleScriptObjC/script should have finished loading before calling 'restore'. For the user, AppleScriptObjC had not finished loading. Crashing is fine by me, if the app was in that state. User sent me a word document w/ copy/paste so you get just the text. user crash

Quinn- A user was reporting the crash which I could not reproduce locally. We are both running macOS 26.3 right after it came out (I upgraded to macOS 26 mostly because of this- rounded corners are annoying/wasteful, just saying). Code is on GitHub (https://github.com/com-entonos/Desktop-Icon-Manager) in particular ViewController.swift, line 114. This works for the user. The previous version of that file crashes at start for the user. The way the code crashed I could not explain (it was in a routine it should not be possible to reach at startup) unless there was UserDefaults value that changed. I had the user use 'defaults delete ...' to delete the relevant plist file, so I really don't know what the state of his machine was. If he had 'Automatically restore at start' checked, it would explain it. Default is not checked. He was at an university so who knows what IT does... Good luck.

Confirmed you must load on the main thread. But you can call AppleScript from any thread after. The bit in my custom class which must be initialized on main: init() { Bundle.main.loadAppleScriptObjectiveCScripts() let DIMBridgeClass: AnyClass = NSClassFromString("ApplescriptBridge")! self._DIM = DIMBridgeClass.alloc() as? DIMBridge } where ApplescriptBridge is the script name and @objc(NSObject) protocol DIMBridge { .. } allows access to AppleScript variables and functions.

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.