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

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,

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,

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.