iOS 26 – navigationItem.titleView shifted left when leftBarButtonItem is nil Hi everyone, I’m encountering a layout issue on iOS 26 related to navigationItem.titleView positioning. What I’m Doing I’m hiding the default back button and removing the left bar button item: navigationItem.leftBarButtonItem = nil navigationItem.hidesBackButton = true navigationItem.setLeftBarButtonItems([], animated: true) Then I create a custom titleView with a specific width calculated as: Screen width minus the width of the two bar button items (left and right). let titleView = UIView(frame: CGRect(origin: .zero, size: sizeOfTitleView)) let titleLabel = UILabel(frame: CGRect(origin: .zero, size: sizeOfTitleView)) Expected Behavior On previous iOS versions, the titleView is perfectly centered in the navigation bar. Actual Behavior (iOS 26) On iOS 26, when leftBarButtonItem is nil, the titleView is pushed slightly to the left instead of being centered (see attached image). Question Has there been a change in UINavigationBar layout behavior in iOS 26? What is the correct way to ensure the titleView remains perfectly centered when there is no leftBarButtonItem? Any guidance would be appreciated. Thanks!

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 ()

What works let backButton = UIBarButtonItem(title: "", style: .plain, target: nil, action: nil) backButton.hidesSharedBackground = true self.navigationItem.rightBarButtonItem = backButton // or self.navigationItem.leftBarButtonItem = backButton What doesn't work let backButton = UIBarButtonItem(title: "", style: .plain, target: nil, action: nil) backButton.hidesSharedBackground = true self.navigationItem.backBarButtonItem = backButton I've tried setting this property on all possible permutations and combinations e.g. Inside navigationController(_ navigationController: UINavigationController, willShow viewController: UIViewController, animated: Bool) and pushViewController(_ viewController: UIViewController, animated: Bool) of a custom UINavigationController to make sure. Expected vs Actual behavior Setting hidesSharedBackground = true should remove the glass background from both regular bar button items and back bar button items but it has no effect on backBarButtonItem. Additional context I’m aware of the UIDesignRequiresCompatibility Info.plist key, but I’m looking for a programmatic solution if there is one. The goal is to remove the glass background from back buttons.

I have three custom UIButton instances inside a custom UIView subclass (not inside a UINavigationBar, UIToolbar, or UITabBar). I want to apply UIGlassEffect with interactive = YES to each button so they get the native liquid glass press animation. The problem is that the UIVisualEffectView containing the effect either: Has userInteractionEnabled = YES — glass animation works but the button's IBAction never fires Has userInteractionEnabled = NO — IBAction fires but no glass animation How can I have both the native interactive glass animation and the button action firing on the same button? Is this possible with the public API, or is the interactive glass animation on custom buttons simply not supported outside of standard UIKit controls?

My app is a UIKit app with a lot of SwiftUI mixed in. A common scenario is that a UIViewController presents a sheet with a SwiftUI view wrapped in a UIHostingController. When I present the exact same SwiftUI View it looks different in a SwiftUI sheet compared to when it's wrapped in a UIHostingController and presented from a view controller. I'm using a hacky workaround in which I loop through all subviews of the hosting controller in viewWillLayoutSubviews and look for a NavigationStackHostingController<SwiftUI.AnyView> to manually set the background color, but it feels like it could brake easily. Has anyone found a better way to fix this? Feedback: FB22028838

I’ve encountered an aspect of the Liquid Glass effect in SwiftUI that seems a bit odd: the Liquid Glass interaction appears to ignore regular hit-testing behavior. The following sample shows a button with hit testing disabled: @main struct LiquidGlassHitTestDemo: App { var body: some Scene { WindowGroup { Button("Liquid") { fatalError("Never called.") } .buttonStyle(.glassProminent) .allowsHitTesting(false) } } } As expected, the button’s action is never called. However, the interactive glass effect still responds to touch events: What’s even more surprising is that the UIKit equivalent behaves differently: final class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() let button = UIButton( configuration: .prominentGlass(), primaryAction: UIAction( title: "Liquid", handler: { action in print("Never called.") } ) ) view.addSubview(button) button.translatesAutoresizingMaskIntoConstraints = false NSLayoutConstraint.activate([ button.centerXAnchor.constraint(equalTo: view.centerXAnchor), button.centerYAnchor.constraint(equalTo: view.centerYAnchor) ]) button.isUserInteractionEnabled = false } } In this case, the effect is not interactive at all. Similarly, if a UIViewController’s root view overrides hitTest(_:with:) to always return nil, the Liquid Glass effect does not react to touch events whatsoever. The only way I’ve found to “properly” disable the glass interactivity in SwiftUI is to use the .disabled(true) modifier. However, this also changes the button’s appearance, which is not always desirable. Is this expected behavior, or could this be a bug? Am I missing something about how Liquid Glass interaction is implemented in SwiftUI?

