I have been able to fix the crash reported above by adding /usr/lib/swift to 'Runpath Search Paths'. I noticed that Xcode implicitly sets this path in my other small test project even though the corresponding entry in the build settings is empty. In my main project this did not happen. It would be nice if the app would print something meaningful instead of cryptically crashing. Normally if there is an issue with dynamic libraries a message is printed that the library could not be loaded. Here nothing of that sort happened.

I found out that the Swift compiler generates different type reference symbols depending on the -target compiler option and somehow this seems to play a role in our project. Will keep investigating.

Correction: the crash does not happen when the completion handler is called, but very early before the actual code of the Swift async function is executed. Meanwhile I have done tests with a minimal working example and it worked, there was no crash. So now I need to figure out why I get the crash in the large project.

I did a bit more digging in the disassembly and found that the error message passed to swift::fatalError() is "Failed to look up symbolic reference at %p - offset %d - symbol %s in %s\n" The final parameter is the executable path. The second last parameter is the following string: "symbolic _____Sg ScP" I get the feeling that the swift compiler attempts to bind to a symbol which the objc compiler didn't export. On the objC side the call simply looks the following: [object method:^() {}];

I tried that and it compiles but I get a crash exactly where the Swift function attempts to call the completion handler: 0x10a7f36cd <+93>: callq 0x10a7f3920 ; Swift._runTaskForBridgedAsyncMethod(__owned @Sendable () async -> ()) -> () at <compiler-generated> #1 0x00007ff814974f85 in pthread_kill () #2 0x00007ff814895b19 in abort () #3 0x00007ff82623dc21 in swift::fatalErrorv () #4 0x00007ff82623dcab in swift::fatalError () #5 0x00007ff826270746 in swift::ResolveAsSymbolicReference::operator() () #6 0x00007ff8262a3a32 in swift::Demangle::__runtime::Demangler::demangleSymbolicReference () #7 0x00007ff82629fd78 in swift::Demangle::__runtime::Demangler::demangleType () #8 0x00007ff8262777c7 in swift_getTypeByMangledNameImpl () #9 0x00007ff826272a8b in swift_getTypeByMangledName () #10 0x00007ff826272d87 in swift_getTypeByMangledNameInContextImpl () #11 0x000000010a7f34ab in __swift_instantiateConcreteTypeFromMangledName () #12 0x000000010a7f393c in _runTaskForBridgedAsyncMethod(_:) ()

Ok, just found another thread which actually provides functional workarounds: https://developer.apple.com/forums/thread/727123 Replacing ditto with zip works for us. For anyone considering doing the same please read the other thread as it contains additional infos which may be important in other cases.

We are having the same problem. Since altool notarization will be removed this fall we need a functional workaround soon. In our case the only reason we zip our .app is to send for notarization because altool and notarytool don't accept .app. We distribute only an installer which pulls/updates the .app from our servers. So what is the solution/workaround now? What's the status of the bug report anyway? The link provided above doesn't work for me (feedback not found).

Found the answer: App Store -> Settings has the button to sign out from a sandbox account on 13.4.1.

Tried again nine days later and it works now for us, though we didn't change anything. Thus I would assume it was a remote issue at Apple's side. Thus whenever this kind of problem appears the resolution seems to be to simply wait until it works again.

Same here (9th May 2022). I think the actual problem is that the OS doesn't show the login window where we can authenticate using our sandbox accounts. It worked for us recently (<2weeks), but this has always been an unreliable mechanism in my experience.

Thank you, that solved the problem!

We have resolved the problem. I am presenting details here in case other developers run into the same problem. First, not every Mac shows the same symptoms. We were unlucky to start testing with a Mac Mini (10.15) that did not trigger the keystrokes dialog which made it impossible for us to debug. Further tests with other Macs were successful and allowed us to localise the problem. In our case the offending code was located in an older version of SDL (2.0.8). The problem has been fixed in later versions, the two relevant commits are: Commit 1 - https://github.com/spurious/SDL-mirror/commit/8ace14e8244b7bc82881b7ee437ee3b17ab86985#diff-8779326b1912bdedc731ffe4bf485dc8 Commit 2 - https://github.com/spurious/SDL-mirror/commit/1ceddc5a20b954f7e4110e2cec2403576faf71ab#diff-906b3479f92876240ca6d12bbd1299f8 The first commit contains the actual fix for the privacy problem and the second is a correction, included here in case someone wants to patch older SDL versions instead of upgrading.

Hello eskimoYou are correct, disabling Hardened Runtime did not solve the problem.We are also not able to reproduce the dialog. I have installed the failing package on a 10.15 system where the application has never run before. It did not trigger the dialog. This means we are unable to progress.