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!