I'm getting a crash for decoration views somewhere inside UIKitCore which is definitely out of my control – the code doesn't dequeue or care about instantiation of decoration views at all – all it does is inserting the registered layout attributes in the flow layout subclass, the rest of it (instantiation of the registered view & queuing/dequeuing) is provided by UIKit. I have a ton of crashes starting with iOS 18, not a single one on iOS 17 and prior. Call stack: Thread 1: "*** -[__NSArrayM objectAtIndex:]: index 4 beyond bounds [0 .. 3]" #1 0x000000018039c67c in -[__NSArrayM objectAtIndex:] () #2 0x0000000185a9aa54 in -[_UICollectionViewSubviewManager dequeueReusableViewWithReuseIdentifier:elementKind:elementCategory:] () #3 0x00000001851bc3cc in -[UICollectionView _dequeueReusableViewOfKind:withIdentifier:forIndexPath:viewCategory:] () #4 0x00000001851a6ab4 in -[UICollectionView _createPreparedSupplementaryViewForElementOfKind:atIndexPath:layout:withLayoutAttributes:applyAttributes:] () #5 0x00000001851af69c in -[UICollectionView _createVisibleViewsForSingleCategoryAttributes:limitCreation:fadeForBoundsChange:] () #6 0x00000001851af824 in -[UICollectionView _createVisibleViewsForAttributes:fadeForBoundsChange:notifyLayoutForVisibleCellsPass:] () #7 0x00000001851ad9c4 in -[UICollectionView _updateVisibleCellsNow:] () Array index out of bounds. Definitely not an array in reach, very internal operations. This is also preceded by the following warning thrown into Console: UICollectionView internal inconsistency: attempted to queue view that is already in the reuse queue. Collection view: <TripItineraryDayCollectionView: 0x146917400; baseClass = UICollectionView; frame = (0 0; 402 682); clipsToBounds = YES; autoresize = W+H; gestureRecognizers = <NSArray: 0x600000e5d770>; backgroundColor = UIExtendedGrayColorSpace 0 0; layer = <CALayer: 0x600000393440>; contentOffset: {0, 0}; contentSize: {402, 662}; adjustedContentInset: {0, 0, 0, 0}; layout: <TripItineraryDayViewLayout: 0x1463d6770>; dataSource: <TripItineraryDayView: 0x1463d6360; frame = (0 102; 402 682); clipsToBounds = YES; autoresize = W+H; backgroundColor = UIExtendedGrayColorSpace 0 0; layer = <CALayer: 0x6000003974a0>>>; view: <TransportLineDecorationView: 0x1059e51a0; baseClass = UICollectionReusableView; frame = (14 257; 54 69); userInteractionEnabled = NO; layer = <CALayer: 0x6000004180c0>>; layout attributes: <TransportDecorationViewLayoutAttributes: 0x1463e34a0; index path: (2-4); element kind: (TripItineraryDayTransportDecorationView); frame = (14 257; 54 69)> Disabling the decoration views makes the crash go away. Something has probably changed in iOS 18 which might have sense for cells (where providing the views in the delegate properly is mandatory) or supplementary views, yet it doesn't work really well with decoration views. It gives me the impression that supplementary and decoration views have been merged into one queue stack internally, but something's not right.