When you set inputAccessoryView AND inputView you get unexpected system UI in between the two custom views If anyone has a workaround for this I'd love to hear it. See also: https://stackoverflow.com/questions/79818015/uitextfield-custom-inputaccessoryview-with-custom-inputview-in-ios-26 Red == inputAccessoryView Blue == inputView Glassy bit in between == bug? // // ViewController.swift // Custom Keyboard // // Created by Lewis Smith on 19/02/2026. // import UIKit class ViewController: UIViewController { let textField = { let textField = UITextField() textField.translatesAutoresizingMaskIntoConstraints = false textField.backgroundColor = .yellow let inputAccessoryView = UIView(frame: CGRect(x: 0, y: 0, width: .zero, height: 70)) inputAccessoryView.backgroundColor = .red let inputView = UIView(frame: CGRect(x: 0, y: 0, width: .zero, height: 70)) inputView.backgroundColor = .blue // When you set inputAccessoryView AND inputView you get unexpected UI inbetweeen the two custom views textField.inputAccessoryView = inputAccessoryView textField.inputView = inputView textField.becomeFirstResponder() return textField }() override func viewDidLoad() { super.viewDidLoad() self.view.backgroundColor = .purple self.view.addSubview(textField) NSLayoutConstraint.activate([ textField.centerXAnchor.constraint(equalTo: view.centerXAnchor), textField.centerYAnchor.constraint(equalTo: view.centerYAnchor), textField.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 20), textField.trailingAnchor.constraint(equalTo: view.trailingAnchor, constant: -20), ]) } }

Any logical reason why applying .sharedBackgroundVisibility(.hidden) to a ToolbarItem would not remove the spacing allocated for glass border? Thus causing any element utilizing this functionality to appear offset from the regular buttons. Or is this yet another magical Apple experience I am not blessed enough to understand.

Hi everyone, I’m running into a strange issue with UISearchController placement with iOS 26 SDK. In one of my view controllers, I was able to move the search bar to the top of the navigation bar by setting: navigationItem.searchController = searchController navigationItem.hidesSearchBarWhenScrolling = false navigationItem.preferredSearchBarPlacement = .stacked This works as expected — the search bar is placed at the top. However, in another view controller with almost identical configuration, the search bar always shows up at the bottom. If I delay the setup with DispatchQueue.main.async, it appears at the bottom; if I don’t, it doesn’t appear at all. Both VCs are wrapped in their own UINavigationController. So my questions are: Has anyone faced this issue where preferredSearchBarPlacement = .stacked is ignored? Are there hidden requirements or limitations for placing the search bar at the top? Why could the same setup behave differently in two controllers? Any help or ideas would be appreciated!

Could you help me with resolving this issue, please. I've got following trace: ksmemory_notifyUnhandledFatalSignal EXC_BAD_ACCESS (KERN_INVALID_ADDRESS) Crashed: com.apple.main-thread EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x000000000000002b Crashed: com.apple.main-thread 0 KSCrash 0xbff8 ksmemory_notifyUnhandledFatalSignal + 12 1 KSCrash 0xcd6c handleSignal + 100 2 libsystem_platform.dylib 0x4178 _sigtramp + 56 3 libsystem_kernel.dylib 0x42f8 mach_msg2_internal + 76 4 libsystem_kernel.dylib 0x4214 mach_msg_overwrite + 428 5 libsystem_kernel.dylib 0x405c mach_msg + 24 6 CoreFoundation 0x46868 __CFRunLoopServiceMachPort + 160 7 CoreFoundation 0x1d848 __CFRunLoopRun + 1188 8 CoreFoundation 0x1ca6c _CFRunLoopRunSpecificWithOptions + 532 9 GraphicsServices 0x1498 GSEventRunModal + 120 10 UIKitCore 0x9ddf8 -[UIApplication _run] + 792 11 UIKitCore 0x46e54 UIApplicationMain + 336 12 UIKitCore 0x172938 -[UIScrollView contentInset] + 588 13 AppName 0xed9440 main + 4386804800 (AppDelegate.swift:4386804800) 14 ??? 0x189f76e28 (Missing) It appears that a variable or object is attempting to access another object that has already been deallocated. Based on the stack trace, the issue was likely detected while layout was in progress. Our analytics show this happens generally on app launch and occasionally during normal use. Unfortunately, I couldn't gather additional diagnostic data. I tried to reproduce the issue using the Leaks tool and enabled runtime diagnostics (Address Sanitizer, Malloc Scribble, Zombies), but without success. I may be overlooking something — any suggestions would be greatly appreciated. Thank you in advance

