Consider this:
Exception Type: EXC_BREAKPOINT (SIGTRAP)
This typically means your app trapped, that is, it detected a problem and crashed itself. In Swift code this might be, for example, because you force unwrapped an option that’s nil.
Now look at the crashing thread backtrace:
Thread 5 Crashed:: Dispatch queue: com.apple.NSURLSession-delegate
0 mobile Access …
1 mobile Access …
2 mobile Access …
3 mobile Access …
4 CFNetwork … __46-[NSURLSession getTasksWithCompletionHandler:]_block_invoke_2 + 216 /Library/Caches…
5 CFNetwork … __67-[__NSURLBackgroundSession _onqueue_getTasksWithCompletionHandler:]_block_invoke + …
6 libdispatch.dylib … _dispatch_call_block_and_release + 32 /Library/Caches/com.apple.xbs/Sources/libdispatch…
Frame 4 shows that your app called -[NSURLSession getTasksWithCompletionHandler:]
and the system is now calling you back with the results. Frames 3 through 0 are all your code. These are not symbolicated, so it’s hard to say what went wrong. I recommend that you symbolicate your crash report and investigate from there. For advice on ow to do that, see Adding Identifiable Symbol Names to a Crash Report.
Finally, a significant number of ‘crashes only in TestFlight’ problems are actually the result of a crash in your release build. See Testing a release build.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"