Still investigating.

Thanks Ed! I think this fixed the problem.

The problem happens when the total embedded frameworks + dynamic iOS embedded libraries exceeds 240. At least, that's what we've learned in our exchanges with Apple Developer Technical support so far. Converting cocoa pods to swift packages will reduce the number of embedded frames works in the app bundle. However, we still have not been able to overcome the bug in the Apple Linker at this time.

We believe Apple is aware of this issue and is investigating this as a possible but in Xcode 13.3.

We found that including the swiftlibFoundation.tbd files in the build phase allowed us to move past the foundation link error. However, dyld failed in a different location. Adding more .tbd files just produced errors in other places. I used otool -l to show the loading paths. I compared the output the working Xcode 13.2.1 built binary and the Xcode 13.3 and the only difference I found was the version number of Foundation. Load command 284      cmd LC_LOAD_DYLIB    cmdsize 64      name /usr/lib/swift/libswiftFoundation.dylib (offset 24)   time stamp 2 Wed Dec 31 16:00:02 1969    current version 69.0.0 compatibility version 1.0.0 Load command 284      cmd LC_LOAD_DYLIB    cmdsize 64      name /usr/lib/swift/libswiftFoundation.dylib (offset 24)   time stamp 2 Wed Dec 31 16:00:02 1969    current version 72.105.0 We are using cocoa pods to build the frameworks that get included in this library. I did an "nm" of the framework that was causing the problem and found the missing symbol is the first symbol in the file. (undefined) external _$s10Foundation10URLRequestV10httpMethodSSSgvs (from libswiftFoundation) However, this symbol also appears at the top of the working Xcode 13.2.1 built library as well.

To be more clear here, Xcode is not crashing, but our iOS app is crashing when trying to run with Xcode 13.3. When compiling the same code with Xcode 13.2.x, the app does not crash.