The NSWindow collection behavior is supposed to allow for a window to appear in all spaces, even when another window is full screen in that space. However, I cannot get this to work as expected with any combination. This should be as simple as: window.level = .screenSaver window.collectionBehavior = [ .canJoinAllSpaces, .fullScreenAuxiliary, .canJoinAllApplications, .stationary, .ignoresCycle ] If I have a window (Safari for example) which is full screen in its own space, run my app and change to the Safari window's space, my app's window is not visible at all; it will only float on top of windows in non-fullscreen spaces. What am I misunderstanding?

.preferredColorScheme(.dark) doesn't seem to affect app toolbar, when .scrollEdgeEffectStyle(.hard, for: .top) is used. In the attachment, you can see the title and toolbar items don't change according to current value of .preferredColorScheme (you may need to scroll a bit to achieve it) iOS 26 RC Feedback ID - FB19769073 import SwiftUI struct ContentView: View { var body: some View { NavigationStack { ScrollView(.vertical) { ForEach(0..<100) { index in Text("\(index)") .padding() .border(.blue) .background(.blue) .frame(maxWidth: .infinity) } } .scrollEdgeEffectStyle(.hard, for: .top) .navigationTitle("Test Title") .navigationBarTitleDisplayMode(.inline) .toolbar { ToolbarItem(placement: .navigationBarTrailing) { Button(action: { }) { Text("Test") } } } } .preferredColorScheme(.dark) } } #Preview { ContentView() }

When I try to show/hide the content in .safeAreaBar(edge: .bottom), especially the content with a large height, the background animation of the toolbar is very laggy. iOS 26 RC Feedback ID - FB19768797 import SwiftUI struct ContentView: View { @State private var isShown: Bool = false var body: some View { NavigationStack { Button("Toggle") { withAnimation { isShown.toggle() } } ScrollView(.vertical) { ForEach(0..<100) { index in Text("\(index)") .padding() .border(.blue) .background(.blue) .frame(maxWidth: .infinity) } } .scrollEdgeEffectStyle(.soft, for: .bottom) .safeAreaBar(edge: .bottom) { if isShown { Text("Safe area bar") .padding(64) .background(.red) } } } } } #Preview { ContentView() }

When using .scrollEdgeEffectStyle(.hard, for: .top), search bar background doesn't match with . safeAreaBar view background (you can see that is is darker than the rest of the toolbar). Please find the screenshot in the attachment iOS 26 RC Light Mode Feedback ID - FB19768159 import SwiftUI struct ContentView: View { @State private var count = 0 var body: some View { NavigationStack { ScrollView(.vertical) { ForEach(0..<100) { index in Text("\(index)") .background(.red) } } .scrollEdgeEffectStyle(.hard, for: .top) .searchable( text: .constant(""), placement: .navigationBarDrawer(displayMode: .always) ) .safeAreaBar(edge: .top) { Text("Safe area bar") } } } } #Preview { ContentView() }

I have an app where the user can choose if the dark / light mode is enabled automatically during the night / day (dusk and dawn times are calculated according to to the date and location of the user). I also have an UITabBarController, with two tabs which have a GMSMapView (Google Map View from their SDK), and three tabs with UITableViews. I have noticed that when the automatic change of dark / light mode is performed from dark to light mode, and the user is in a tab with GMSMapView, the tabBar does not change to light model, it remains in dark mode. I perform the switch by setting the self.window.overrideUserInterfaceStyle of the UIWindow of the UIScene. All the views change to light mode, including the navigation bar, but not the tab bar. If I move between the tabs with GMSMapView, the tabBar stays in dark mode. As soon as I move to a tab which contains a UITableView, the tabBar switches to light mode. If the switch to light mode is performed while the user is in tab with the UITableViews, the tabBar switches to light mode immediately, as expected. When moving to the tabs with the GMSMapViews, the tabBar stays in light mode, also as expected. I have also noticed the same problem in CarPlay, in CPMapTemplate (with a UIViewController whose view is GMSMapView), in the buttons with are set with the property “mapButtons”, and with the panning buttons. When the switch from dark mode to light mode is performed by setting the self.window.overrideUserInterfaceStyle of the UIWindow of CarPlay scene, the mapButtons keeps the glyphs in white, and set the background of the buttons to almost white, so the glyphs are barely visible unless you put png images on them instead of SF Symbols. With the panning buttons there is not workaround, since you cannot set custom images for the panning buttons. This happens even if the panning buttons are not being displayed when the switch is performed to light mode, and you enable them later. Is this a bug? Why does this only happen with view over GMSMapView (Google Maps view for a map from their SDK)? Can you think of any viable workaround? Thank you.

