hello, I have been receiving crash reports on iPadOS 26.1, When UITrackingElementWindowController viewDidDisappear The feedback associated with this post is: FB20986398 and Exception Exception 'Cannot remove an observer <PKTextEffectsWindowObserver 0x10854cbe0> for the key path "frame" from <UITextEffectsWindow 0x10827ca00> because it is not registered as an observer.' #1 0x0000000183529814 in objc_exception_throw () #2 0x00000001845065a4 in -[NSObject(NSKeyValueObserverRegistration) _removeObserver:forProperty:] () #3 0x00000001845069c8 in -[NSObject(NSKeyValueObserverRegistration) removeObserver:forKeyPath:] () #4 0x00000001845068e0 in -[NSObject(NSKeyValueObserverRegistration) removeObserver:forKeyPath:context:] () #5 0x00000001cb22e894 in -[PKTextEffectsWindowObserver dealloc] () #6 0x000000018beafb28 in _setInteractionView () #7 0x000000018d81e8b8 in -[UIView(Dragging) removeInteraction:] () #8 0x00000001cb216448 in -[PKTextInputInteraction willMoveToView:] () #9 0x000000018beafb1c in _setInteractionView () #10 0x000000018d81e8b8 in -[UIView(Dragging) removeInteraction:] () #11 0x000000018d5ab094 in -[UIEditingOverlayViewController _removeInteractions] () #12 0x000000018cb166a8 in -[UIViewController _setViewAppearState:isAnimating:] () #13 0x000000018cb16d70 in __52-[UIViewController _setViewAppearState:isAnimating:]_block_invoke_2 () #14 0x000000018cb16c10 in __52-[UIViewController _setViewAppearState:isAnimating:]_block_invoke () #15 0x000000018655ef78 in __NSARRAY_IS_CALLING_OUT_TO_A_BLOCK__ () #16 0x00000001866b4a24 in -[__NSArrayI enumerateObjectsWithOptions:usingBlock:] () #17 0x000000018cb16a44 in -[UIViewController _setViewAppearState:isAnimating:] () #18 0x000000018cb1753c in -[UIViewController __viewDidDisappear:] () #19 0x000000018cb17638 in -[UIViewController _endAppearanceTransition:] () #20 0x000000018ca2401c in __48-[UIPresentationController transitionDidFinish:]_block_invoke () #21 0x000000018ca23cd0 in -[UIPresentationController transitionDidFinish:] () #22 0x000000018ca2d720 in -[_UICurrentContextPresentationController transitionDidFinish:] () #23 0x000000018ca27608 in __77-[UIPresentationController runTransitionForCurrentStateAnimated:handoffData:]_block_invoke.106 () #24 0x000000018cb31fec in -[_UIViewControllerTransitionContext completeTransition:] () #25 0x000000018d7f09bc in -[UITransitionView notifyDidCompleteTransition:] () #26 0x000000018d7f0750 in -[UITransitionView _didCompleteTransition:] () #27 0x000000018bf1c2a4 in __UIVIEW_IS_EXECUTING_ANIMATION_COMPLETION_BLOCK__ () #28 0x000000018d817960 in -[UIViewAnimationBlockDelegate _didEndBlockAnimation:finished:context:] () #29 0x000000018d7f7168 in -[UIViewAnimationState sendDelegateAnimationDidStop:finished:] () #30 0x000000018d7f75cc in -[UIViewAnimationState animationDidStop:finished:] () #31 0x000000018d7f763c in -[UIViewAnimationState animationDidStop:finished:] () #32 0x0000000186fedda4 in run_animation_callbacks () #33 0x000000010365e2d0 in _dispatch_client_callout () #34 0x000000010367f4c0 in _dispatch_main_queue_drain.cold.5 () #35 0x0000000103654778 in _dispatch_main_queue_drain () #36 0x00000001036546b4 in _dispatch_main_queue_callback_4CF () #37 0x00000001865b42c8 in __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ () #38 0x0000000186567b3c in __CFRunLoopRun () #39 0x0000000186566a6c in _CFRunLoopRunSpecificWithOptions () #40 0x0000000226ee5498 in GSEventRunModal () #41 0x000000018bf2aba4 in -[UIApplication _run] () #42 0x000000018bed3a78 in UIApplicationMain ()

