At WWDC25 we launched a new type of Lab event for the developer community - Group Labs. A Group Lab is a panel Q&A designed for a large audience of developers. Group Labs are a unique opportunity for the community to submit questions directly to a panel of Apple engineers and designers. Here are the highlights from the WWDC25 Group Lab for UI Frameworks. How would you recommend developers start adopting the new design? Start by focusing on the foundational structural elements of your application, working from the "top down" or "bottom up" based on your application's hierarchy. These structural changes, like edge-to-edge content and updated navigation and controls, often require corresponding code modifications. As a first step, recompile your application with the new SDK to see what updates are automatically applied, especially if you've been using standard controls. Then, carefully analyze where the new design elements can be applied to your UI, paying particular attention to custom controls or UI that could benefit from a refresh. Address the large structural items first then focus on smaller details is recommended. Will we need to migrate our UI code to Swift and SwiftUI to adopt the new design? No, you will not need to migrate your UI code to Swift and SwiftUI to adopt the new design. The UI frameworks fully support the new design, allowing you to migrate your app with as little effort as possible, especially if you've been using standard controls. The goal is to make it easy to adopt the new design, regardless of your current UI framework, to achieve a cohesive look across the operating system. What was the reason for choosing Liquid Glass over frosted glass, as used in visionOS? The choice of Liquid Glass was driven by the desire to bring content to life. The see-through nature of Liquid Glass enhances this effect. The appearance of Liquid Glass adapts based on its size; larger glass elements look more frosted, which aligns with the design of visionOS, where everything feels larger and benefits from the frosted look. What are best practices for apps that use customized navigation bars? The new design emphasizes behavior and transitions as much as static appearance. Consider whether you truly need a custom navigation bar, or if the system-provided controls can meet your needs. Explore new APIs for subtitles and custom views in navigation bars, designed to support common use cases. If you still require a custom solution, ensure you're respecting safe areas using APIs like SwiftUI's safeAreaInset. When working with Liquid Glass, group related buttons in shared containers to maintain design consistency. Finally, mark glass containers as interactive. For branding, instead of coloring the navigation bar directly, consider incorporating branding colors into the content area behind the Liquid Glass controls. This creates a dynamic effect where the color is visible through the glass and moves with the content as the user scrolls. I want to know why new UI Framework APIs aren’t backward compatible, specifically in SwiftUI? It leads to code with lots of if-else statements. Existing APIs have been updated to work with the new design where possible, ensuring that apps using those APIs will adopt the new design and function on both older and newer operating systems. However, new APIs often depend on deep integration across the framework and graphics stack, making backward compatibility impractical. When using these new APIs, it's important to consider how they fit within the context of the latest OS. The use of if-else statements allows you to maintain compatibility with older systems while taking full advantage of the new APIs and design features on newer systems. If you are using new APIs, it likely means you are implementing something very specific to the new design language. Using conditional code allows you to intentionally create different code paths for the new design versus older operating systems. Prefer to use if #available where appropriate to intentionally adopt new design elements. Are there any Liquid Glass materials in iOS or macOS that are only available as part of dedicated components? Or are all those materials available through new UIKit and AppKit views? Yes, some variations of the Liquid Glass material are exclusively available through dedicated components like sliders, segmented controls, and tab bars. However, the "regular" and "clear" glass materials should satisfy most application requirements. If you encounter situations where these options are insufficient, please file feedback. If I were to create an app today, how should I design it to make it future proof using Liquid Glass? The best approach to future-proof your app is to utilize standard system controls and design your UI to align with the standard system look and feel. Using the framework-provided declarative API generally leads to easier adoption of future design changes, as you're expressing intent rather than specifying pixel-perfect visuals. Pay close attention to the design sessions offered this year, which cover the design motivation behind the Liquid Glass material and best practices for its use. Is it possible to implement your own sidebar on macOS without NSSplitViewController, but still provide the Liquid Glass appearance? While technically possible to create a custom sidebar that approximates the Liquid Glass appearance without using NSSplitViewController, it is not recommended. The system implementation of the sidebar involves significant unseen complexity, including interlayering with scroll edge effects and fullscreen behaviors. NSSplitViewController provides the necessary level of abstraction for the framework to handle these details correctly. Regarding the SceneDelagate and scene based life-cycle, I would like to confirm that AppDelegate is not going away. Also if the above is a correct understanding, is there any advice as to what should, and should not, be moved to the SceneDelegate? UIApplicationDelegate is not going away and still serves a purpose for application-level interactions with the system and managing scenes at a higher level. Move code related to your app's scene or UI into the UISceneDelegate. Remember that adopting scenes doesn't necessarily mean supporting multiple scenes; an app can be scene-based but still support only one scene. Refer to the tech note Migrating to the UIKit scene-based life cycle and the Make your UIKit app more flexible WWDC25 session for more information.