I'm getting a crash for decoration views somewhere inside UIKitCore which is definitely out of my control – the code doesn't dequeue or care about instantiation of decoration views at all – all it does is inserting the registered layout attributes in the flow layout subclass, the rest of it (instantiation of the registered view & queuing/dequeuing) is provided by UIKit. I have a ton of crashes starting with iOS 18, not a single one on iOS 17 and prior. Call stack: Thread 1: "*** -[__NSArrayM objectAtIndex:]: index 4 beyond bounds [0 .. 3]" #1 0x000000018039c67c in -[__NSArrayM objectAtIndex:] () #2 0x0000000185a9aa54 in -[_UICollectionViewSubviewManager dequeueReusableViewWithReuseIdentifier:elementKind:elementCategory:] () #3 0x00000001851bc3cc in -[UICollectionView _dequeueReusableViewOfKind:withIdentifier:forIndexPath:viewCategory:] () #4 0x00000001851a6ab4 in -[UICollectionView _createPreparedSupplementaryViewForElementOfKind:atIndexPath:layout:withLayoutAttributes:applyAttributes:] () #5 0x00000001851af69c in -[UICollectionView _createVisibleViewsForSingleCategoryAttributes:limitCreation:fadeForBoundsChange:] () #6 0x00000001851af824 in -[UICollectionView _createVisibleViewsForAttributes:fadeForBoundsChange:notifyLayoutForVisibleCellsPass:] () #7 0x00000001851ad9c4 in -[UICollectionView _updateVisibleCellsNow:] () Array index out of bounds. Definitely not an array in reach, very internal operations. This is also preceded by the following warning thrown into Console: UICollectionView internal inconsistency: attempted to queue view that is already in the reuse queue. Collection view: <TripItineraryDayCollectionView: 0x146917400; baseClass = UICollectionView; frame = (0 0; 402 682); clipsToBounds = YES; autoresize = W+H; gestureRecognizers = <NSArray: 0x600000e5d770>; backgroundColor = UIExtendedGrayColorSpace 0 0; layer = <CALayer: 0x600000393440>; contentOffset: {0, 0}; contentSize: {402, 662}; adjustedContentInset: {0, 0, 0, 0}; layout: <TripItineraryDayViewLayout: 0x1463d6770>; dataSource: <TripItineraryDayView: 0x1463d6360; frame = (0 102; 402 682); clipsToBounds = YES; autoresize = W+H; backgroundColor = UIExtendedGrayColorSpace 0 0; layer = <CALayer: 0x6000003974a0>>>; view: <TransportLineDecorationView: 0x1059e51a0; baseClass = UICollectionReusableView; frame = (14 257; 54 69); userInteractionEnabled = NO; layer = <CALayer: 0x6000004180c0>>; layout attributes: <TransportDecorationViewLayoutAttributes: 0x1463e34a0; index path: (2-4); element kind: (TripItineraryDayTransportDecorationView); frame = (14 257; 54 69)> Disabling the decoration views makes the crash go away. Something has probably changed in iOS 18 which might have sense for cells (where providing the views in the delegate properly is mandatory) or supplementary views, yet it doesn't work really well with decoration views. It gives me the impression that supplementary and decoration views have been merged into one queue stack internally, but something's not right.

This is pretty weird. While the synchronous variant with completionHandler gets called correctly on Main thread with a FrontBoardServices → UIScene call stack, the async variant get called on a random thread via swift_job_runImpl, assuming some behind-the-scene magic related to Concurrency causing this call to be…Tasked? Or anything calling it outside of Main thread. It affects us by causing crashes in production. We can temporarily fix this by downgrading to the synchronous variant with completion block, but I guess this should be escalated because it's causing issues from somewhere within the OS stack as the actual crash occurs in [UIApplication _updateSnapshotAndStateRestorationWithAction:windowScene:] which has to be somewhere around the thread-splitting moment, causing both our delegate call and the UIApplication call scheduled outside of Main thread. As this protocol is realated to UIKit-based protocol in the first place (even tho legacy one in Objective-C code base), it should be carefully held on Main thread to be in sync with @MainActor requirements of UIKit stuff. Cc @eskymo

You could try fr v yourVariable to print a frame variable description – at least that is mostly working in these cases. But I only came here to note down this is still an issue in Xcode 14.2, and it becomes more frustrating than printing when I f.e. want an override like thread return myVariable to perform an early return with a different value, getting the same error message instead. 😕

Guys, I like this approach better: xcrun simctl spawn booted defaults write -g SBChamoisWindowingEnabled -bool true 😉