iOS crash: EXC_BAD_ACCESS in iOS 26+ when mouting/dismounting WebView

Question

Created Apr ’26

Replies 1

Boosts 0

Participants 2

I'm experiencing a native crash on iOS 26+ with WebKit with title: EXC_BAD_ACCESS (KERN_INVALID_ADDRESS).

The stack trace points to UIKit/WebKit animation and context menu handling, and the crash occurs while a WebView is presented or dismissed.

          Crashed: com.apple.main-thread
0  WebKit                         0x7bcfac <redacted> + 12
1  WebKit                         0xaf5c34 <redacted> + 84
2  UIKitCore                      0x34ebdc -[_UIContextMenuAnimator performAllCompletions] + 248
3  UIKitCore                      0x7f997c block_destroy_helper.72 + 1840
4  UIKitCore                      0x7fb4b4 objectdestroy.36Tm + 88
5  UIKitCore                      0x7ad354 objectdestroy.3Tm + 30500
6  UIKitCore                      0x5c0e5c __swift_memcpy192_8 + 4352
7  UIKitCore                      0x21944 block_copy_helper.374 + 40
8  UIKitCore                      0x1dc174 -[_UIGroupCompletion _performAllCompletions] + 160
9  UIKitCore                      0x35d0c4 -[_UIGravityWellEffectBody .cxx_destruct] + 180
10 UIKitCore                      0x215018 -[UIScrollView _contentLayoutGuideIfExists] + 72
11 UIKitCore                      0x943e4 NSStringFromUIEdgeInsets + 304
12 UIKitCore                      0x94348 NSStringFromUIEdgeInsets + 148
13 UIKitCore                      0x8f598 __UIVIEW_IS_EXECUTING_ANIMATION_COMPLETION_BLOCK__ + 36
14 UIKitCore                      0x1995d8c -[UIViewAnimationBlockDelegate _sendDeferredCompletion:] + 92
15 libdispatch.dylib              0x1adc _dispatch_call_block_and_release + 32
16 libdispatch.dylib              0x1b7fc _dispatch_client_callout + 16
17 libdispatch.dylib              0x38b10 _dispatch_main_queue_drain.cold.5 + 812
18 libdispatch.dylib              0x10ec8 _dispatch_main_queue_drain + 180
19 libdispatch.dylib              0x10e04 _dispatch_main_queue_callback_4CF + 44
20 CoreFoundation                 0x6a2b4 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16
21 CoreFoundation                 0x1db3c __CFRunLoopRun + 1944
22 CoreFoundation                 0x1ca6c _CFRunLoopRunSpecificWithOptions + 532
23 GraphicsServices               0x1498 GSEventRunModal + 120
24 UIKitCore                      0x9ddf8 -[UIApplication _run] + 792
25 UIKitCore                      0x46e54 UIApplicationMain + 336
26 -                              0xedf88 main + 24 (AppDelegate.swift:24)
27 ???                            0x196686e28 (Missing)

Answered by DTS Engineer in 888105022

Thanks for posting the crash log. The stack you've shown isn't enough on its own to point at a specific cause — the WebKit frames are still <redacted>, and there's no information about the WebView itself or what triggers the crash. Before going further, could you share the following?

The WebView setup — how you create, configure, and present or dismiss the WebView. The relevant view controller code, your WKWebViewConfiguration, and the navigation flow that leads to the crash.
Reproduction steps — what does someone do (or what does the app do) right before the crash? The frame _UIContextMenuAnimator performAllCompletions suggests a long-press preview menu may be involved. Does the crash require a context menu to have opened first?
Frequency and conditions — does this happen in your own testing, or only in production via crash analytics? Specific iOS version (26.0, 26.1, 26.4)? Specific devices? Any particular network or content state?
The original crash report, not a forwarded copy — those <redacted> WebKit frames are usually the result of Apple's crash export pipeline stripping symbols before the log leaves the device. If the report you have was forwarded through anything other than Apple's own delivery channel, the WebKit symbols may have been redacted on the way out and no amount of local dSYM application will bring them back. To see the unredacted stack, you need to get the original report:
- For TestFlight or App Store builds: Xcode → Window → Organizer → Crashes. Apple delivers symbolicated crash reports there directly to the developer who shipped the build.
- For your own development device: on the device, Settings → Privacy & Security → Analytics & Improvements → Analytics Data, then transfer the .ips file to a Mac and open it in Xcode (or symbolicate against your dSYMs).
The original report is what we'd need to see real function names where those <redacted> frames are now.

Once we can see what's at the top of the stack and how your app drives the WebView, we can start narrowing this down. Post back here when you have those pieces.

Boost

Answer 1

DTS Engineer OP

Apple

18h

Recommended

Thanks for posting the crash log. The stack you've shown isn't enough on its own to point at a specific cause — the WebKit frames are still <redacted>, and there's no information about the WebView itself or what triggers the crash. Before going further, could you share the following?

The WebView setup — how you create, configure, and present or dismiss the WebView. The relevant view controller code, your WKWebViewConfiguration, and the navigation flow that leads to the crash.
Reproduction steps — what does someone do (or what does the app do) right before the crash? The frame _UIContextMenuAnimator performAllCompletions suggests a long-press preview menu may be involved. Does the crash require a context menu to have opened first?
Frequency and conditions — does this happen in your own testing, or only in production via crash analytics? Specific iOS version (26.0, 26.1, 26.4)? Specific devices? Any particular network or content state?
The original crash report, not a forwarded copy — those <redacted> WebKit frames are usually the result of Apple's crash export pipeline stripping symbols before the log leaves the device. If the report you have was forwarded through anything other than Apple's own delivery channel, the WebKit symbols may have been redacted on the way out and no amount of local dSYM application will bring them back. To see the unredacted stack, you need to get the original report:
- For TestFlight or App Store builds: Xcode → Window → Organizer → Crashes. Apple delivers symbolicated crash reports there directly to the developer who shipped the build.
- For your own development device: on the device, Settings → Privacy & Security → Analytics & Improvements → Analytics Data, then transfer the .ips file to a Mac and open it in Xcode (or symbolicate against your dSYMs).
The original report is what we'd need to see real function names where those <redacted> frames are now.

Once we can see what's at the top of the stack and how your app drives the WebView, we can start narrowing this down. Post back here when you have those pieces.

0