Scenario: Typing Chinese Zhuyin “ㄨㄤ” and then selecting the candidate word “王”. On iOS 18, the delegate (textField:shouldChangeCharactersInRange:replacementString:) is called with: range: {0, 2} replacementString: "王" On iOS 26, the delegate (textField:shouldChangeCharactersInRanges:replacementString:) instead provides: ranges: [{2, 0}] replacementString: "王" This results in inconsistent text input handling compared to earlier system versions. Implement: Limit user input to a maximum of 100 Chinese characters. - (BOOL)textField:(UITextField *)textField shouldChangeCharactersInRange:(NSRange)range replacementString:(NSString *)string { if ([textField markedTextRange]) { return YES; } NSString *changedString = [textField.text stringByReplacingCharactersInRange:range withString:string]; if (changedString.length > 100) { return NO; } return YES; } Questions: Is this an intentional change in iOS 26? If intentional, what is the recommended way to handle such cases in order to support both iOS 18 and iOS 26 consistently?

All of these issues appear when the search controller is set on the view controller's navigationItem and the search controller's searchBar has its scopeButtonTitles set. So far the following issues are affecting my app on iOS/iPadOS 26 as of beta 7: When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to .integratedButton, and the searchBarPlacementAllowsToolbarIntegration is set to false (forcing the search icon to appear in the nav bar), on both iPhones and iPads, the scope buttons never appear. They don't appear when the search is activated. They don't appear when any text is entered into the search bar. FB19771313 I attempted to work around that issue by setting the scopeBarActivation to .manual. I then show the scope bar in the didPresentSearchController delegate method and hide the scope bar in the willDismissSearchController. On an iPhone this works though the display is a bit clunky. On an iPad, the scope bar does appear via the code in didPresentSearchController, but when any scope bar button is tapped, the search controller is dismissed. This happens when the app is horizontally regular. When the app on the iPad is horizontally compact, the buttons work but the search bar's text is not correctly aligned within the search bar. Quite the mess really. I still need to post a bug report for this issue. But if issue 1 above is fixed then I don't need this workaround. When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to .stacked, and the hidesSearchBarWhenScrolling property of the navigationItem is set to false (always show the search bar), and this is all used in a UITableViewController, then upon initial display of the view controller on an iPhone or iPad, you are unable to tap on the first row of the table view except on the very bottom of the row. The currently hidden scope bar is stealing the touches. If you activate and then cancel the search (making the scope bar appear and then disappear) then you are able to tap on the first row as expected. The initially hidden scope bar also bleeds through the first row of the table. It's faint but you can tell it's not quite right. Again, this is resolved by activating and then canceling the search once. FB17888632 When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to integrated or .integratedButton, and the toolbar is shown, then on iPhones (where the search bar/icon appears in the toolbar) the scope buttons appear (at the top of the screen) the first time the search is activated. But if you cancel the search and then activate it again, the search bar never appears a second (or later) time. On an iPad the search bar/icon appears in the nav bar and you end up with the same issue as #1 above. FB17890125 Issues 3 and 4 were reported against beta 1 and still haven't been fixed. But if issue 1 is resolved on iPhone, iPad, and Mac (via Mac Catalyst), then I personally won't be affected by issues 2, 3, or 4 any more (but of course all 4 issues need to be fixed). And by resolved, I mean that the scope bar appears and disappears when it is supposed to each and every time the search is activated and cancelled (not just the first time). The scope bar doesn't interfere with touch events upon initial display of the view controller. And there are no visual glitches no matter what the horizontal size class is on an iPad. I really hope the UIKit team can get these resolved before iOS/iPadOS 26 GM.

