App Crashes At Startup From Testflight Build On iOS 13+ Only - xcode

Question

I recently submitted an app update to the App Store. The app runs well in Xcode (on device and simulator) for all versions of iOS including iOS 13+. I was surprised that it was rejected for crashing at startup. I checked using a Testflight build and it only crashed when ran on a device with iOS 13+. I could not replicate crashes from Xcode as it only crashes on the builds from Tesflight.
I've been researching online and see that this is not an uncommon issue, however, I can't identify what's the issue in my case. I've tried changing the build settings in Xcode and building from an older version of Xcode (10.2.1, doesn't work bc I use newer classes not compatible with anything lower than Xcode 11). I also tried changing the swift compiler optimization level to zero in the build settings. To upload a build to Tesflight, I am exporting the archive and uploading to iTunes Connect using Apple's Transporter app.
Using the crash log and podfile description below, can anyone identify the issue and/or make a suggestion on what's going wrong in the build.
Crash Log
OS Version: iPhone OS 13.2.3 (17B111)
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Triggered by Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
libsystem_kernel.dylib 0x00000001baaf7ec4 __pthread_kill + 8
libsystem_pthread.dylib 0x00000001baa13774 pthread_kill$VARIANT$mp + 112
libsystem_c.dylib 0x00000001ba967844 abort + 100
libc++abi.dylib 0x00000001baac07d4 __cxa_bad_cast + 0
libc++abi.dylib 0x00000001baac09c4 demangling_unexpected_handler+ 6596 () + 0
libobjc.A.dylib 0x00000001baa28258 _objc_terminate+ 25176 () + 124
libc++abi.dylib 0x00000001baacd304 std::__terminate(void (*)+ 58116 ()) + 16
libc++abi.dylib 0x00000001baacd29c std::terminate+ 58012 () + 44
libdispatch.dylib 0x00000001ba9cd198 _dispatch_client_callout + 36
libdispatch.dylib 0x00000001ba975fd8 _dispatch_block_invoke_direct$VARIANT$mp + 224
FrontBoardServices 0x00000001bfe4e4c8__FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ + 40
FrontBoardServices 0x00000001bfe4e194 -[FBSSerialQueue _queue_performNextIfPossible] + 404
FrontBoardServices 0x00000001bfe4e6bc -[FBSSerialQueue _performNextFromRunLoopSource] + 28
CoreFoundation 0x00000001bac7d7c4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24
CoreFoundation 0x00000001bac7d71c __CFRunLoopDoSource0 + 80
CoreFoundation 0x00000001bac7ceb4 __CFRunLoopDoSources0 + 180
CoreFoundation 0x00000001bac78000 __CFRunLoopRun + 1080
CoreFoundation 0x00000001bac778a0 CFRunLoopRunSpecific + 464
GraphicsServices 0x00000001c4bcf328 GSEventRunModal + 104
UIKitCore 0x00000001bed68740 UIApplicationMain + 1936
OnStation 0x0000000100a553ac main + 103340 (main.m:14)
libdyld.dylib 0x00000001bab02360 start + 4
Podfile
pod 'AWSCore'
pod 'AWSSNS'
pod 'AWSS3'
pod 'AWSCognito'
pod 'AWSCognitoIdentityProvider'
pod 'AWSCognitoSync'
pod 'AWSDynamoDB'
pod 'Flurry-iOS-SDK/FlurrySDK'
pod 'ArcGIS-Runtime-SDK-iOS', '100.2.1'
pod 'SVProgressHUD'
pod 'UICKeyChainStore'
pod 'RangeSeekSlider'
pod 'PubNub', '~> 4'
pod 'MessageKit'

Answer 1

I’m going to guess that this is due to a situation parallel to
iOS11 WKWebview crash due to NSInvalidUnarchiveOperationException
In other words, I'm guessing that you have something in your storyboard that comes from another framework that you need to link explicitly. That sort of thing often doesn’t crash from Xcode but does crash when launching independently.