I have a very simple custom collection view layout that supports self-sizing. When a cell is selected, I expand the cell by modifying its constraints. This change (and the resulting effect on the collection view layout) is animated using [self.collectionView.collectionViewLayout invalidateLayout] followed by [self.collectionView layoutIfNeeded] within an animation closure. When you first tap on a cell, it expands smoothly as expected. When you tap on it again to contract it, however, its content jumps before it shrinks again. How can I fix this? For what it’s worth, I’ve noticed that neither UICollectionViewFlowLayout nor UICollectionViewCompositionalLayout have this issue, which suggests I’m doing self-sizing incorrectly. Here’s a screen recording demonstrating the issue. I’ve also put together a minimal sample project. I’m using Xcode 26.2 and iOS 26.2.1.

I need to detect whether a view controller is presented in a popover or in fullscreen mode, as on iPhone. I checked viewController.popoverPresentationController but it returns a non-nil value even on iPhone, when it's clearly not in a popover. I then checked viewController.presentationController?.adaptivePresentationStyle but it returns .formSheet even when it's presented in a popover!?! Why? This whole adaptive presentation thingie is a mess. Heck, viewController.presentationController returns _UIPageSheetPresentationController even when the view controller is in a UINavigationController, so not presented at all. Anybody got any ideas?

There is no way to make an instance of UISegmentedControl transparent like it's done in Photos or Camera. Especially it looks wrong when segmented control is put to a Liquid Glass container. Setting background colour to nil or clear does not help If a transparent image is set as a background image for state and bar metrics, it kills liquid glass selection and segments started to look wrong How can the standard gray-ish background can be removed?

Overview I have the following view hierarchy that mixes SwiftUI and UIKit: AccordionView └─ VStack ├─ Text ├─ Button └─ UIViewRepresentable └─ UIStackView ├─ UILabel └─ UILabel When tapping the button, the UIViewRepresentable hides and shows its content. This all works as expected. However, in certain circumstances the view's sizing is rendered with the correct size, but the text can often render incorrectly, despite the frame seemingly looking as though it has enough room to render the text. More info Below you can see the UILabel has the correct frame height (the light grey background and coloured borders) but the text is rendered as though it has infinite width along one line. There's a few configurations of my view hierarchy that seem to have this effect. I've added a playground to the bottom of this post of various configurations to show what does and doesn't work, just copy and paste to see for yourself... It seems of the ones that don't work, there's a couple of reasons why that may be: HostedView and TextViewContainer do not do the following (I think we only need to do one of these things for auto layout/stack views to work effectively): a) implement an intrinsic content size b) return a 'good' size for systemLayoutSizeFitting(). UIHostingController shouldn't use intrinsic size (although I'm sure it should) Something related to setting setContentCompressionResistancePriority() or setContentHuggingPriority() but having played about with this it doesn't seem relevant here... I've played around with everything I can think of here but can't find a solution that works for all, although I'm 99% sure it's one or all of the points above. If there are any UIKit gurus out there that can help that would be great! Ive already spent so much time on this 🫨 Playground Swift Playground

Since iOS 26, navigationController?.toolbar no longer appears in the view hierarchy, and UIToolbar itself is not visible in the view tree. Is there currently any supported way to access the toolbar’s container view or its underlying view hierarchy? However, the API itself is not deprecated. https://developer.apple.com/documentation/uikit/uinavigationcontroller/toolbar

Hello. I have an 12 year old app that still has some objective-c code in it. I have a place where i have a flip animation between 2 view controllers that looks like this: [UIView transitionFromView:origView toView:newViewController.view duration:0.5 options:UIViewAnimationOptionTransitionFlipFromRight completion:nil]; It has looked like this since 2012 at least. In our production release, it works prior to 26.1, but in 26.1 and 26.2, the flip is off-center and looks weird. it's like both edges flip the same way. It's a little bit hard to explain. If seen at least 2 other app store apps that i have installed behave this way too, from 26.1 and onwards. Anyone else seen this? Is there anything that can be done about it? Thankful for thoughts.