In our app, there is a UIWindow makeKeyAndVisible crash, and for now, it appears once, crash stack: the crash detail: crash.txt in the RCWindowSceneManager class's makeWindowKeyAndVisible method, we check and set a window's windowScene and makeKeyAndVisible: public func makeWindowKeyAndVisible(_ window: UIWindow?) { guard let window else { return } if let currentWindowScene { if window.windowScene == nil || window.windowScene != currentWindowScene { window.windowScene = currentWindowScene } window.makeKeyAndVisible() } } and I set a break point at a normal no crash flow, the stack is: why it crash? and how we avoid this, thank you.

This is really odd. If you setup a UISearchController with a preferredSearchBarPlacement of .stacked and you setup the search bar with scope buttons, then when the view controller is initially displayed, the currently hidden scope buttons block touch events from reaching the main view just below the search bar. But once the search is activated and dismissed, then the freshly hidden scope buttons no longer cause an issue. This is easily demonstrated by putting a UITableViewController in a UINavigationController. Setup the table view to show a few simple rows. Then setup a search controller using the following code: func setupSearch() { // Setup a stacked search bar with scope buttons // Before the search is ever activated, the hidden scope buttons block any touches in the main view controller // in the area just below the search bar. // Once the search is activated and dismissed, the problem goes away. It seems that displaying and hiding the // scope buttons at least once fixes the issue that exists beforehand. // This issue only exists in iOS/iPadOS 26, not iOS/iPadOS 18 or earlier. let search = UISearchController(searchResultsController: UIViewController()) search.hidesNavigationBarDuringPresentation = true search.obscuresBackgroundDuringPresentation = true search.scopeBarActivation = .onSearchActivation // Ensure button appear immediately let searchBar = search.searchBar searchBar.scopeButtonTitles = [ "One", "Two", "Three" ] self.navigationItem.searchController = search self.navigationItem.hidesSearchBarWhenScrolling = false // Issue appears even if this is true self.navigationItem.preferredSearchBarPlacement = .stacked } When first shown, before any attempt is made to activate the search, any attempt to tap on the upper 2/3 of the first row in the table view (which is just below the search bar) fails. If you tap on the lower 1/3 of the first row it works fine. If you then activate the search (now the scope buttons appear) and then dismiss the search (now the scope buttons are hidden again), then there is no issue tapping anywhere on the first row of the table. But if you restart the app, the problem starts over again. This problem happens on any iPhone or iPad, real or simulated, running iOS/iPadOS 26 RC. This is a regression from iOS 18 or earlier.

I have an iPad app that supports multiple scenes. I discovered some issues with my app's user interface that I would like to tweak based on whether the user has setup multitasking (in iPadOS 26) as "Full Screen Apps" or "Windowed Apps". Is there any API or way to determine the current iPadOS 26 multitasking setting? I've looked at UIDevice.current.isMultitaskingSupported and UIApplication.shared.supportsMultipleScenes. Both always return true no matter the user's chosen multitasking choice. I also looked at UIWindowScene isFullScreen which was always false. I tried to look at UIWindowScene windowingBehaviors but that was always nil.

Starting with iOS 18, UITabBarController no longer updates tab bar item titles when localized strings are changed or reassigned at runtime. This behavior worked correctly in iOS 17 and earlier, but in iOS 18 the tab bar titles remain unchanged until the app restarts or the view controller hierarchy is reset. This regression appears to be caused by internal UITabBarController optimizations introduced in iOS 18. Steps to Reproduce Create a UITabBarController with two or more tabs, each having a UITabBarItem with a title. Localize the tab titles using NSLocalizedString(): tabBar.items?[0].title = NSLocalizedString("home_tab", comment: "") tabBar.items?[1].title = NSLocalizedString("settings_tab", comment: "") Run the app. Change the app’s language at runtime (without restarting), or manually reassign the localized titles again: tabBar.items?[0].title = NSLocalizedString("home_tab", comment: "") tabBar.items?[1].title = NSLocalizedString("settings_tab", comment: "") Observe that the tab bar titles do not update visually.

Hi, How to enable multitouch on ARView? Touch functions (touchesBegan, touchesMoved, ...) seem to only handle one touch at a time. In order to handle multiple touches at a time with ARView, I have to either: Use SwiftUI .simultaneousGesture on top of an ARView representable Position a UIView on top of ARView to capture touches and do hit testing by passing a reference to ARView Expected behavior: ARView should capture all touches via touchesBegan/Moved/Ended/Cancelled. Here is what I tried, on iOS 26.1 and macOS 26.1: ARView Multitouch The setup below is a minimal ARView presented by SwiftUI, with touch events handled inside ARView. Multitouch doesn't work with this setup. Note that multitouch wouldn't work either if the ARView is presented with a UIViewController instead of SwiftUI. import RealityKit import SwiftUI struct ARViewMultiTouchView: View { var body: some View { ZStack { ARViewMultiTouchRepresentable() .ignoresSafeArea() } } } #Preview { ARViewMultiTouchView() } // MARK: Representable ARView struct ARViewMultiTouchRepresentable: UIViewRepresentable { func makeUIView(context: Context) -> ARView { let arView = ARViewMultiTouch(frame: .zero) let anchor = AnchorEntity() arView.scene.addAnchor(anchor) let boxWidth: Float = 0.4 let boxMaterial = SimpleMaterial(color: .red, isMetallic: false) let box = ModelEntity(mesh: .generateBox(size: boxWidth), materials: [boxMaterial]) box.name = "Box" box.components.set(CollisionComponent(shapes: [.generateBox(width: boxWidth, height: boxWidth, depth: boxWidth)])) anchor.addChild(box) return arView } func updateUIView(_ uiView: ARView, context: Context) { } } // MARK: ARView class ARViewMultiTouch: ARView { required init(frame: CGRect) { super.init(frame: frame) /// Enable multi-touch isMultipleTouchEnabled = true cameraMode = .nonAR automaticallyConfigureSession = false environment.background = .color(.gray) /// Disable gesture recognizers to not conflict with touch events /// But it doesn't fix the issue gestureRecognizers?.forEach { $0.isEnabled = false } } required dynamic init?(coder decoder: NSCoder) { fatalError("init(coder:) has not been implemented") } override func touchesBegan(_ touches: Set<UITouch>, with event: UIEvent?) { for touch in touches { /// # Problem /// This should print for every new touch, up to 5 simultaneously on an iPhone (multi-touch) /// But it only fires for one touch at a time (single-touch) print("Touch began at: \(touch.location(in: self))") } } } Multitouch with an Overlay This setup works, but it doesn't seem right. There must be a solution to make ARView handle multi touch directly, right? import SwiftUI import RealityKit struct MultiTouchOverlayView: View { var body: some View { ZStack { MultiTouchOverlayRepresentable() .ignoresSafeArea() Text("Multi touch with overlay view") .font(.system(size: 24, weight: .medium)) .foregroundStyle(.white) .offset(CGSize(width: 0, height: -150)) } } } #Preview { MultiTouchOverlayView() } // MARK: Representable Container struct MultiTouchOverlayRepresentable: UIViewRepresentable { func makeUIView(context: Context) -> UIView { /// The view that SwiftUI will present let container = UIView() /// ARView let arView = ARView(frame: container.bounds) arView.autoresizingMask = [.flexibleWidth, .flexibleHeight] arView.cameraMode = .nonAR arView.automaticallyConfigureSession = false arView.environment.background = .color(.gray) let anchor = AnchorEntity() arView.scene.addAnchor(anchor) let boxWidth: Float = 0.4 let boxMaterial = SimpleMaterial(color: .red, isMetallic: false) let box = ModelEntity(mesh: .generateBox(size: boxWidth), materials: [boxMaterial]) box.name = "Box" box.components.set(CollisionComponent(shapes: [.generateBox(width: boxWidth, height: boxWidth, depth: boxWidth)])) anchor.addChild(box) /// The view that will capture touches let touchOverlay = TouchOverlayView(frame: container.bounds) touchOverlay.autoresizingMask = [.flexibleWidth, .flexibleHeight] touchOverlay.backgroundColor = .clear /// Pass an arView reference to the overlay for hit testing touchOverlay.arView = arView /// Add views to the container. /// ARView goes in first, at the bottom. container.addSubview(arView) /// TouchOverlay goes in last, on top. container.addSubview(touchOverlay) return container } func updateUIView(_ uiView: UIView, context: Context) { } } // MARK: Touch Overlay View /// A UIView to handle multi-touch on top of ARView class TouchOverlayView: UIView { weak var arView: ARView? override init(frame: CGRect) { super.init(frame: frame) isMultipleTouchEnabled = true isUserInteractionEnabled = true } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } override func touchesBegan(_ touches: Set<UITouch>, with event: UIEvent?) { let totalTouches = event?.allTouches?.count ?? touches.count print("--- Touches Began --- (New: \(touches.count), Total: \(totalTouches))") for touch in touches { let location = touch.location(in: self) /// Hit testing. /// ARView and Touch View must be of the same size if let arView = arView { let entity = arView.entity(at: location) if let entity = entity { print("Touched entity: \(entity.name)") } else { print("Touched: none") } } } } override func touchesCancelled(_ touches: Set<UITouch>, with event: UIEvent?) { let totalTouches = event?.allTouches?.count ?? touches.count print("--- Touches Cancelled --- (Cancelled: \(touches.count), Total: \(totalTouches))") } }

I open this post to bring attention to overlooked UIManagedDocument. It still marked with @MainActor despite the fact that UIDocument is gonna be nonisolated in iOS 26.1. Here is what we will have with iOS 26.1 (the fix was there since, at least, beta 2): UIDocument was incorrectly annotated to be main actor only. This has been corrected. As a result you might see new warnings or errors show up in your Swift code using UIDocument. (149990945) Seems that UIManagedDocument should also have to be corrected the same way. Otherwise, in Swift 6 we will have crashes. Feedback report for this issue is FB20555456.

Hello, I'm experiencing a navigation bar positioning issue with my UIKit iPad app on iPadOS 26 (23A340) using Xcode 26 (17A321). The navigation bar positions under the status bar initially, and after orientation changes to landscape, it positions incorrectly below its expected location. This occurs on both real device (iPad mini A17 Pro) and simulator. My app uses UIKit + Storyboard with a Root Navigation Controller. A stack overflow post has reproduce the bug event if it's not in the same configuration: https://stackoverflow.com/questions/79752945/xcode-26-beta-6-ipados-26-statusbar-overlaps-with-navigationbar-after-presen I have checked all safe areas and tried changing some constraints, but nothing works. Have you encountered this bug before, or do you need additional information to investigate this issue?

The document-based SwiftUI example app (https://developer.apple.com/documentation/swiftui/building-a-document-based-app-with-swiftui) doesn't specify a launch image. It would seem per the HIG that the "pinkJungle" background in the app would be a decent candidate for a launch image, since it will be in the background when the document browser comes up. However when specifying it as the UIImageName, it is not aligned the same as the background image. I'm having trouble figuring out how it should be aligned to match the image. The launch image seems to be scaled up a bit over scaledToFill. I suppose a launch storyboard might make this more explicit, but I still should be able to do it without one. This is the image when displayed as the launch image: and this is how it's rendered in the background right before the document browser comes up:

Summary In iOS 18, the UICollectionViewDelegate method collectionView(_:targetIndexPathForMoveOfItemFromOriginalIndexPath:atCurrentIndexPath:toProposedIndexPath:) is not being called when moving items in a UICollectionView. This method works as expected in iOS 17.5 and earlier versions. Steps to Reproduce Create a UICollectionView with drag and drop enabled. Implement the UICollectionViewDelegate method: func collectionView(_ collectionView: UICollectionView, targetIndexPathForMoveOfItemFromOriginalIndexPath originalIndexPath: IndexPath, atCurrentIndexPath currentIndexPath: IndexPath, toProposedIndexPath proposedIndexPath: IndexPath) -> IndexPath { print("🐸 Move") return proposedIndexPath } Run the app on iOS 18. Attempt to drag and drop items within the collection view. Expected Behavior The method should be called during the drag and drop operation, and "🐸 Move" should be printed to the console. Actual Behavior The method is not called, and nothing is printed to the console. The drag and drop operation still occurs, but without invoking this delegate method. Configuration iOS Version: 18 Xcode Version: Xcode 16.0.0

I have a tab bar with 4 tabs. Since iOS 26, I’m facing an issue with the tab alignment — the text automatically shrinks, and the tab icon shifts upward for some tabs. I am using UITab property for creating Tabs from os Version above 18 and UITabBar for os version below 18.

I’m developing an app that includes a navigation bar with a centered title and a single right bar button item. I’ve noticed that when both the navigation bar title and the right bar button item’s title are relatively long, the navigation bar title becomes hidden. This issue only occurs on iOS 26. When running the same code on iOS 18, the layout behaves as expected, with both elements visible. Has anyone else experienced this behavior on iOS 26? Is this a known layout change or a possible bug?

I’m running the interactive reordering sample from this repo and hitting an odd behavior on newer simulators: the delegate method that lets you steer the drop: func collectionView(_:targetIndexPathForMoveOfItemFromOriginalIndexPath:atCurrentIndexPath:toProposedIndexPath:) works fine on iOS 16, but on iOS 18 and iOS 26 simulators it never fires, so the item always lands at the proposed index path and I can’t constrain moves or adjust the compositional view layout to accommodate the cell of different size. Is this a new behavior in modern iOS? If so, what’s the recommended way to control the final index path for the UICollectionViewDropDelegate now?

According to Apple's documentation, SKOverlay is designed to recommend other applications to users. I'm seeking clarification on whether it also supports displaying update prompts for the host application itself. Use case: My app (for example, HelloDeveloper) is live at version 2.0, but some users are still on version 1.0. I want to display a soft update prompt that allows users to remain in the app. Question: Is it possible to use SKOverlay with my app's App Store ID to present an update option without requiring users to leave the app?

Hi, We began to get this new crash in codes that exist years ago from our recent released version, it crashed after a view removed itself from superview. We tried to look at the assembly code of NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex, find out that d0 <= 0 would branch to NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex.cold.1. We believe that it's related with Autolayout, but setting a negative value for width or height constraints can't reproduce this crash. Here is the crash log Exception Type: NSInternalInconsistencyException Invalid parameter not satisfying: placeValue > 0 Exception Codes: fault addr: (null) Crashed Thread: 0 0 CoreFoundation ___exceptionPreprocess + 164 1 libobjc.A.dylib _objc_exception_throw + 88 2 Foundation -[NSMutableDictionary(NSMutableDictionary) initWithContentsOfFile:] + 0 3 CoreAutoLayout NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex.cold.1 + 100 4 CoreAutoLayout _NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex + 848 5 CoreAutoLayout _NSISSparseVectorAddVectorTimesScalar + 72 6 CoreAutoLayout -[NSISObjectiveLinearExpression replaceVar:withExpression:processVarNewToReceiver:processVarDroppedFromReceiver:] + 200 7 CoreAutoLayout ____substituteOutAllOccurencesOfBodyVar_block_invoke + 504 8 CoreAutoLayout __substituteOutAllOccurencesOfBodyVar + 340 9 CoreAutoLayout __pivotToMakeColNewHeadOfRow + 960 10 CoreAutoLayout -[NSISEngine removeConstraintWithMarker:] + 748 11 CoreAutoLayout -[NSLayoutConstraint _removeFromEngine:] + 140 12 UIKitCore ___57-[UIView(AdditionalLayoutSupport) _switchToLayoutEngine:]_block_invoke + 164 13 CoreAutoLayout -[NSISEngine withBehaviors:performModifications:] + 84 14 UIKitCore -[UIView(AdditionalLayoutSupport) _switchToLayoutEngine:] + 212 15 UIKitCore ___57-[UIView(AdditionalLayoutSupport) _switchToLayoutEngine:]_block_invoke_2 + 148 16 UIKitCore ___57-[UIView(AdditionalLayoutSupport) _switchToLayoutEngine:]_block_invoke + 544 17 CoreAutoLayout -[NSISEngine withBehaviors:performModifications:] + 84 18 UIKitCore -[UIView(AdditionalLayoutSupport) _switchToLayoutEngine:] + 212 19 UIKitCore ___45-[UIView(Hierarchy) _postMovedFromSuperview:]_block_invoke + 84 20 CoreAutoLayout -[NSISEngine withBehaviors:performModifications:] + 84 21 UIKitCore -[UIView _postMovedFromSuperview:] + 512 22 UIKitCore ___UIViewWasRemovedFromSuperview + 136 23 UIKitCore -[UIView(Hierarchy) removeFromSuperview] + 244 Assembly of NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex CoreAutoLayout`NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex: -> 0x1ec1a2124 <+0>: pacibsp 0x1ec1a2128 <+4>: stp d11, d10, [sp, #-0x60]! 0x1ec1a212c <+8>: stp d9, d8, [sp, #0x10] 0x1ec1a2130 <+12>: stp x24, x23, [sp, #0x20] 0x1ec1a2134 <+16>: stp x22, x21, [sp, #0x30] 0x1ec1a2138 <+20>: stp x20, x19, [sp, #0x40] 0x1ec1a213c <+24>: stp x29, x30, [sp, #0x50] 0x1ec1a2140 <+28>: add x29, sp, #0x50 0x1ec1a2144 <+32>: mov x19, x1 0x1ec1a2148 <+36>: fmov d9, d2 0x1ec1a214c <+40>: fmov d10, d1 0x1ec1a2150 <+44>: fmov d8, d0 0x1ec1a2154 <+48>: mov x20, x0 0x1ec1a2158 <+52>: fcmp d0, #0.0 0x1ec1a215c <+56>: b.le 0x1ec1a2470 ; <+844> 0x1ec1a2160 <+60>: fcmp d10, #0.0 0x1ec1a2164 <+64>: adrp x8, 112778 .... 0x1ec1a2468 <+836>: ldp d11, d10, [sp], #0x60 0x1ec1a246c <+840>: retab 0x1ec1a2470 <+844>: bl 0x1ec1cac18 ; NSISSparseVectorAddTermWithPlaceValueCoefficientStartingIndex.cold.1 0x1ec1a2474 <+848>: b 0x1ec1a2160 ; <+60>

After updating to Xcode 26 my XCUITests are now failing as during execution exceptions are being raised and caught by my catch all breakpoint These exceptions are only raised during testing, and seem to be referencing some private internal property. It happens when trying to tap a button based off an accessibilityIdentifier e.g. accessibilityIdentifier = "tertiary-button" ... ... app.buttons["tertiary-button"].tap() The full error is: Thread 1: "[<UIKit.ButtonBarButtonVisualProvider 0x600003b4aa00> valueForUndefinedKey:]: this class is not key value coding-compliant for the key _titleButton." Anyone found any workarounds or solutions? I need to get my tests running on the liquid glass UI

please fix!

Setting up UITabAccessory via setBottomAccessory(_:animated:) causing recursion internally on iPhone Air which is leading into a crash. Sharing crash log & feedback below... crashlog.crash crash-feedback.json