We are seeing an intermittent launch-time crash that increased sharply starting with iOS 18.4.
The affected app version is 1.4.8, which uses the UISceneDelegate-based lifecycle. The primary UIWindow is created and managed for the UIWindowScene provided to the scene delegate.
The OS-version distribution is very specific:
- iOS 18.3: no significant occurrence
- iOS 18.4 through the tested iOS 18.x releases: the crash occurs
- iOS 26: no occurrence observed
This comparison uses the same application binary. Therefore, the issue appears to be specific to the iOS 18.4–18.x UIKit/FrontBoard implementation rather than a general behavior on all newer iOS versions.
The crash occurs on the main thread:
EXC_BREAKPOINT (SIGTRAP)
0 FrontBoardServices -[FBSScene _sendUpdate:].cold.1 + 244
1 FrontBoardServices -[FBSScene _sendUpdate:].cold.1 + 244
2 FrontBoardServices -[FBSScene _sendUpdate:] + 1156
3 FrontBoardServices -[FBSScene _updateClientSettings:] + 552
4 FrontBoardServices -[FBSScene updateClientSettingsWithBlock:] + 124
5 UIKitCore -[FBSScene(UIApp) updateUIClientSettingsWithBlock:] + 168
6 UIKitCore __39-[UIWindow _noteOverlayInsetsDidChange]_block_invoke + 248
7 UIKitCore -[_UIAfterCACommitBlock run] + 72
8 UIKitCore -[_UIAfterCACommitQueue flush] + 168
9 libdispatch.dylib _dispatch_call_block_and_release + 32
10 libdispatch.dylib _dispatch_client_callout + 16
11 libdispatch.dylib _dispatch_main_queue_drain.cold.5 + 812
12 libdispatch.dylib _dispatch_main_queue_drain + 180
13 libdispatch.dylib _dispatch_main_queue_callback_4CF + 44
14 CoreFoundation __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16
15 CoreFoundation __CFRunLoopRun + 1980
16 CoreFoundation CFRunLoopRunSpecific + 572
17 GraphicsServices GSEventRunModal + 168
18 UIKitCore -[UIApplication _run] + 816
19 UIKitCore UIApplicationMain + 336
Another observed variant contains:
-[FBSScene _sendUpdate:].cold.1 + 244
Some reports continue through:
_UIApplicationFlushCATransaction _UIUpdateSequenceRun
while others continue through the main dispatch queue.
These reports appear to belong to the same crash family because they share the following path:
UIWindow _noteOverlayInsetsDidChange → FBSScene updateUIClientSettingsWithBlock: → FBSScene _updateClientSettings: → FBSScene _sendUpdate: → SIGTRAP
The crash occurs during cold launch, immediately after the root tab bar controller begins its first appearance.
In affected launches, the last application-side lifecycle marker we observe is:
MSKMainTabBarViewController.viewWillAppear(_:)
The process then terminates while UIKit is flushing the first appearance-related Core Animation transaction. No later application-side lifecycle marker is observed before termination.
We are treating viewWillAppear(_:) only as the last observable application-side marker. We do not assume that it directly causes the crash, because the failing UIWindow client-settings update is deferred until after the Core Animation commit.
There are no application frames in the crashing portion of the stack, and the app does not call any private API. The affected app version has already adopted the UISceneDelegate lifecycle, so this does not appear to be caused by the legacy UIApplicationDelegate-only compatibility lifecycle.
We have also observed the same FBSScene update path during a normal, non-crashing launch. The fatal reports differ in that FrontBoardServices triggers SIGTRAP inside _sendUpdate: or its compiler-generated cold path.
Because the client-settings update is deferred, the crash report does not identify which UIWindow operation, overlay-insets change, or FBSScene client setting originally produced the rejected update.
Has anyone encountered this exact FBSScene / _noteOverlayInsetsDidChange crash specifically on iOS 18.4–18.x?
In particular:
- Is this a known UIKit or FrontBoardServices regression introduced in iOS 18.4?
- Was this behavior changed or fixed in iOS 26?
- Which UIWindow or FBSScene client setting can cause this internal assertion?
- Is there a supported way to identify the UIWindow responsible for the rejected update?
- Are there known launch-time restrictions involving multiple UIWindows, key-window transitions, overlay insets, status-bar updates, or first-appearance transactions?
- Is there a recommended diagnostic profile, breakpoint, or logging option for capturing the original producer of the deferred update?