Hello, We are seeing an intermittent crash when initializing a base UITableView with Apple's [initWithFrame:style:] initializer. Crash stack: Role: Foreground OS Version: iOS 26.1 Exception Type: EXC_BREAKPOINT Exception Subtype: KERN_INVALID_ADDRESS EXC_BREAKPOINT: 0 libswiftCore.dylib +0x1358c0 _assertionFailure(_:_:file:line:flags:) 1 UIKitCore +0x1fdca0 0x188c26ca0 (0x188c26b20 + 384) 2 UIKitCore +0x1ffa60 0x188c28a60 (0x188c2890c + 340) 3 UIKitCore +0x2012d0 0x188c2a2d0 (0x188c2a1ec + 228) 4 UIKitCore +0x200f20 0x188c29f20 (0x188c29cac + 628) 5 UIKitCore +0x200428 0x188c29428 (0x188c29384 + 164) 6 UIKitCore +0x18af7f4 -[UITableMetricsAdapter _updateSharedSectionMetricsForListGeometry:] 7 UIKitCore +0x201da8 -[UITableMetricsAdapter tableBackgroundColor] 8 UIKitCore +0x1643a44 ___39-[UITableView _applyAppearanceDefaults]_block_invoke 9 UIKitCore +0x196f3d0 +[UIView _performSystemAppearanceModifications:] 10 UIKitCore +0x1643978 -[UITableView _applyAppearanceDefaults] 11 UIKitCore +0x202854 -[UITableView _setupTableViewCommon] 12 UIKitCore +0x1643760 -[UITableView initWithFrame:style:] 13 Application +0x30b6a40 closure #1 in variable initialization expression of MyAppClass.tableView 14 Application +0x30b6ef0 MyAppClass.init(frame:) Has anyone else seen something like this? Any insights or advice is much appreciated, thank you!

I am building an app for iOS and MacCatalyst that indexes files by storing their local paths. Because the app relies on the file remaining at its original location, I only want to accept items that can be opened in place. I am struggling to determine if an item is "Open In Place" compatible early in the drag-and-drop lifecycle. Specifically: In dropInteraction(_:canHandle:) and dropInteraction(_:sessionDidUpdate:), calling itemProvider.registeredTypeIdentifiers(fileOptions: [.openInPlace]) returns an empty array. Only once the drop is actually committed in dropInteraction(_:performDrop:) does that same call return the expected type identifiers. This creates a poor user experience. I want to validate the "In Place" capability at the very start of the session so the drop target only activates for valid files. If an item is ephemeral (like a dragged photo from the Photos app or a temporary export), the drop zone should not react at all. How can I reliably detect if an NSItemProvider supports .openInPlace before the performDrop delegate method is called?

Hi all, I’m seeing a lifecycle behavior change on iOS 26.0 (and up). While my app is in the foreground and active, pressing the hardware Lock button triggers didBecomeActive callbacks/notifications even though the app is transitioning away from active state. I’m observing this sequence: willResignActive didBecomeActive willResignActive didEnterBackground This happens for: • UISceneDelegate.sceneDidBecomeActive(:) • UIApplicationDelegate.applicationDidBecomeActive(:) • UIApplication.didBecomeActiveNotification On iOS 18 (same app, same code) I do not see didBecomeActive in the middle of locking/backgrounding. Problem is reproduced on totally new project. I would expect a normal transition to background: • willResignActive → didEnterBackground …and no extra didBecomeActive between them. I have “became active” logic (refresh UI/state, resume timers, analytics). On iOS 26.0 this logic runs unexpectedly during locking, causing unnecessary work and incorrect state transitions. Is this callback ordering expected on iOS 26.0 when pressing the Lock button? If expected, what’s the recommended way to detect a “real” activation (and avoid transient didBecomeActive during locking/backgrounding)? If this is a regression, is there a known workaround or best practice?

I just found a weird bug: If you place a Text view using .foregroundStyle(.secondary), .tertiary, or other semantic colors inside a ScrollView, and apply a Material background clipped to an UnevenRoundedRectangle, the text becomes invisible. This issue does not occur when: The text uses .primary or explicit colors (e.g., .red, Color.blue), or The background is clipped to a standard shape (e.g., RoundedRectangle). A minimal reproducible example is shown below: ScrollView{ VStack { Image(systemName: "globe") .imageScale(.large) .foregroundStyle(.tint) Text("Hello World.") .font(.system(size: 15)) .foregroundStyle(.quinary) } } .padding() .frame(height: 100) .background(Material.regular) .clipShape(UnevenRoundedRectangle(topLeadingRadius: 10,bottomLeadingRadius: 8,bottomTrailingRadius:8, topTrailingRadius: 8))