Calling contactAccessPicker results in a blank sheet and a jetsam error, rather than the expected contact picker, using Apple’s sample code, only on device with iOS 26.2.1. This is happening on a iPhone 17 Pro Max running 26.2.1, and not on a simulator. I’m running Apple's sample project Accessing a person’s contact data using Contacts and ContactsUI Steps: Run the sample app on device running iOS 26.2.1. Use the flow to authorize .limited access with 1 contact: Tap request access, Continue, Select Contacts. Select a contact, Continue, Allow Selected Contact. This all works as expected. Tap the add contact button in the toolbar to add a second contact. Expected: This should show the Contact Access Picker UI. Actual: Sheet is shown with no contents. See screenshot of actual results on iOS device running 26.2.1. Reported as FB21812568 I see a similar (same?) error reported for 26.1. It seems strange that the feature is completely broken for multiple point releases. Is anyone else seeing this or are the two of us running into the same rare edge case? Expected Outcome, seen on simulator running 26.2 Actual outcome, seen on device running 26.2.1

iOS 15 - iOS 26.x, SwiftUI, Xcode 26.1.1 (rewritten without links) I’m attempting to add the capability to export a file from CoreData. Since ShareLink requires iOS16+, I found an article showing how to create a UIKit wrapper for 'UIActivityViewController' This does work, but I end up with multiple files instead of one. How do I merge this into one file? Note: I don’t think I want to write to the app’s document directory – rather I’d like to allow the user to export to iCloud. Eventually, I’d like to share a list of dates with descriptions and if someone puts a sensitive date in there – I don’t want it to be left in a directory. I would include a warning that the file that they export needs to be handled with care if there are any sensitive dates. Some might consider birthdays as private information, right? I'd also like to be able to name the file - so far when the share sheet comes up, I select "Save to Files" and it uses a default name of text.txt My next step is to be able to import a CSV file (roundtrip) - could you point me to resources for how to do that?