Hi, I hope you are doing well. We have been running up against an issue in our application which despite our best efforts we cannot seem to solve. After a certain point of use (of which we cannot seem to isolate a trigger), something internally with the way SwiftUI handles animation transactions seems to be breaking. This results in the following behavior that we (and our users) are noticing: Alerts/Sheets/NavigationPath changes lose all animations Closures associated with buttons no longer fire at all. The alert disappears, but with no animation and any action associated with the button selected does nothing. This results in an infinite loop of triggering an alert, clicking on an alert action, and the alert dismissing without the corresponding action ever occurring. We have tried moving the navigationPath out of a view model (Observable) and into a @State variable on the view in case it was an issue with view pre-rendering due to path changes, but this did not improve our case. We hoisted the state and the alert presentation out of all subviews and onto the root view of our navigation destination (as this happens on a sub-page of the application) as well, and while did this seem to minimize occurrences it did not fully resolve it. The app structure of our watch app is as follows: We have a NavigationStack at the root level which wraps a TabView, containing 3 pages. Selecting a button triggers a navigation destination, presenting a detail view. The detail view is a ZStack which switches on a property contained in an @State Observable view model scoped to the detail view. The ZStack can contain one of 5 subviews, derived from a viewState enum with associated values (all of which are equatable, and by extension viewState is also an equatable type as well). One of the subviews receives a binding, which on button trigger updates the binding and thus the view containing the ZStack presents the alert. Sometimes, when this happens, the animations break, and then are subsequently broken for the remainder of the lifetime of the app until it is force-closed (not backgrounded, but a full force-close). NavigationStack { TabView { Tab1 Tab2 // triggers navigationDestination Tab3 } .navigationDestination(for:) { DestinationView() // the view containing the ZStack + Alert } } STEPS TO REPRODUCE Unfortunately we have not been able to ascertain exactly what is causing this issue as we cannot reproduce it in a sandbox environment, only when moving through the view flow associated with our code. Any debugging ideas or recommendations would be greatly appreciated, as we have already tried _printChanges and do not notice any erroneous view redraws.

Using a storyboard, I created a UIView containing an UIImageView and a UILabel, that I dragged into the navigation bar of one of my viewControllers. In my viewDidLoad I transform the view to move it down past the bounds of the navigation bar so its hidden initially navBarMiddleView.transform = .init(translationX: 0, y: 50) Then as the screen scrolls, I slowly move it up so it slides back into the middle of the navigationBar func scrollViewDidScroll(_ scrollView: UIScrollView) { let padding: CGFloat = 70 let adjustedOffset = (scrollView.contentOffset.y - padding) navBarMiddleView.transform = .init(translationX: 0, y: max(0, (50 - adjustedOffset))) } (The content is displayed in a collectionView cell as large content initially, and I want it to remain visible as the user scrolls down. So a mini view of the same data is moved up into the navigationBar) With iOS 26 the navigationBar is applying a blur effect to this view, even when its outside the bounds of the navigationBar, meaning the content its hovering on top of is slightly obscured. I don't know why this blur is being added, how do I remove it? I've tried the following based on recommendations from chatGPT but none have worked self.navigationController?.navigationBar.clipsToBounds = true self.navBarMiddleView.layer.allowsGroupOpacity = false self.navBarMiddleView.backgroundColor = .clear self.navBarMiddleView.isOpaque = true self.navBarMiddleView.layer.isOpaque = true I have my navigation bar setup with this appearence already: let navigationBarAppearance = UINavigationBarAppearance() navigationBarAppearance.configureWithOpaqueBackground() navigationBarAppearance.backgroundEffect = nil navigationBarAppearance.backgroundColor = UIColor.clear navigationBarAppearance.shadowColor = .clear navigationBarAppearance.titleTextAttributes = [ NSAttributedString.Key.foregroundColor: UIColor.colorNamed("Txt2"), NSAttributedString.Key.font: UIFont.custom(ofType: .bold, andSize: 20) ] UINavigationBar.appearance().standardAppearance = navigationBarAppearance UINavigationBar.appearance().compactAppearance = navigationBarAppearance UINavigationBar.appearance().scrollEdgeAppearance = navigationBarAppearance

I have a triple-column UISplitViewController setup in "tile" mode. Each of the 3 columns has a table view controller. Under iPadOS 26, the section headers and row selection in the middle table extends all the way to the left of the screen, behind the primary column. It looks terrible. The documentation for "Adopting Liquid Glass" makes it sound like you can add this behavior by using UIBackgroundExtensionView. But I get this behavior automatically in a UISplitViewController. How do I turn this off? I created a simpler sample using a double-column split view with two table view controllers. Here's a screenshot of the result: Note how the section headers and the row selection appear all the way to the left edge of the screen. I don't want that effect. How do you turn off this effect in a UISplitViewController? Here is the code used to setup the split view and the app's main window: func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { guard let winScene = (scene as? UIWindowScene) else { return } let primary = PrimaryViewController(style: .plain) let primaryNC = UINavigationController(rootViewController: primary) let detail = DetailViewController(style: .plain) let detailNC = UINavigationController(rootViewController: detail) let sv = UISplitViewController(style: .doubleColumn) sv.preferredDisplayMode = .oneBesideSecondary sv.preferredSplitBehavior = .tile sv.primaryBackgroundStyle = .none sv.displayModeButtonVisibility = .automatic sv.setViewController(primaryNC, for: .primary) sv.setViewController(detailNC, for: .secondary) let win = UIWindow(windowScene: winScene) win.rootViewController = sv win.makeKeyAndVisible() window = win } The PrimaryViewController and DetailViewController are simple UITableViewController subclasses that only add a few rows and section headers as needed.

Hi, I have a NSToolbar in my Mac Catalyst app with a space and flexible space item in it (https://developer.apple.com/documentation/appkit/nstoolbaritem/identifier/space). On macOS Tahoe the space item is being rendered with a Liquid Glass effect and seems to be automatically grouped with the previous item. Is there a way to prevent this? It basically adds some undesired padding next to the previous item and looks add. The flexible space is rendered normally and as before. I am talking about the space right next to the back chevron item. Thanks for any hints!

for await result in Transaction.currentEntitlements is not returning at all. if I call it with individual product id that I know has been purchased on the device, it is not returning that it's valid either. could this be an apple issue? I am on iOS 26

in iOS, user can set focus on UItextField and tapping a key in the virtual keyboard updates the text in the textfield. This user action causes the relevant delegates of UITextFieldDelegate to get invoked, i.e the handlers associated with action of user entering some text in the textfield. I m trying to simulate this user action where I am trying to do this programatically. I want to simulate it in a way such that all the handlers/listeners which otherwise would have been invoked as a result of user typing in the textfield should also get invoked now when i am trying to do it programatically. I have a specific usecase of this in my application. Below is how I m performing this simulation. I m manually updating the text field associated(UITextField.text) and updating its value. And then I m invoking the delegate manually as textField.delegate?.textField?(textField, shouldChangeCharactersIn: nsRange, replacementString: replacementString) I wanted to know If this is the right way to do this. Is there something better available that can be used, such that simulation has the same affect as the user performing the update?

In the RC canidate of iOS 26 I have notices sometimes my toolbar is not rendering one of the items, its a select button, The space is there as there is an oval on the screen but it does not have the label and does nothing when you touch it. Other UIToolbarItems in my toolbar are being displayed so i dont know why this one is having troubles. This however doesnt happen every time and instead it works I am not seeing anything in the console to indicate why this one button is not getting set correctly I should also mention this was not an issue with iOS 18 and we havent changed any code around how we set the toolbar Below is my code snippet

In iOS and iPadOS 26 beta 9 (and previous batas), setting the tintColor property on a navigation bar does not tint bar button items. The text and images are always black in the following cases: Buttons displaying only text (initWithTitle:) Buttons displaying only a symbol (initWithImage:) Buttons displaying system items, ie., UIBarButtonSystemItemCancel. Nav bar title The tintColor seems to be respected for: Selected-state background for buttons configured with changesSelectionAsPrimaryAction. To reproduce, Create a UINavigationController, Add bar button items to its navigation item, Set a tint color as in the following statement: self.navigationController.navigationBar.tintColor = [UIColor redColor]; Then note that the bar button items are black rather than red as expected. I have filed a feedback: FB19980265.

Hi, I’m working with custom text input handling in a UITextView. For simulating user typing programmatically, the documented way is to call: textView.insertText("H") This correctly inserts text, triggers delegate callbacks, updates the caret, and behaves as expected. However, since physical keyboard input normally goes through pressesBegan(:with:) before being translated into insertText(:), I was wondering: Is it possible (or supported) to call pressesBegan ourselves with a constructed UIPress/UIKey to simulate key input events in the same way the system does? Or Is the intended approach strictly to use insertText(_:) for simulating text entry, and pressesBegan should only ever be used for listening to actual hardware key presses? Thanks!

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

Hi, When pushing a view controller with a toolbar onto a UITabBarController that has a bottom accessory, the toolbar and bottom accessory overlap. UITabbarController has a bottomAccessory AViewController push BViewController. And BViewController.hidesBottomBarWhenPushed = true Xcode version : Xcode 26.0 Release Cantidate sample code let flexible = if #available(iOS 26.0, *) { UIBarButtonItem(barButtonSystemItem: .fixedSpace, target: nil, action: nil) } else { UIBarButtonItem(barButtonSystemItem: .flexibleSpace, target: nil, action: nil) } let isMemo = isMemo let emailItem = UIBarButtonItem(image: UIImage(named: "batch_gray_email.png"), style: .plain, target: self, action: #selector(onEmailTapped)) let deleteItem = UIBarButtonItem(image: UIImage(named: "batch_gray_bin.png"), style: .plain, target: self, action: #selector(onDeleteTapped)) deleteItem.tintColor = .systemRed let editItem = UIBarButtonItem(image: UIImage(named: "batch_gray_compose.png"), style: .plain, target: self, action: #selector(onEditTapped)) let memoItem = UIBarButtonItem(image: UIImage(named: "batch_note.png"), style: .plain, target: self, action: #selector(onMemoTapped)) if isMemo { setToolbarItems([flexible, deleteItem, flexible, memoItem, flexible], animated: true) } else { setToolbarItems([emailItem, flexible, deleteItem, flexible, editItem, flexible, memoItem], animated: true) } AViewController *detailViewController = [[AViewController alloc]init]; detailViewController.hidesBottomBarWhenPushed = YES; [self.navigationController pushViewController:detailViewController animated:true];

In a SwiftUI DocumentGroup, the "Create Document" button remains permanently disabled when attempting to open a document that is in a conflict state (e.g., due to simultaneous edits across devices). As a result, the user cannot create new documents, and the app becomes stuck. On macOS, the expected conflict resolution dialog appears, and the app continues to function normally. On iOS, however, the "Create Document" button stays disabled indefinitely. This behavior occurs consistently in a default SwiftUI document-based app. Steps to Reproduce: Create a new SwiftUI document-based project in Xcode; Setup iCloud Storage in Signing & Capabilities; Create an empty document and place it in a conflict state (e.g., save it simultaneously from two devices); Attempt to open the conflicted document on an iPhone or iPad; Expected Result: The user should be able to resolve the conflict and continue working; The "Create Document" button should remain functional; Actual Result: The "Create Document" button is disabled permanently; The app cannot create new documents until restarted; Environment; iOS 18, iOS 26 (latest tested); Xcode Version 16.4 (16F6) Reproduced on iPhone and iPad; Works as expected on macOS; This appears to be a blocking issue in SwiftUI’s DocumentGroup on iOS. FB20203775

I'm trying to understand how to best position my iOS apps in the event that—for whatever reason—I'm unable to release another version after submitting a version built with Xcode 26 that uses UIDesignRequiresCompatibility = YES. For the sake of this discussion, assume that my apps require updates for proper UI presentation with the Liquid Glass UI, and that I'm submitting an initial version with UIDesignRequiresCompatibility = YES. I need to make an initial update for iOS 26 right away, because running the app linked with the iOS 18.x SDK (as currently shipping on the App Store) on iOS 26 introduces UI usability problems. Now, I have actually revised the UI for Liquid Glass and this requires slightly different behaviors for the legacy UI path (iOS 18.6 or iOS 26.0 with UIDesignRequiresCompatibility = YES) versus Liquid Glass UI path. My Liquid Glass adoption UI may be "good enough," and it's certainly better than the results obtained when rebuilding with Xcode 26 and running without any updates at all (which produces a very poor, if not unusable, user experience), but I am not satisfied with these updates at present and I hope to make additional improvements before enabling the revised UI for users. However, in the event that I cannot make another update for whatever reason, I need to ensure that users will never be exposed to the UI behavior that results from running with UIDesignRequiresCompatibility = NO with the code supporting Liquid Glass adoption disabled. As long as Apple will guarantee going forward that an app built with Xcode/iOS 26.0 SDK including UIDesignRequiresCompatibility = YES in its plist will always use the old rendering mode in any future OS, then perhaps everything is fine. However, if that's not the case, then I think I need some way to detect the enablement state of the new Liquid Glass UI at runtime (which goes beyond a simple @available check, e.g. iOS 26+ with "compatibility mode" disabled) so that I can provision to have my code supporting Liquid Glass adoption be automatically enabled in the event that my app never receives another update and a future OS ignores the UIDesignRequiresCompatibility key in its plist. I'm assuming that testing the value of the key in the plist at runtime would be insufficient, since it would still be present but ignored. This sort of continuity planning seems like something that many developers would be concerned about. What is Apple's guidance on this? So far I haven't found any clear discussion of this concern. Note: My app is UIKit-based, mostly Objective-C with a bit of Swift only for TipKit.

When UIStatusBarHidden is set to YES, the navigation bar is displayed in the wrong vertical position immediately after app launch. The layout only corrects itself after the device orientation changes (e.g., rotation). Steps to Reproduce: Create a new app with a navigation controller. Set UIStatusBarHidden = YES in Info.plist. Launch the app. Expected Result: The navigation bar should appear in the correct position immediately after launch. Actual Result: The navigation bar is misaligned on first launch, and only moves to the correct position after rotating the device.

I’m using SwiftUI’s Text(_:style:) with the .relative style to show how long ago a date occurred. According to the docs: A style displaying a date as relative to now. I expected it to show the precise difference between a past date and the current date. However, I noticed that two dates that are 3 days apart both display the same relative string under certain conditions. Code snippet to reproduce- (using GMT time zone and the system calendar) IMPORTANT: To reproduce this, set your Mac’s system clock to 8 September 2025, 3:00 AM. SwiftUI’s relative style uses the current system time as its reference point, so changing the clock is necessary to see the behavior. Settings Mac is set to Central European Time zone (but this behaviour was also reproduced by one of my app's users in the US.) Mac OS Sequoia 15.5 XCode 16.4 tested on an iOS Simulator and a real iPhone both running iOS 18.5 struct TestDateView: View { var body: some View { // 8. July 10AM to 8. September 3AM = Shows 2 months 2 days let startDate1: Date = Calendar.current.date(from: .init(calendar: .current, timeZone: .gmt, year: 2025, month: 7, day: 8, hour: 10, minute: 0, second: 0))! // 5. July 10AM to 8. September 3AM = Shows 2 months 2 days let startDate2: Date = Calendar.current.date(from: .init(calendar: .current, timeZone: .gmt, year: 2025, month: 7, day: 5, hour: 10, minute: 0, second: 0))! // IMPORTANT!: Need to set MAC's clock to 8. September 3:00 AM to reproduce this bug VStack { Text(startDate1, style: .relative) Text(startDate2, style: .relative) } } } How exactly does the .relative style work internally? Is it expected that different dates can collapse into the same result like this, or is there a better way to use .relative to get more precise results? PS: I know about DateComponents and DateFormatter for exact calculations, but I’d like to understand this approach since it auto-updates natively with no timers or publishers.