“LLDB crash”

We're experiencing a similar UpdateCycle crash on iOS 26, though with a slightly different manifestation. Our crash occurs when displaying custom inputView keyboards on iPad devices. Crash Details: Exception: NSInternalInconsistencyException Message: Invalid parameter not satisfying: parentEnvironment != nil Location: UC::DriverCore::continueProcessing() at address 5472 in UpdateCycle library OS Version: iPadOS 26.1.0 (84.6% of crashes), also seen on 26.0.0 and 26.0.1 Device: 100% iPad devices (iPad Pro models, all in landscape orientation) Reproduction Context: The crash occurs when a custom UIView is set as textField.inputView and the text field becomes first responder on iPad. The crash happens during UpdateCycle's processing when it attempts to access the focus environment hierarchy. The custom keyboard view appears to be accessed by UpdateCycle before it's fully integrated into the focus hierarchy, resulting in a nil parentEnvironment. Key Observation

As i am facing also same crash into Xcode 26.1.1 (production build) and Testing on Xcode 26.2. and when i set usesClassicLoadingMode = false. its stopped preparing form request encoding. as i can see there is no data into httpbody. @DTS Engineer

First of all, App Review handles rules on a case by case basis, and usually will refrain from commenting on apps unless they are under review. So, for a final answer, you will need to submit your app. That said, these are my educated opinions. Although this is an off label use for a Notification Service Extension which is meant to be used for modifying content in newly delivered notifications, there are no strict rules for what you can do within the limits of an extension process. The process is short lived (30 seconds), memory restrained (24 MB), and bound by a number of sandbox rules that limit the abuse it can inflict on a user's device. The OS itself will enforce the rules, up to and including deciding to not launch the extension if it historically has been terminated for constantly crashing and/or being terminated due to not properly handling the constraints. Also keep in mind that these notifications have to be visible, and cannot be silent notifications. If you wanted to use silent notificatio

Following up here. This is of course infernally annoying to test and debug: there is no response from Apple on this issue or documentation about VPP vs App Store differences. Furthermore we can only test our attempted changes by submitting a new build to the app store, waiting for approval, and then trying to deploy to our devices with VPP. What we can confirm is: – This is happening with other watch companion apps installed through VPP. HOWEVER a couple of watch companion apps I tested DID work. I would be happy to provide a list for comparison to Apple if it's helpful. – We tried adjusting a bunch of project settings related to optimization, dead code stripping, symbol stripping, etc. following a mix of online and AI-based guidance about potential objective-c metadata issues flagged from the crash logs. Our app is primarily based on Swift 5 but it does target some objective-c pods and frameworks which haven't changed in years. This didn't help. – Our app used the old WatchKit architecture with both

Ok, I tested it now but the small app I added to my Feedback is still crashing. Currently on another area, but it is even no longer starting. I updated my Feedback with the requested information

Related to termination, my advice is to NEVER terminate your app. In the past, some of our Apps had a Decline button on the Terms of Service (ToS) screen that terminated the app, but App Review flagged that behavior as a Crash and blocked our app submission. Now our ToS screens only have an Accept button and the user can press that or they can close the app themselves; this always gets through App Review. For Age Verification, we have implemented similar: If an eligible user Declines to share their Age Range or is a minor without parental consent, they see a screen explaining that they are blocked with a link to App Store documents about the law and settings. There is no way out of that screen other than closing the app.

Same piece of code works in iOS 26.1 and earlier even a simple print crashes due to object no longer being available

This happens only in iOS 26.2 prior versions working fine . I’m listening for updates from sampleHandler triggered from web view. The object reference is released when the didReceive message is triggered self.webkit.configuration.userContentController.add(self, name: sampleHandler) self.webkit.load(request) func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage) { print(message.name) // works print(message.body) // crashes }

Apologies for the delayed update. Yesterday, we completed the rollout of your workaround solution, and our metrics indicate its effectiveness. The issue count has decreased significantly during the implementation, dropping from 6000 per day to 1000 per day as of today. Fabulous, that's great to hear and thank you for sharing concrete numbers. I was fairly confident it would work, but it's good to get independent confirmation. We would like to express our gratitude for the workaround solution you provided. You're very welcome. Currently, we have implemented the workaround only for incoming calls, as these were the primary source of issues observed in our app. We plan to extend the implementation to outbound calls as well. I don't know this for certain, but my guess is that the difference between the incoming/outgoing rate is mostly due to usage patterns and the details of your existing implementation. In particular, these two factors: I suspect most calls originate from the foreground (the user opening your ap