Context: Xcode 26.3, iOS 18.7.6 on iPhone Xs In this iOS app, I call UIActivityViewController to let user Airdrop files from the app. When trying to send a URL whose file name contains some characters like accentuated (-, é, '), the transfer fails. Removing those characters makes it work without problem. The same app running on Mac (in iPad mode) works with both cases. I also noticed that even when airdrop fails, there is no error reported by activityVC.completionWithItemsHandler = { activity, success, items, error in } Are those known issues ?

My basic need is that I have unicode symbols which compose to a marked musical note. I'd like that note to be rotated upside down. Obviously, I could do this by sticking each into a View of some sort, and applying rotation effect. Indeed, I've done this for the part of my app where these notes are the labels of Buttons. However, the results of pressing the buttons need to be displayed, and on most of my app, this is a simple String. However, I can find no way to rotate individual glyphs of a String. And I'm not keen to write a compositor to layout View like glyphs in a String. Is there a way to make a font by finding individual glyphs, doing the transform, and packaging them into a new specialized font, without needed to use an external Font making application?

Hi everyone, I am experiencing a strange rendering issue on iPadOS 26 when sizeRestrictions.minimumSize is set on a UIWindowScene. After rotating the device and then rotating it back to the original orientation, the window appears to be stretched based on its previous dimensions. This resulting "stretched" area does not resize or redraw correctly, leaving a significant black region on the screen. Interestingly, as soon as I interact with the window (e.g., a slight drag or touch), the UI snaps back to its intended state and redraws perfectly. Here is a sample code and capture of behavior. class SceneDelegate: UIResponder, UIWindowSceneDelegate { var window: UIWindow? func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { guard let windowScene = (scene as? UIWindowScene) else { return } windowScene.sizeRestrictions?.minimumSize = CGSize( width: 390, height: 844 // larger than the height of iPad in landscape ) // initialize... } } Has anyone else encountered this behavior? If so, are there any known workarounds to force a layout refresh or prevent this "ghost" black area during the rotation transition? Any insights would be greatly appreciated. Thanks!

If I see it correctly, it is currently not possible to validate a drop operation on a DynamicViewContent when using dropDestination? Just a simple example: Let's say I build a folder view on macOS where I can arrange folders freely. In this case I need to use DynamicViewContent.dropDestination to get an insertion index on drop. However, it seems that methods like dropConfiguration do not have any effect. Als dropDestionation(…, isTargeted:) seems not to be available. Here is my sample code: struct FolderRow: View { let folder: Folder var body: some View { DisclosureGroup(isExpanded: .constant(true)) { ForEach(folder.children) { child in FolderRow(folder: child) } .dropDestination(for: Folder.self) { item, idx in print("Dropped at \(idx)") } } label: { Label(folder.name, systemImage: "folder") .draggable(folder) .dropDestination(for: Folder.self) { items, _ in print("Dropped on Item") } } .dropConfiguration { session in DropConfiguration(operation: .move) } } } struct ContentView: View { @State private var folder: Folder = Folder.sampleData @State private var selection: Set<UUID> = [] var body: some View { NavigationSplitView { List(selection: $selection) { FolderRow(folder: folder) } } detail: { EmptyView() } } } The dropConfiguration is applied on the Label (in this case the "Move" cursor is used instead of the "Copy" cursor). Is there any way to do that or is it just an omission in Swift UI?

My document-based UIKit app can open plain text files such as .txt files. When tapping a particular button I want to be able to select a folder, but when using the code below, the document picker allows me to select folders as well as .txt files: class DocumentViewController: UIDocumentViewController, UIDocumentPickerDelegate { override func viewDidAppear(_ animated: Bool) { let documentPicker = UIDocumentPickerViewController(forOpeningContentTypes: [.folder]) documentPicker.delegate = self present(documentPicker, animated: true) } } If I remove the text file entry from the Info.plist's document types list, it works as expected. Is this a bug and if yes, is there a workaround? <key>CFBundleDocumentTypes</key> <array> <dict> <key>CFBundleTypeName</key> <string>Text</string> <key>CFBundleTypeRole</key> <string>Editor</string> <key>LSHandlerRank</key> <string>Default</string> <key>LSItemContentTypes</key> <array> <string>public.text</string> </array> </dict> </array> I created FB22254960.

UIActivity is not annotated with concurrency information. Does anyone know if subclasses you create will always run on the @MainActor ?

So I'm in the middle of an asynchronous file operation. I publish an NSProgress and it displays wonderfully in Finder. But it is a folder and while the operation is in progress the user should not be allowed to enter it, modify it, etc, while the work is being done. I want to do this to protect the user from doing something silly. But Finder does not prevent the selection with the published progress. And while it would be kind of dumb to do - the user can just go about adding/removing contents to the folder while it has progress. If I remember correctly publishing an NSProgress did use to prevent the file from being selectable in Finder until either the progress finished or my app is quit (or maybe not)? But now the user is free to select, edit, modify during progress which could cause problems if the user does something unexpectedly silly. Is there a way to mark the file 'unselectable' with the published progress? Thanks in advance.

I'm using UITabBarAppearance to customize my TabBar in a SwiftUI app. The customization works perfectly on iOS 18 and earlier, but after updating to iOS 26, the unselected tab items no longer respect my color settings - they just appear black (they are on a white background).Here's my simplified setup: struct ContentView: View { var body: some View { TabView { Text("Home") .tabItem { Image(systemName: "house") Text("Home") } .tag(0) Text("Settings") .tabItem { Image(systemName: "gear") Text("Settings") } .tag(1) } .onAppear { setupTabBarAppearance() } } private func setupTabBarAppearance() { let appearance = UITabBarAppearance() appearance.configureWithOpaqueBackground() let itemAppearance = UITabBarItemAppearance() // These settings work for selected items itemAppearance.selected.iconColor = .systemBlue itemAppearance.selected.titleTextAttributes = [ .font: UIFont.systemFont(ofSize: 10), .foregroundColor: UIColor.systemBlue ] // These settings STOPPED working on iOS 26 for unselected items itemAppearance.normal.iconColor = .gray itemAppearance.normal.titleTextAttributes = [ .font: UIFont.systemFont(ofSize: 10), .foregroundColor: UIColor.gray ] appearance.stackedLayoutAppearance = itemAppearance appearance.inlineLayoutAppearance = itemAppearance appearance.compactInlineLayoutAppearance = itemAppearance UITabBar.appearance().standardAppearance = appearance UITabBar.appearance().scrollEdgeAppearance = appearance } }

When using ShareLink in SwiftUI to share an image, the “Save Image” action dismisses not only the share sheet but also the presenting SwiftUI view. The behavior differs depending on whether the photo library permission alert appears. Observed behavior: The first time the user taps Save Image, the system permission alert appears. After granting permission, the image saves successfully and the share sheet dismisses normally. On subsequent attempts, the image is saved successfully, but both the share sheet and the presenting view are dismissed unexpectedly. Expected behavior: After saving the image, only the share sheet should dismiss. The presenting SwiftUI view should remain visible. Steps to Reproduce Present a SwiftUI view using .sheet. Inside that view, add a ShareLink configured to export a PNG image using Transferable. Tap the ShareLink button. Choose Save Image. Grant permission the first time (if prompted). Repeat the action. Result: On subsequent saves, the share sheet dismisses and the presenting view is dismissed as well. Sample code ` internal import System import UniformTypeIdentifiers import SwiftUI struct RootView: View { @State private var isPresented: Bool = false var body: some View { ZStack { Color.white Button("Show parent view") { isPresented = true } } .sheet(isPresented: $isPresented) { ParentView() } } } struct ParentView: View { @State private var isPresented: Bool = false var body: some View { NavigationStack { ZStack { Color.red.opacity(0.5) } .toolbar { ToolbarItem() { let name = "\(UUID().uuidString)" let image = UIImage(named: "after")! return ShareLink( item: ShareableImage(image: image, fileName: name), preview: SharePreview( name, image: Image(uiImage: image) ) ) { Image(uiImage: UIImage(resource: .Icons.share24)) .resizable() .foregroundStyle(Color.black) .frame(width: 24, height: 24) } } } } } } struct ShareableImage: Transferable { let image: UIImage let fileName: String static var transferRepresentation: some TransferRepresentation { FileRepresentation(exportedContentType: .png) { item in let fileURL = FileManager.default.temporaryDirectory .appendingPathComponent(item.fileName) .appendingPathExtension("png") guard let data = item.image.pngData() else { throw NSError(domain: "ImageEncodingError", code: 0) } try data.write(to: fileURL) return SentTransferredFile(fileURL) } } } `

There is a long-standing, structural issue with the iPadOS Korean IME when using a hardware keyboard. The IME forcibly intercepts the " (quote) keydown event and injects Unicode smart/curved quotes (“ or ”) directly into the text field. This hardcoded behavior ignores both: User Settings: The global "Smart Punctuation" toggle in [Settings > General > Keyboard] is completely ignored. Developer APIs: Setting UITextInputTraits.smartQuotesType = .no on a UITextView or UITextField has absolutely no effect when the Korean keyboard is active. Steps to Reproduce: Set smartQuotesType = .no on a standard UITextView. Connect a hardware keyboard. Switch input language to English -> Press the quote key. (Result: ASCII straight quote " - Correct behavior) Switch input language to Korean -> Press the quote key. (Result: Unicode curved quote “ - Incorrect behavior) Impact on Developers & Users: Because the OS IME forcefully injects the curved Unicode character before the app can process the raw key event, developers building code editors, markdown editors, or specific word processors (like Google Docs) cannot prevent this behavior. We cannot provide a standard text-editing experience for Korean users without forcing them to manually toggle their keyboard language to English just to type a straight quote. Expected Behavior: The Korean hardware keyboard IME must respect UITextInputTraits.smartQuotesType and the global OS toggle. Please provide a mechanism for developers and users to bypass this forced CJK typography rule.

Hi! I've encountered strange bug in iOS 26. The MultiDatePicker component exhibits unreliable behavior when attempting to deselect previously chosen dates. Users often need to tap a selected date multiple times (e.g., tap to deselect, tap to re-select, then tap again to deselect) for the UI to correctly register the deselection and update the displayed state. This issue does not occur on iOS 18 or Xcode 26 previews, where MultiDatePicker functions as expected, allowing single-tap deselection. The bug only occurs on physical device or simulator. I can't lie, I have multidatepicker as crucial component in my larger app and can't really find a solution to this. Has anyone encountered this problem before? Here is the code to replicate the issue: import SwiftUI struct ContentView: View {     @ State private var selectedDates: Set = []     var body: some View {         NavigationStack {             Form {                 Section {                     MultiDatePicker("Select Dates", selection: $selectedDates)                 } header: {                     Text("MultiDatePicker Bug Test")                 }                 Section {                     Text("Selected Dates Count: (selectedDates.count)")                     ForEach(Array(selectedDates).sorted(by: {                         Calendar.current.date(from: $0)! < Calendar.current.date(from: $1)!                     }), id: .self) { dateComponent in                         if let date = Calendar.current.date(from: dateComponent) {                             Text(date.formatted(date: .long, time: .omitted))                         }                     }                 } header: {                     Text("Current State of Selected Dates")                 }             }             .navigationTitle("Date Picker Bug")         }     } } #Preview {     ContentView() }

I'm building a macOS app with two separate NSPanel windows, both using the new liquid glass material (NSVisualEffectView / macOS 26). The UI intentionally has two separate floating panels visible at the same time. The problem: only the key window displays the active liquid glass appearance. The non-key panel always renders with the inactive/foggy appearance, even with: NSWindowStyleMaskNonactivatingPanel canBecomeKeyWindow = false orderFrontRegardless() addChildWindow(_:ordered:) Is there any way — documented or otherwise — to force the active liquid glass appearance on a non-key NSPanel? Or is this fundamentally a compositor-level restriction? If it's impossible with two separate windows, is there an alternative approach to achieve two visually separate liquid glass boxes that both appear active simultaneously?

There is a long-standing, structural issue with the iPadOS Korean IME when using a hardware keyboard. The IME forcibly intercepts the " (quote) keydown event and injects Unicode smart/curved quotes (“ or ”) directly into the text field. This hardcoded behavior ignores both: User Settings: The global "Smart Punctuation" toggle in [Settings > General > Keyboard] is completely ignored. Developer APIs: Setting UITextInputTraits.smartQuotesType = .no on a UITextView or UITextField has absolutely no effect when the Korean keyboard is active. Steps to Reproduce: Set smartQuotesType = .no on a standard UITextView. Connect a hardware keyboard. Switch input language to English -> Press the quote key. (Result: ASCII straight quote " - Correct behavior) Switch input language to Korean -> Press the quote key. (Result: Unicode curved quote “ - Incorrect behavior) Impact on Developers & Users: Because the OS IME forcefully injects the curved Unicode character before the app can process the raw key event, developers building code editors, markdown editors, or specific word processors (like Google Docs) cannot prevent this behavior. We cannot provide a standard text-editing experience for Korean users without forcing them to manually toggle their keyboard language to English just to type a straight quote. Expected Behavior: The Korean hardware keyboard IME must respect UITextInputTraits.smartQuotesType and the global OS toggle. Please provide a mechanism for developers and users to bypass this forced CJK typography rule.

I want to create SplitView App for macOS like Apple Mail. Is it possible using swiftUI NavigationSplitView or should I use AppKit to achieve it. I want exact toolbar buttons also. Filter button will be in Invoice list pane and other buttons in the details pane. Also, I want details pane completely collapsable(just like in Mail app).

Hi! So while Date is supported for @Parameter in an App Intent, I just discovered that Xcode will not let me use use it in a parametrized App Shortcut phrase. In my case, I would like to give the option to say "today", tomorrow", or "day after tomorrow" for the date. Am I missing something? Any hints on the best way to approach this?

On macOS 26, how do you support the Preferred Text Size value as defined in the Accessibility Settings? Historically, "Dynamic Type" has not been available on macOS. However, the user has some control over text size through the Accessibility Settings. On macOS 26, a small subset of applications are honouring changes to that value include Finder, Mail, and sidebars in many applications. Dynamic sizing in table views has been available on macOS for awhile. But Mail.app, in particular, is also adjusting the font sizes used in the message's body pane while the Finder is adjusting font sizes used for Desktop icons. I can't find an NSNotification that is fired when the user adjusts the Accessibility Text Size slider, nor can I find an API to read the current value. NSFont.preferredFont(forTextStyle:options:) looks promising but the fonts returned do not appear to take the user's Accessibility setting into account. (Nor do they update dynamically.) SwiftUI's Text("Apple").font(.body) performs similarly to NSFont in that it does respect the style, but it does not honour dynamic sizing. NSFontDescriptor has a bunch of interesting methods, but none that seem to apply to Accessibility Text Size. Given an AppKit label: let label = NSTextField(labelWithString: "AppKit") label.font = NSFont.preferredFont(forTextStyle: .body) Or a SwiftUI label: Text("SwiftUI").font(.body) How do I make either of them responsive to the user's Text Size setting under Accessibility? Note this is on macOS 26 / Xcode 26. I realize there have been some previous forum posts related to this issue but hoping that things might have improved since then.

[Submitted as FB22226720] For a NavigationStack destination, applying .navigationBarBackButtonHidden(true) hides the back button and also disables the interactive left-edge back gesture when using the standard push navigation transition. However, when the destination uses .navigationTransition(.zoom), the back button is hidden but the left-edge back gesture is still available—it can still be dismissed even though back is intentionally suppressed. This creates inconsistent behavior between navigation transition styles. navigationBarBackButtonHidden(_:) works with a standard push transition, but not with .navigationTransition(.zoom). In the code below, .interactiveDismissDisabled(true) is also applied as another attempt to suppress the back-swipe gesture, but it has no effect. As a result, there’s currently no clean way to prevent back navigation when using the zoom transition. REPRO STEPS Create an iOS project then replace ContentView with code below, build and run. Leave nav type set to List Push. Open an item. Verify there is no back button, then try the left-edge back gesture. Return to the root view. Change nav type to Grid Zoom. Open an item. Verify there is no back button, then try the left-edge back gesture. ACTUAL In List Push mode, the left-edge back gesture is prevented. In Grid Zoom mode, the back button is hidden, but the left-edge back gesture still works and returns to the previous view. EXPECTED Behavior should be consistent across navigation transition styles. If this configuration is meant to suppress interactive backward navigation for a destination, it should also suppress the left-edge back gesture when using .navigationTransition(.zoom). SCREEN RECORDING SAMPLE CODE struct ContentView: View { private enum NavigationMode: String, CaseIterable { case listPush = "List Push" case gridZoom = "Grid Zoom" } @Namespace private var namespace @State private var navigationMode: NavigationMode = .listPush private let colors: [Color] = [.red, .blue] var body: some View { NavigationStack { VStack(spacing: 16) { Picker("Navigation Type", selection: $navigationMode) { ForEach(NavigationMode.allCases, id: \.self) { mode in Text(mode.rawValue).tag(mode) } } .pickerStyle(.segmented) if navigationMode == .gridZoom { HStack { ForEach(colors.indices, id: \.self) { index in NavigationLink(value: index) { VStack { RoundedRectangle(cornerRadius: 14) .fill(colors[index]) .frame(height: 120) Text("Grid Item \(index + 1)") .font(.subheadline.weight(.medium)) } .padding(12) .frame(maxWidth: .infinity) .background(.quaternary.opacity(0.25), in: RoundedRectangle(cornerRadius: 16)) .matchedTransitionSource(id: index, in: namespace) } .buttonStyle(.plain) } } } else { ForEach(colors.indices, id: \.self) { index in NavigationLink(value: index) { HStack { Circle() .fill(colors[index]) .frame(width: 24, height: 24) Text("List Item \(index + 1)") Spacer() Image(systemName: "chevron.right") .foregroundStyle(.secondary) } .padding() .background(.quaternary.opacity(0.25), in: RoundedRectangle(cornerRadius: 12)) } .buttonStyle(.plain) } } Spacer() } .padding(20) .navigationTitle("Prevent Back Swipe") .navigationSubtitle("Compare Grid Zoom vs List Push") .navigationDestination(for: Int.self) { index in if navigationMode == .gridZoom { DetailView(color: colors[index]) .navigationTransition(.zoom(sourceID: index, in: namespace)) } else { DetailView(color: colors[index]) } } } } } private struct DetailView: View { @Environment(\.dismiss) private var dismiss let color: Color var body: some View { ZStack { color.ignoresSafeArea() Text("Try left-edge swipe back") .font(.title.bold()) .multilineTextAlignment(.center) .padding(.horizontal, 24) } .navigationBarBackButtonHidden(true) .interactiveDismissDisabled(true) .toolbar { ToolbarItem(placement: .topBarTrailing) { Button("Close", action: dismiss.callAsFunction) } } } }

I have an icon button in toolbar but only the icon is triggering tap events while outside icon button gives tap feedback but event is not firing. Code: ToolbarItem(placement: .navigationBarTrailing) { Button(action: toggleBookmark) { Image(systemName: isBookmarked ? "bookmark.fill" : "bookmark") .resizable() .aspectRatio(0.8, contentMode: .fit) .frame(width: 20, height: 20) } } Here toggleBookmark function is only called if I click on Image but not if I click outside image but on the circular button that appears on iOS 26. See this screen recording.