Starting with Liquid Glass, the navigation items seem not to be vertically centered within the navigation bar. This makes it very challenging to position an overlay on top of the navigation bar so that it aligns naturally with other elements such as the back button, dismiss button, and others. We want to achieve this for a progress bar so that it remains visible regardless of which views are pushed underneath. Therefore, we cannot add it as a navigation item on each screen, as doing so would cause the progress bar to animate repeatedly as new screens are pushed onto the stack. This used to be easier pre liquid glass since navigation items were centered vertically within the navigation bar. The approach I tried to center the progress bar in the navigation bar: Get access to the top safe area insets through GeometryReader Get access to the the status bar height through UIWindowScene's statusBarManager Subtract status bar height from top safe area inset to calculate the navigation bar height Update the padding of the progress bar accordingly to make sure it is centered within the navigation bar This works, but as I mentioned, now the navigation items are not centered, and the amount of vertical offset they have seems to differ from one screen to another, making it impossible to come up with an additional padding value to align across devices. See how the navigation item looks like within the navigation bar in the view debugger (doesn't matter if it is UINavigationController or NavigationStack the behaviour is the same, also please note that the positioning is the same for a view without an explicit leading toolbar item, where the default back button is provided by the system when a view is pushed): Existing code (without any hacky solutions) to add a progress bar on top as overlay: struct ContentView: View { @State var shouldShowOverlay = false var body: some View { NavigationStack { NavigationLink("Go to View2") { View2() } .navigationBarTitleDisplayMode(.inline) .toolbar { ToolbarItem(placement: .topBarLeading) { Button { } label: { Image(systemName: "chevron.left") } } } } .overlay(alignment: .top) { ProgressView(value: 0.5) .frame(width: 200) // what to add as padding here // .padding(.top, 16.0) } } How it looks: Some additional observations for the navigation bar item here: There seems to be 4 _UINavigationBarPlatterAnimationViews in the view stack, prior to the bar button item:
 The first two seems to be fine, they both have (0, 0, 44, 44) for both frame and bounds
 The third one’s frame has height and width of 48.2, and x, y values of -2.1. The last one’s frame has 40,17 for height and width and 1.92 for x,y values. Both views have the following bounds: (0, 0, 44, 44). I also tried to access to the origin of the back bar button item so that I could calculate where the position the overlay, but that also didn't yield to something useful, not to mention it would also be a super hacky solution. So my ultimate question is, is there a clean way to position an overlay on top of the navigation bar that vertically aligns with other navigation bar items, or should we just position it elsewhere and do not mess with navigation bar anymore? Any input would be greatly appreciated.

When I set up a toolbar item group with multiple options and set the controlGroupStyle as .palette, and when one of the options are supposed to present a view controller, I get the following error Attempt to present <UINavigationController: 0x101813200> on <ProjectName.HomeTabBarViewController: 0x10701bc00> (from <UINavigationController: 0x107821000>) which is already presenting <_UIContextMenuActionsOnlyViewController: 0x1035c19d0>. So basically the context menu we see is under the hood a view controller that is being presented. Is there a right way of fixing it, or is it maybe something that will be fixed by Apple? This is how I set up the ToolbarItemGroup on SwiftUI and the view model ultimately presents another UINavigationController that has a UIHostingController as its view controller: .toolbar { ToolbarItemGroup(placement: .topBarTrailing) { Button("ft_commons_edit".localised, systemImage: "pencil") { viewModel.didTapEditAction() } Button("ft_commons_delete".localised, systemImage: "trash") { viewModel.didTapDeleteAction() } } label: { Image("edit-icon") .resizable() .frame(width: 24.0, height: 24.0) } } .controlGroupStyle(.palette) This is how the view looks like when presentation fails: As a workaround, I found two options that work well. I’d like to share them and ask for recommendations, just to make sure they won’t cause any unexpected issues later on: Option 1: Access the top most visible view controller and attempt presenting on it This requires the following extension: extension UIViewController { func topMostViewController() -> UIViewController { if let presentedViewController = self.presentedViewController { return presentedViewController.topMostViewController() } else if let navigationController = self as? UINavigationController, let topViewController = navigationController.topViewController { return topViewController.topMostViewController() } else if let tabBarController = self as? UITabBarController, let selectedViewController = tabBarController.selectedViewController { return selectedViewController.topMostViewController() } else { return self } } } Then called as: navigationController.topMostViewController().present(exerciseEditingNavController, animated: true) Option 2: Call dismiss before attempting to present anything This also works fine, even without any delay, the menu is first dismissed and presentation works fine afterwards, code example: navigationController.dismiss(animated: true) navigationController.present(exerciseEditingNavController, animated: true) I feel like Option 1 would be the better choice, because if this context menu is ever no longer treated as a view controller and direct presentation starts working, Option 1 would still behave correctly by presenting from the topmost visible view controller. Option 2, on the other hand, could introduce a bug by dismissing an unrelated view controller if the context menu is no longer represented as a view controller at that point. I would appreciate any advice from anyone who has experienced this, or from Apple developers. Thanks

I’m running into a macOS window restoration behavior issue where viewDidAppear (AppKit) or onAppear (SwiftUI) fires before the window’s final restored size is applied. AppKit example class MyViewController: NSViewController { override func viewDidLayout() { print("viewDidLayout: \(view.bounds.size)") } override func viewDidAppear() { print("viewDidAppear: \(view.bounds.size)") } } Logs on launch: viewDidAppear: (480.0, 270.0) viewDidLayout: (480.0, 270.0) viewDidLayout: (556.0, 476.0) viewDidLayout: (556.0, 476.0) The correct restored size is (556.0, 476.0), but viewDidAppear initially reports the old default size (480.0, 270.0). SwiftUI equivalent struct MyView: View { var body: some View { GeometryReader { geo in VStack {} .onAppear { print("onAppear: \(geo.size)") } .onChange(of: geo.size) { print("onChange: \(geo.size)") } } } } Logs on launch: onAppear: (900.0, 450.0) onChange: (680.0, 658.0) Problem I need to run some setup code: Only once After the view/window has its correct restored size Without rerunning on every layout or geometry change Question What is the proper macOS-native way to perform one-time startup logic only after the final restored window size is available? Is there a recommended lifecycle hook or pattern for this? Also, is it expected behavior that onAppear / viewDidAppear reports the pre-restoration size, or is it a bug?

FB: FB22577211 The following trivial SwiftUI Text rendering causes wrong text layout and truncated text. The text should take the required height to render the text without truncation. Adding fixedSize does also not solve this. This bug only happens on devices and not on the simulator. Confirmed with iPhone 15 and iOS 26.4.1 but my colleague used another iPhone so it’s multiple iPhone devices. import SwiftUI let txt = """ Es sollte die erste Japan-Tournee von vielen werden, kein anderes Land – abgesehen von Österreich und der Schweiz – bereisten die Berliner Philharmoniker häufiger. Wie kam es zu dem überschäumend herzlichen Empfang, der dem Orchester bei seinem ersten Gastspiel in Tokio bereitet wurde und wie wurde das Land zu einer »zweiten Heimat« für die Berliner? Ein konkreter historischer Grundstein für das hohe Ansehen klassischer Musik »made in Germany« in Japan wurde bereits im 19. Jahrhunderts gelegt: Als Teil von umfassenden gesellschaftlichen Modernisierungsmaßnahmen vergab die Regierung ab 1868 Stipendien an junge japanische Intellektuelle, damit diese an den besten internationalen Instituten studieren konnten. Berlin wurde – neben Wien – als globales Zentrum der Musik betrachtet, und so erhielten viele japanische Studierende um die Jahrhundertwende die Gelegenheit, von Komponisten wie etwa Max Bruch zu lernen. Zurück in der Heimat, teilten sie ihre Begeisterung für die europäische Kunstmusik sowie das Wissen um die instrumentale und kompositorische Praxis der klassisch-romantischen Tradition. """ struct ContentView: View { var body: some View { VStack { Text(txt) } .padding(.leading, 20) .padding(.trailing, 20) .frame(maxWidth: .infinity) } } This is also enough: Text(txt) .padding(.horizontal, 20) .fixedSize(horizontal: false, vertical: true) Expected: Text is rendered without truncation / ellipsis. Actual: Text is rendered with too small height / missing one line so it’s truncated / with ellipsis.

On macOS 26, the Label part of a LabeledContent control and the Section.header part of a Section do not seem to honour view modifiers like .controlSize(.small) when used inside a Form with .formStyle(.grouped). Is there a way to make them respect the control size? Example: Form { Section("Details") { LabeledContent("Company", value: "Apple") } } .formStyle(.grouped) .controlSize(.small) // This only effects 'Apple' This produces a view where the value "Apple" is using a smaller font size but the label and the section header are not. I've tried (I think) almost every variation I can think of in terms of creating a LabeledContent and applying .controlSize but all of them come up short. The Form appears to always override my view modifiers for the section heading and label. Example 2: Form { Section { LabeledContent { Text("Company") .controlSize(.small) // Has no effect. } label: { Text("Apple") // Correctly resized to .small. } } header: { Text("Details") .controlSize(.small) // Has no effect. } } .formStyle(.grouped) .controlSize(.small) The best I've been able to come up with is a custom LabeledContentStyle that manually applies the layout and the styling, but that requires I explicitly "recreate" the macOS look-and-feel of left aligned labels and right aligned values by way of an HStack and Spacer. Have I overlooked a way to style a Form or LabeledContent that would provide the results I'm looking for?

When applying the .accessibilityIdentifier(_:) modifier to a SwiftUI TextField, the identifier is correctly added to the SwiftUI Accessibility Tree (visible in Accessibility Inspector), but it is not assigned to the accessibilityIdentifier property of the underlying UITextField instance. This causes issues for developers who monitor global notifications, such as UITextField.textDidChangeNotification. When a notification is received, the object (the UITextField) has a nil identifier, making it impossible to programmatically determine which specific text field triggered the event. Steps to Reproduce: Create a SwiftUI view containing a TextField. Apply .accessibilityIdentifier("TargetTextField") to that TextField. Set up an observer (via NotificationCenter or onReceive) for UITextField.textDidChangeNotification. Run the app and type into the text field. Inspect the accessibilityIdentifier property of the UITextField object provided by the notification. Expected Result: The UITextField.accessibilityIdentifier should be "TargetTextField". Actual Result: The UITextField.accessibilityIdentifier is nil.

Hi folks, I've used a NavigationSplitView within one of the tabs of my app since iOS 16, but with the new styling in iOS 18 the toolbar region looks odd. In other tabs using e.g. simple stacks, the toolbar buttons are horizontally in line with the new tab picker, but with NavigationSplitView, the toolbar leaves a lot of empty space at the top (see below). Is there anything I can do to adjust this, or alternatively, continue to use the old style? Thanks!

In SF Symbols 7, I'm observing a discrepancy between the .replace animation previewed in the SF Symbols app and the result when using the code template the app provides. Expected behavior: When previewing the .replace animation in the SF Symbols app (with Magic Replace preferred), the transition looks like: Actual behavior: When I implement the animation using the exact code template generated by the SF Symbols app, the result looks like: My code: struct PlaygroundSwiftUIView: View { @State var name = "folder.circle" var body: some View { Image(systemName: name) .font(.system(size: 60)) .contentTransition(.symbolEffect(.replace)) .onTapGesture { name = "tree" } } } #Preview { PlaygroundSwiftUIView() } The animation rendered in my app does not match the preview shown in the SF Symbols app. The drawOff animation is partly missing. Is there something missing from the code template, or is there an additional configuration step required to achieve the correct Replace effect?

Hello everyone, I’m running into an issue where a partial sheet repeatedly presents and dismisses in a loop. Setup The main screen is presented using fullScreenCover From that screen, a button triggers a standard partial-height sheet The sheet is presented using .sheet(item:) Expected Behavior Tapping the button should present the sheet once and allow it to be dismissed normally. Actual Behavior After the sheet is triggered, it continuously presents and dismisses. What I’ve Verified The bound item is not being reassigned in either the parent or the presented view There is no .task, .onAppear, or .onChange that sets the item again The loop appears to happen without any explicit state updates Additional Context I encountered a very similar issue when iOS 26.0 was first released At that time, moving the .sheet modifier to a higher parent level resolved the issue The problem has now returned on iOS 26.4 beta I’m currently unable to reproduce this in a minimal sample project, which makes it unclear whether: this is a framework regression, or I’m missing a new presentation requirement Environment iOS: 26.4 beta Xcode: 26.4 beta I’ve attached a screen recording of the behavior. Has anyone else experienced this with a fullScreenCover → sheet flow on iOS 26.4? Any guidance or confirmation would be greatly appreciated. Thank you!

During refactoring of an app I made a typo which leads to a misleading error message in Xcode 26.4. I could reproduce it with a small sample code in Swift Playground. Is it a bug which should be reported? Details: I have an array containing two strings. Using a ForEach loop is fine: ForEach(appData.dataArray, id: \.self) { value in Text("\(value.subject)\t\(value.room)") } but with a typo in the Text line I got an error on the ForEach line: ForEach(appData.dataArray, id: \.self) { value in --> Cannot convert value of type '[MyArray]' to expected argument type 'Binding' Text("\(value.subject)\t\(value.subject.room)") } Complete sample code from Swift Playground (macOS 26): import SwiftUI class MyArray : Hashable, Equatable, Identifiable, ObservableObject, Codable { let id = UUID() @Published var subject: String @Published var room : String private enum CodingKeys : String, CodingKey { case subject case room } init(subject : String, room : String) { self.subject = subject self.room = room } func encode(to encoder: Encoder) throws { var container = encoder.container(keyedBy: CodingKeys.self) try container.encode(subject, forKey: .subject) try container.encode(room, forKey: .room) } required init(from decoder: Decoder) throws { let container = try decoder.container(keyedBy: CodingKeys.self) subject = try container.decode(String.self, forKey: .subject) room = try container.decode(String.self, forKey: .room) } static func == (v1: MyArray, v2: MyArray) -> Bool { let result = v1.id == v2.id return result } func hash(into hasher: inout Hasher) { hasher.combine(id) } } public class AppData : ObservableObject { @Published var dataArray : [MyArray] = [] init() { dataArray.append(MyArray(subject: "Foo", room: "Bar")) dataArray.append(MyArray(subject: "Foo", room: "Batz")) } } struct ContentView: View { @EnvironmentObject var appData : AppData var body: some View { ForEach(appData.dataArray, id: \.self) { value in Text("\(value.subject)\t\(value.subject.room)") // to fix the error replace value.subject.room with value.room } } } @main struct MyApp: App { var appData = AppData() var body: some Scene { WindowGroup { ContentView() .environmentObject(appData) } } }

Hi, I have a list cell with a play button and a text label. When tapping the play button, it plays an audio, and when long-pressed, it plays the audio slowly. The long press works as per the example code below, but once a contextMenu is added, the long-press gesture of the play button is ignored (even though it's a small element in the cell), and the context menu is presented instead. Is there a way to allow for the context menu long-press to respect the long-press gesture of a child element in the cell on which it's defined? I also tried with highPriorityGesture but to no effect. Example code: HStack { Button { print("Play") } label: { Image(systemName: "play.circle") .onLongPressGesture(minimumDuration: 0.5) { print("Play slowly") } } Text("Audio cell") .frame(maxWidth: .infinity, alignment: .leading) } .contextMenu { Button("Hello") { print("hello") } Button("Goodbye") { print("goodbye") } }

Summary When a SwiftUI widget uses a Link containing an Image modified with .widgetAccentedRenderingMode (using any mode except .fullColor), tapping the image on the widget launches the app but does not pass the expected deep link URL to the SceneDelegate. Steps to Reproduce Create a SwiftUI Widget View with a Link: struct ImageView: View { var image: UIImage var body: some View { Link(URL(string: "myapp://image")!) { Image(uiImage: image) .resizable() .widgetAccentedRenderingMode(.accentedDesaturated) // or any mode other than .fullColor .scaledToFill() .clipped() } } } Add Custom URL Scheme in Info.plist: <dict> <key>CFBundleURLName</key> <string>com.company.myapp</string> <key>CFBundleURLSchemes</key> <array> <string>myapp</string> </array> </dict> Implement Deep Link Handling in SceneDelegate: func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { if let url = connectionOptions.urlContexts.first?.url { handle(url) } } func scene(_ scene: UIScene, openURLContexts urlContexts: Set<UIOpenURLContext>) { if let url = urlContexts.first?.url { handle(url) } } private func handle(_ url: URL) { // Process URL here } Run the application on a device or simulator. Add the widget to the Home Screen. Tap the image inside the widget. Expected Result The application launches and receives the URL in SceneDelegate, as expected. Actual Result The application launches, but the URL is not passed to SceneDelegate. Both connectionOptions.urlContexts and openURLContexts are empty.

I'm almost having a heart attack with this "a DancingCreatures view" issue. I must be really dumb I've tried everything and the question just won't move forward. Someone, for the love of God, explain to me what it would be.

My visionOS 26.3 app displays a diorama-like scene in a RealityView in a mixed immersive space, about 1 meter square, with view attachments floating above the scene. Each view attachment fades out after user interaction, by animating the view's opacity. What I'm observing is that depending on the position of a view attachment relative to the scene and the camera, an unwanted cutout effect is observed (presumably because of draw order issues), as shown in the right column in the screenshots below. YouTube video link of these sequences: https://youtu.be/oTuo0okKCkc (19 seconds) My question: How does visionOS determine the view attachment draw order relative to the RealityView scene? If I better understood how the draw order is determined, I could modify my scene to ensure that the view attachments were always drawn after the scene, fixing the unwanted cutout effect. I've successfully used ModelSortGroupComponent to control the draw order of entities within the RealityView scene, but my understanding is that this approach cannot be used with view attachments. I've submitted FB22014370 about this issue. Thank you.

Hi, I'm trying to create a custom TextField component where we can have our own custom FormatStyle as a param and then it will change the value binding according to the FormatStyle. It worked with State<Any?> like for example $textValue. But when I use .constant(2000) for instance, the Formatting doesn't work. So is there any way to detect whether the value param is constant or not? Thank you.

.navigationTitle disappears when using .toolbar and List inside NavigationStack (iOS 26 beta) Summary In iOS 26 beta, using .navigationTitle() inside a NavigationStack fails to render the title when combined with a .toolbar and a List. The title initially appears as expected after launch, but disappears after a second state transition triggered by a button press. This regression does not occur in iOS 18. Steps to Reproduce Use the SwiftUI code sample below (see viewmodel and Reload button for state transitions). Run the app on an iOS 26 simulator (e.g., iPhone 16). On launch, the view starts in .loading state (shows a ProgressView). After 1 second, it transitions to .loaded and displays the title correctly. Tap the Reload button — this sets the state back to .loading, then switches it to .loaded again after 1 second. ❌ After this second transition to .loaded, the navigation title disappears and does not return. Actual Behavior The navigation title displays correctly after the initial launch transition from .loading → .loaded. However, after tapping the “Reload” button and transitioning .loading → .loaded a second time, the title no longer appears. This suggests a SwiftUI rendering/layout invalidation issue during state-driven view diffing involving .toolbar and List. Expected Behavior The navigation title “Loaded Data” should appear and remain visible every time the view is in .loaded state. ✅ GitHub Gist including Screen Recording 👉 View Gist with full details Sample Code import SwiftUI struct ContentView: View { private let vm = viewmodel() var body: some View { NavigationStack { VStack { switch vm.state { case .loading: ProgressView("Loading...") case .loaded: List { ItemList() } Button("Reload") { vm.state = .loading DispatchQueue.main.asyncAfter(deadline: .now() + 1) { vm.state = .loaded } } .navigationTitle("Loaded Data") } } .toolbar { ToolbarItem(placement: .navigationBarTrailing) { Menu { Text("hello") } label: { Image(systemName: "gearshape.fill") } } } } } } struct ItemList: View { var body: some View { Text("Item 1") Text("Item 2") Text("Item 3") } } @MainActor @Observable class viewmodel { enum State { case loading case loaded } var state: State = .loading init() { DispatchQueue.main.asyncAfter(deadline: .now() + 1) { self.state = .loaded } } }

Navigation title scroll along with the content in iOS 26. working fine in iOS 18 and below. One of my UI component is outside the scrollview which is causing the issue. var body: some View { VStack { Rectangle() .frame(maxWidth: .infinity) .frame(height: 60) .padding(.horizontal) .padding(.top) ScrollView { ForEach(0...5, id: \.self) { _ in RoundedRectangle(cornerRadius: 10) .fill(.green) .frame(maxWidth: .infinity) .frame(height: 100) .padding(.horizontal) } } } .navigationTitle("Hello World") } }

My iPadOS app can open .xml files. In my XMLApp.swift, I hooked up a: var body: some Scene { WindowGroup(id: "main") { .commands CommandGroup(replacing: .newItem) { ... Button(.openDot) { openXMLFile() } ... Next, I entered a new UTImportedTypeDeclarations / UTExportedTypeDeclarations in Project Settings -> Target -> Info -> Document Types, Exported Type Identifiers, Imported Type Identifiers, for the XML file-type: ... <key>UTImportedTypeDeclarations</key> <array> <dict> <key>UTTypeConformsTo</key> <array> <string>public.data</string> <string>public.xml</string> <string>public.content</string> </array> ... As soon as I do that, Xcode creates an additional Open... menu entry all the way at the bottom of the File menu. I cannot get rid of this additional menu entry. Its state is disabled (grayed out). I have my own Open (per the code above), which also responds to ⌘ - O. My menu entry works fine, as long as I disable the same keyboard shortcut so they don't collide. The extra Open entry is also displayed on the matching iPadOS simulator. From the same codebase, the Open is not displayed on the Mac (targeting macOS, not Catalyst). On macOS, only my Open is in the File menu, as expected. Why is there a duplicate Open menu entry and how do I get rid of it?

Could anyone help confirm if this is a bug and suggest possible solutions? Thanksssss In iOS 18, when using Zoom NavigationTransition, the toolbar from the destination view may randomly appear on the source view after navigating back with the swipe-back gesture. Re-entering the destination view and navigating back again can temporarily resolve the issue, but it may still occur intermittently. This bug only happens with Zoom NavigationTransition and does not occur when using a button tap to navigate back. import SwiftUI struct test: View { @Namespace private var namespace var body: some View { NavigationStack { NavigationLink { Image("img1") .resizable() .navigationTransition(.zoom(sourceID: 1, in: namespace)) .toolbar { ToolbarItem(placement: .bottomBar) { Text("destination noDisappear") } } } label: { Image("img1") .resizable() .frame(width: 100, height: 100) .matchedTransitionSource(id: 1, in: namespace) .toolbar { ToolbarItem(placement: .bottomBar) { Text("source toolbar") } } } } } }

Because of this, in Swift 6 mode, Xcode complains about the access, and ask me to use unsafe keyword. To fix it, I need to do this: Anyone can explain this abrupt nonisolated(unsafe) change?