I use NSLog and I cant see the whole log in the console app

I dont agree that in all cases the problem are the tests. For Instance we use OCmock and create partial mocks for objects. and that's cause us a lot of issues when different tests mocking/using the same objects simultaneously. When u have a multiple developers trying to test same region, there is good chance of race conditions between the tests accessing same area of code/ resources what what won't really happen in simple user flow

any progress on it ?

Pendo SDK had a great progress in coddlers analytics for swiftui: https://github.com/pendo-io/pendo-mobile-sdk/blob/master/ios/pnddocs/swiftui.md

Same issue

Same issue

Having the same(similar) issue: the SDK is build with Xcode14 but for is failed to build on Xcode 13. "Failed to build module 'OURSDK'; this SDK is not supported by the compiler (the SDK is built with 'Apple Swift version 5.7 (swiftlang-5.7.0.120.1 clang-1400.0.28.1)', while this compiler is 'Apple Swift version 5.6.1 (swiftlang-5.6.0.323.66 clang-1316.0.20.12)'). Please select a toolchain which matches the SDK The module stability is from 5.1 so there should not be an issue

Same issue here

Having the same issue, any progress iOS 15.2

Any progress on it?

Xcode 13.2.1 the problem still exists (swift code): why? :( `po $arg1 error: <EXPR>:8:1: error: cannot find '$arg1' in scope $arg1 ^~~~~ (lldb) register read -A General Purpose Registers:        rax = 0x0000000000000036        rbx = 0x00007fa8a0f081e0       arg4 = 0x0000000000000000       arg3 = 0x0000000000000000       arg1 = 0x00007fa8a0f081e0       arg2 = 0x00007fff6dd7499e         fp = 0x00007ffeef3b6f30         sp = 0x00007ffeef3b6f20       arg5 = 0x00007fff864a40a0  libsystem_pthread.dylib`_pthread_keys       arg6 = 0x00007fa8a483bc90        r10 = 0x00000001008562a8  (void *)0x0000000100857588: _TtC6XXX29XXXViewController        r11 = 0x00007fff248cd65c  UIKitCore`-[UIViewController(UIKitManual) release]        r12 = 0x0000000000000278        r13 = 0x00007fa8a0f081e0        r14 = 0x0000000000000000        r15 = 0x00007fff201833c0  libobjc.A.dylib`objc_msgSend         pc = 0x000000010084a8e4  XXX`XXX.XXX.Controller.setup() -> () + 20 at ViewController.swift:33:9      flags = 0x0000000000000202         cs = 0x000000000000002b         fs = 0x0000000000000000         gs = 0x0000000000000000 (lldb) po $arg1 error: <EXPR>:8:1: error: cannot find '$arg1' in scope $arg1 ^~~~~`

@eskimo Thanks a lot, indeed the issue was caused by sort of complex dead lock, its almost like u described just in my case the background thread after getting the lock was asking main thread in sync way to execute some logic , mean-while a main thread also asked the same lock, but the background thread never released his lock as main thread was not available to execute his logic

@eskimo Sorry I didn't find how to add additional crash log to the initial question so I am adding it here TerminationReasonObfuscated.txt How do I reproduce this kind of issues on my side? I mean I found some time consuming code that maybe responsible for it (its not part of the stack trace), but even though I add additional long calculation into it, it doesn't crash. Maybe it happens only on device? production mode? Thanks

Thanks @eskimo ok I got an additional crash report from the customer with some more insight. The previous crash report is almost identical to the current one (so I will attach the most significant difference ). Its also reproducible on iOS 14.6 Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Termination Reason: Namespace SPRINGBOARD, Code 0x8badf00d Termination Description: SPRINGBOARD, <RBSTerminateContext| domain:10 code:0x8BADF00D explanation:scene-update watchdog transgression: application<com.glip.mobile.rc>:2931 exhausted real (wall clock) time allowance of 10.00 seconds | ProcessVisibility: Background | ProcessState: Running | WatchdogEvent: scene-update | WatchdogVisibility: Background | WatchdogCPUStatistics: ( | "Elapsed total CPU time (seconds): 7.820 (user 4.990, system 2.830), 13% CPU", | "Elapsed application CPU time (seconds): 0.091, 0% CPU" | ) reportType:CrashLog maxTerminationResistance:Interactive> Triggered by Thread: 0 Now it seems that what cause the crash is some additional work that happens before the work during when the crash was reported. I have read the following apple explanation But I am still not 100% sure, in addition I noticed: Elapsed application CPU time (seconds): 0.091, 0% CPU - that's look like a plausible time to avoid the crash BUT maybe it doesn't take in to account some additional previous time . Any insights are welcome

Thanks Submitting crash report: FB9523755 (Crash in ios15 beta EXC_CRASH (SIGKILL))