LLDB crash

Thank you for the post and detailed description of the issue. I have checked both versions of the app on the App Store and TestFlight. Both versions have the same version 4.0.1 and the same build number 340. Therefore, both versions appear to be the same app. However, the crash files indicate that there is a part in your code that calls abort. Unfortunately, since it is your code and symbols, I cannot pinpoint the exact location of the crash at this time. It appears that frame 8 is the culprit. I recommend downloading the app from TestFlight and using your Xcode with your symbols to identify the crash or abort. I am happy to assist you in loading your app symbols to diagnose the issue. 8 dbMobil_DevExpress 0x106d60b88 Please let me know how I can help. However, I believe that if you use Xcode, connect the device, and debug the app, you will be able to resolve the issue quickly. I hope this information is helpful to you. Albert Pascual
  Worldwide Developer Relations.

The crash log, an IPS file, indicates a crash occurred at a specific time, with the exception backtrace pointing to _terminateAppIfThereAreUnhandledVoIPPushes. So, this crash ONLY occurs for one reason, which is that your app received a voip push and failed to report a new incoming call, as the API contract requires. There's no other way this crash can occur. However, cross-reference with the SysDiagnose logs, there is no corresponding process or activity for the application at the reported crash time. The app was not active, nor was it woken up by any event. I'm not sure where you were looking, but there is plenty of syslog data about the crash. Starting from the crash log, the crash occurred at: Date/Time: 2025-08-29 16:21:32.6696 +0530 ... Terminating Process: [283] And the time and pid (283) match up with the crash log embedded the system log archive: 2025-08-29 16:21:32.669000+0530 283 : { In terms of the general flow of th

We’re still seeing a dyld crash at app startup on iOS 18.1.1 (22B91). The crash happens before our app binary is even mapped (main_executable_path_missing in crash log). Device: iPhone 12 Pro (iPhone13,3) iOS: 18.1.1 (22B91) Distribution: App Store build Feedback filed: FB20068209 Restaring the iPhone sometimes resolves it, but it’s happening in production and has been reported by multiple users. To what version (if any) should we recommend users to upgrade until this is solved?

Should be noted I can use NSGlassEffectView perfectly fine. It's just any new SwiftUI symbols that crash immediately.

We do allow you to embed multiple network extensions in the same app. That’s true on all our platforms, although the mechanics vary based on whether you’re using a system extension (sysex) or an app extension (appex). For more info about what packaging is supported on what platforms, see TN3134 Network Extension provider deployment. It sounds like you’re using a sysexes, and that presents a decision point: You can have multiple independent sysex, each with a single NE provider. Or you can have a single sysex with multiple NE providers. The latter is generally easier to wrangle. In that case you have a single sysex target with multiple NE provider subclasses linked into the resulting executable, and then list all of those in the NEProviderClasses dictionary in your sysex’s Info.plist. IMPORTANT If you set things up this way there’s a single sysex process and all of your NE providers run within that. This has pros (you can share data between them) and cons (if one crashes, they all crash). Of

clean your build folder it shouldn't do that. The assertion error doesn't have to do anything with the crash.

Yes! If you Quick Look that in the Finder, you’ll get a human readable version of it. My comments below are based on that. The presence of the Last Exception Backtrace section indicates that your app crashed due to an unhandled language exception. Looking at the associated backtrace I see this: Last Exception Backtrace: 0 CoreFoundation … __exceptionPreprocess + 164 1 libobjc.A.dylib … objc_exception_throw + 88 2 CoreFoundation … +[NSObject(NSObject) _copyDescription] + 0 3 CoreFoundation … ___forwarding___ + 1492 4 CoreFoundation … _CF_forwarding_prep_0 + 96 5 UnityFramework … 0x10b164000 + 26948776 6 UnityFramework … 0x10b164000 + 26953748 7 UnityFramework … 0x10b164000 + 26918904 8 UnityFramework … 0x10b164000 + 26917296 9 UnityFramework … 0x10b164000 + 26902496 10 UnityFramework … 0x10b164000 + 27452572 11 libdispatch.dylib … _dispatch_call_block_and_release + 32 Frame 11 is Dispatch calling a block on a queue. Frames 10 through 5 are your third-party runtime. Frames 4 through 0 are a telltale pa

This came up on Swift Forums and I wanted to drop some links here, just for the record: How to prevent crash due to Swift Runtime initializing os_log on macOS? is the Swift Forums thread itself. A fork() in the road [1] is a research paper that offers valuable insight into the overall issue. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] https://www.microsoft.com/en-us/research/wp-content/uploads/2019/04/fork-hotos19.pdf