For information I stumbled upon a regression with SwiftUI Slider on iOS 26. Its onEditingChanged closure might be called twice when interaction ends, with a final Boolean incorrect value of true provided to the closure. As a result apps cannot reliably rely on this closure to detect when an interaction with the slider starts or ends. I filed a feedback under FB20283439 (iOS 26.0 regression: Slider onEditingChanged closure is unreliable).

It compiles for iOS but seems to be a no-op. Is this coming in a future beta? Or is there a way to hide the default back button when using the presentation + zoom navigationTransition APIs? I have a view that needs to show a confirmation on dismissal. I was previously doing this manually using a custom toolbar button + confirmationDialog modifier. But in iOS 27 I don't seem to be able to hide the navigation back button since I added the zoom navigationTransition API. This allows the user to tap the back button and lose changes. Not a great UX.

I'm seeing two related UI issues when presenting MFMailComposeViewController from SwiftUI using .sheet. The Cancel button disappears During the sheet presentation animation, the Cancel button is visible in the navigation bar. However, once the presentation animation completes, the Cancel button disappears. This is particularly problematic when the mail composer is presented full-screen: since the Cancel button is removed, there is no longer any way for the user to cancel composing the email and dismiss MFMailComposeViewController. The navigation bar changes abruptly when the presentation animation finishes The navigation bar has one appearance while the sheet is being presented, including the Cancel button and the layout/styling of its navigation items. As soon as the presentation animation finishes, the navigation bar abruptly changes to a different appearance. This causes a noticeable flicker/jump at the end of the animation. In other words, the appearance of MFMailComposeViewController during the sheet transition does not match its final appearance after the transition completes. The sample code below reproduces the issue. Steps to reproduce: Run the sample on an iPad Pro 13-inch (M5) running iPadOS 26.5. Present MFMailComposeViewController using the provided SwiftUI .sheet. Observe the navigation bar during the presentation animation. When the animation completes, observe that the navigation bar changes abruptly and the Cancel button disappears. Is this a known issue with MFMailComposeViewController when presented from SwiftUI using .sheet? struct ContentView: View { @State private var isMailComposerPresented = false var body: some View { VStack { Button("Send") { isMailComposerPresented = true } .buttonStyle(.borderedProminent) } .sheet(isPresented: $isMailComposerPresented) { MailComposerView() } } } struct MailComposerView: UIViewControllerRepresentable { @Environment(\.dismiss) private var dismiss func makeUIViewController(context: Context) -> MFMailComposeViewController { let composer = MFMailComposeViewController() composer.mailComposeDelegate = context.coordinator return composer } func updateUIViewController(_ uiViewController: MFMailComposeViewController, context: Context) {} func makeCoordinator() -> Coordinator { Coordinator(dismiss: dismiss) } final class Coordinator: NSObject, MFMailComposeViewControllerDelegate { private let dismiss: DismissAction init(dismiss: DismissAction) { self.dismiss = dismiss } func mailComposeController( _ controller: MFMailComposeViewController, didFinishWith result: MFMailComposeResult, error: Error? ) { dismiss() } }}

Hello everyone, I have a question regarding the Place Card API I'm using .mapFeatureSelectionAccessory(.automatic) to get information about a POI on the Map The trouble I have is that it forces me to use Apple Maps for directions, which isn't ideal for my use case For example, I support commercial navigation, including large units such as trucks, and I have my own routing engine for this Is there a way to handle the directions via my routing engine instead? Is there a modifier I'm missing, or should I suggest this as an enhancement? Thanks, great work MapKit team

I am seeing a weird crash from Xcode 27 Beta 3 when building a variadic type DynamicProperty that also needs SwiftUI.State. This does not crash from Xcode 26. Here is a repro: import SwiftUI struct Repeater<each Input>: DynamicProperty { @State private var storage = Storage() private var input: (repeat each Input) init(_ input: repeat each Input) { self.input = (repeat each input) } } extension Repeater { final class Storage { } } @main struct CrashDemoApp: App { private var repeater = Repeater(1) var body: some Scene { WindowGroup { EmptyView() } } } Here is the crash: Thread 1 Queue : com.apple.main-thread (serial) #0 0x000000019a93aec0 in swift::TargetMetadata<swift::InProcess>::isCanonicalStaticallySpecializedGenericMetadata () #1 0x000000019a946b38 in performOnMetadataCache<swift::MetadataResponse, swift_checkMetadataState::CheckStateCallbacks> () #2 0x000000019a8c85f0 in swift_checkMetadataState () #3 0x00000001004a2c78 in type metadata completion function for Repeater () #4 0x000000019a94cfe4 in swift::GenericCacheEntry::tryInitialize () #5 0x000000019a94c870 in swift::MetadataCacheEntryBase<swift::GenericCacheEntry, void const*>::doInitialization () #6 0x000000019a94f820 in swift::LockingConcurrentMap<swift::GenericCacheEntry, swift::LockingConcurrentMapStorage<swift::GenericCacheEntry, (unsigned short)14>>::getOrInsert<swift::MetadataCacheKey, swift::MetadataRequest&, swift::TargetTypeContextDescriptor<swift::InProcess> const*&, void const* const*&> () #7 0x000000019a93c714 in _swift_getGenericMetadata () #8 0x00000001004a4190 in __swift_instantiateGenericMetadata () #9 0x00000001004a2a5c in type metadata accessor for Repeater () #10 0x00000001004a5094 in type metadata accessor for Repeater<Pack{Int}> () #11 0x00000001004a4fcc in type metadata completion function for CrashDemoApp () #12 0x000000019a9543bc in swift::MetadataCacheEntryBase<(anonymous namespace)::SingletonMetadataCacheEntry, int>::doInitialization () #13 0x000000019a8d2ae0 in swift_getSingletonMetadata () #14 0x00000001004a479c in type metadata accessor for CrashDemoApp () #15 0x00000001004a473c in static CrashDemoApp.$main() () #16 0x00000001004a4a34 in main () #17 0x0000000186e47e00 in start () Here is a repo to demo: https://github.com/vanvoorden/2026-07-17 Please let me know if you have any ideas about that. Thanks!

Feedback ID: FB23086400 On iOS 27 beta 1, .scrollEdgeEffectStyle(.soft, for: .top) on a List underneath a custom .safeAreaBar(edge: .top) no longer renders the progressive fade-blur. The top edge is fully transparent — scrolled rows pass under the bar with no visual treatment at all, as if scrollEdgeEffectDisabled() had been applied. What I've verified so far: .hard renders correctly in the exact same hierarchy; only .soft is affected. The same binary works correctly on iOS 26.x Xcode preview. I'm building with Xcode 26.3 (iOS 26 SDK). Minimal reproduction: import SwiftUI struct EdgeEffectRepro: View { enum Style: String, CaseIterable, Identifiable { case automatic, soft, hard var id: Self { self } var value: ScrollEdgeEffectStyle { switch self { case .automatic: .automatic case .soft: .soft case .hard: .hard } } } @State private var style: Style = .soft @State private var useSystemBarOnly = false var body: some View { NavigationStack { List(0..<60, id: \.self) { i in Text("Row \(i)") .frame(maxWidth: .infinity, alignment: .leading) .listRowBackground( i.isMultiple(of: 2) ? Color.orange.opacity(0.45) : Color.teal.opacity(0.45) ) } .scrollIndicators(.hidden) .scrollEdgeEffectStyle(style.value, for: .top) .safeAreaBar(edge: .top) { if !useSystemBarOnly { VStack(spacing: 8) { HStack { Text("Custom Top Bar") .font(.system(size: 28, weight: .bold)) Spacer() } HStack { Text("Second row (e.g. date range picker)") .font(.caption) .foregroundStyle(.secondary) Spacer() } } .padding(.horizontal) } } .safeAreaInset(edge: .bottom) { VStack(spacing: 8) { Picker("Edge effect style", selection: $style) { ForEach(Style.allCases) { Text($0.rawValue).tag($0) } } .pickerStyle(.segmented) Toggle("System bar only (control group)", isOn: $useSystemBarOnly) .font(.caption) } .padding() .background(.regularMaterial) } .navigationTitle("EdgeEffect Repro") .navigationBarTitleDisplayMode(.inline) } } } Steps: run on iOS 27 beta 1, set the picker to soft, scroll rows under the bar. Expected: fade-blur as on iOS 26. Actual: fully transparent. Switch to hard: renders fine.

Any view that is content for the tabViewBottomAccessory API fails to retain its state as of the last couple of 26.1 betas (and RC). The loss of state happens (at least) when the currently selected tab is switched (filed as FB20901325). Here's code to reproduce the issue: struct ContentView: View { @State private var selectedTab = TabSelection.one enum TabSelection: Hashable { case one, two } var body: some View { TabView(selection: $selectedTab) { Tab("One", systemImage: "1.circle", value: .one) { BugExplanationView() } Tab("Two", systemImage: "2.circle", value: .two) { BugExplanationView() } } .tabViewBottomAccessory { AccessoryView() } } } struct AccessoryView: View { @State private var counter = 0 // This guy's state gets lost (as of iOS 26.1) var body: some View { Stepper("Counter: \(counter)", value: $counter) .padding(.horizontal) } } struct BugExplanationView: View { var body: some View { ScrollView { VStack(alignment: .leading, spacing: 16) { Text("(1) Manipulate the counter state") Text("(2) Then switch tabs") Text("BUG: The counter state gets unexpectedly reset!") } .multilineTextAlignment(.leading) } } }

Hi everyone, We're experiencing a bug on iOS 26 that only occurs when the user has Reduce Transparency enabled in Accessibility settings. App structure: Our app uses a TabView with a standard tab bar. Inside each tab, we use a NavigationStack. The tab bar is visible on root-level screens, and hidden on all pushed destinations using: .toolbar(.hidden, for: .tabBar) The problem: On iOS 26 with Reduce Transparency off (Liquid Glass active) — everything works correctly. The tab bar hides as expected. On iOS 26 with Reduce Transparency on — a white bar appears at the bottom of the screen in every place where the tab bar is hidden. This white bar: Overlaps content at the bottom of the screen. Blocks scroll, tap, and all user interactions in that area. We also tried: .toolbarBackground(.hidden, for: .tabBar) Removing all custom UITabBarAppearance configuration The only workaround we found is setting UIDesignRequiresCompatibility = YES in Info.plist, which reverts the entire app to the pre-iOS 26 design — not a viable long-term solution. What can we do? Thanks in advance.

I’m seeing a layout regression in SwiftUI on iPadOS 26.4 involving NavigationSplitView inside a TabView. When a NavigationSplitView is embedded in a TabView, the sidebar toolbar appears to reserve too much vertical space. There is a large vertical gap between the top edge of the sidebar and the sidebar collapse/toggle icon. It looks as if the sidebar toolbar itself has become much taller than expected. The same NavigationSplitView layout is rendered correctly when it is shown directly without being embedded in a TabView. Environment: iPadOS 26.4 or later SwiftUI iPad TabView NavigationSplitView inside one tab Expected behavior The sidebar toolbar should use its normal height, as it does when the same NavigationSplitView is shown without a surrounding TabView. The sidebar collapse/toggle icon should appear close to the top of the sidebar, without a large empty gap above it. Actual behavior When the NavigationSplitView is hosted inside a TabView, the sidebar toolbar area becomes excessively tall. A large empty space appears above the sidebar collapse/toggle icon. This only happens in the TabView setup. Rendering the same NavigationSplitView directly does not show the issue. Feedback I also filed this as Feedback Assistant report: FB22645938 Has anyone else seen this behavior since iPadOS 26.4? Is this an intentional layout change, or is there a supported way to avoid this additional top inset when using NavigationSplitView inside TabView? Reproduction import SwiftUI struct ContentView: View { enum AppTab { case first case second } @State private var selectedTab: AppTab = .first var body: some View { TabView(selection: $selectedTab) { Tab("First", systemImage: "sidebar.leading", value: .first) { NavigationSplitView { List { Section("Sidebar Content") { ForEach(1...20, id: \.self) { index in Text("Item \(index)") } } } .navigationTitle("Sidebar") .toolbar { ToolbarItem(placement: .topBarLeading) { Button { // action } label: { Image(systemName: "plus") } } } } detail: { Text("Detail") } } Tab("Second", systemImage: "doc", value: .second) { Text("Second tab") } } } }

I need to display verse so that if a line exceeds the right margin, it is continued on the next line but indented. In UIKit this is easy by using NSParagraphStyle and headIndent and firstLineHeadIndent. But none of this is available on SwiftUI on the Apple Watch, which marks a big step back compared to WatchKit. Is there any way to display text indented in this way? I attach two screenshots, one with the indentation and one without. The one with indentation is far more readable!

Did VisionOS get the LazyVGrid Performance Updates that other platforms received? I’m observing that a LazyVGrid that works well on iPhone, iPad, and Mac appears to hitch and jitter as cells exit and renter the lazyVGrid on VisionOS. It really feels like it did not get the same behavior changes as the other platforms. I observe the scrollbar expands as cells leave the top of the grid, and each “exit” of a row seems to cause a hitch. I’ve got rigidly defined cell frames, rigidly defined columns. I don’t think any cells frames are being invalidated during scroll… (there’s no way to check this with instruments, right?) I‘ve made several analysis passes myself and threw the Xcode Agent with Codex at it just to scan for stuff, but it’s starting to just guess at things. Any known issues with VisionOS?

I’ve hit a strange SwiftUI preview crash that happens on macOS previews when using a view inside a List’s ForEach, resulting in the error Fatal Error in TableViewListCore_Mac2.swift. Only crashes macOS preview - iPhone/iPad preview doesn't crash. Doesn't crash when actually running the app. Here’s a minimal reproducible example, causing the preview to crash. XCode: Version 26.0.1 (17A400) MacOS: 26.0.1 (25A362) import SwiftUI struct Item: Identifiable { let id = UUID() let name: String } struct ItemRow: View { let item: Item var body: some View { HStack { Button(action: {}) { Image(systemName: "play") } Text(item.name) Spacer() ProgressView() } } } struct ContentView: View { @State private var items = [ Item(name: "Item A"), Item(name: "Item B"), ] var body: some View { List { ForEach(items) { item in ItemRow(item: item) } } } } #Preview("Content view") { ContentView() } #Preview("Item row") { ItemRow(item: Item(name: "Item A")) } If I wrap the row in a container, like this: ForEach(items) { item in ZStack { ItemRow(item: item) } } the crash seems to disappear. Has anyone else seen this behavior? What might I be doing wrong? Any ideas about what could be causing this?

Collapsing a NavigationSplitView sidebar from the toolbar button terminates the process in a right-to-left window — but only when the detail column's content carries a padding modifier. Remove the padding and it never crashes. Switch the window to left-to-right and it never crashes. AppKit raises an uncaught exception from -[NSWindow _postWindowNeedsUpdateConstraints] (the window is asked to update its constraints more times than it has views) while a SwiftUI NSHostingView re-invalidates its layout without ever settling. Environment: macOS 27.0 beta (26A5388g), MacBook Pro with Apple M5; Xcode 27.0 (27A5228h); Swift 6.4. Complete reproducer This is the whole app — no dependencies, no model, no table, no timer, no toolbar items of my own. @main struct PaddedDetailCrashApp: App { @State private var columns: NavigationSplitViewVisibility = .all var body: some Scene { Window(Text(verbatim: "Padded Detail"), id: "main") { NavigationSplitView(columnVisibility: $columns) { List { Text(verbatim: "Projects") Text(verbatim: "Archived") Text(verbatim: "Trash") } } detail: { Color.gray .padding(40) // <-- remove this and the crash goes with it } .environment(\.layoutDirection, .rightToLeft) } .defaultSize(width: 900, height: 600) } } Steps to reproduce: 1 - Build and run the code above, launched with the arguments that mirror the window itself: -AppleTextDirection YES -NSForceRightToLeftWritingDirection YES 2 - Click the toolbar's sidebar toggle repeatedly and quickly — roughly four clicks a second. 3 - The process terminates, in my measurements after about 8 toggles. The timing is essential. Each click has to land while the previous collapse is still animating. Clicking slowly, or scripting it so each click completes before the next begins, never reproduces it. Driving the toggle from the View menu (which changes the same state without animating) also never reproduces it.

For GNU Taler, we defined a custom URL scheme: "taler://". We want to have a SwiftUI PasteButton in our app which is only active/enabled when the user copied a talerURI, but not for other URIs (such as https:// or mailto://). Currently we use PasteButton(supportedContentTypes: [.url]) { providers in which works, but is also enabled when the copied text is some other URI, not only for "taler://". Can we define a UTType ".taler" for PasteButton to check whether the pasteBoard has indeed a talerURI? How?

I've got a single-window app whose main ContentView is a table of records. It has some menu commands, defined in my App file, that allow record-level operations (add, delete, process, etc). It also uses some framework-provided editing views (i.e. TextFieldView) for individual fields on each record. I'm having a lot of trouble implementing undo/redo. The menu commands don't have access to the Environment to obtain the undoManager there. The undoManager is nil during onAppear of the ContentView, so I can't set it into my view model before running some user-initiated action on the view itself. If I wire up custom Undo/Redo menu items with my own UndoManager, the TextFieldView undo no longer works. I even tried getting at the underlying NSWindowDelegate to provide my own UndoManager in windowWillReturnUndoManager, but that never gets called. What's the correct pattern to use here?

Here is a simple class that implements a timer: import AsyncAlgorithms final class Timer { private var task: Task<Void, Never>? init() { let id = ObjectIdentifier(self) print(id, "init") } deinit { let id = ObjectIdentifier(self) print(id, "deinit") self.task?.cancel() } func start() { if let _ = self.task { return } let id = ObjectIdentifier(self) self.task = Task.immediate { print(id, "start") defer { print(id, "stop") } for await _ in AsyncTimerSequence.repeating(every: .seconds(1.0)) { let now = Date.now print( id, now.formatted( date: .omitted, time: .standard ) ) } } } } And here is a simple SwiftUI app to start a timer: import SwiftUI @main struct StateDemoApp: App { @State private var timer = Timer() init() { self.timer.start() } var body: some Scene { WindowGroup { EmptyView() } } } Launching the app from Xcode 26.6 runs correctly: ObjectIdentifier(0x0000000c0c96c020) init ObjectIdentifier(0x0000000c0c96c020) start ObjectIdentifier(0x0000000c0c96c020) 10:40:19 PM ObjectIdentifier(0x0000000c0c96c020) 10:40:20 PM ObjectIdentifier(0x0000000c0c96c020) 10:40:21 PM ... ... ... Launching the app from Xcode 27 Beta 3 breaks: ObjectIdentifier(0x0000000a22c245a0) init ObjectIdentifier(0x0000000a22c245a0) start ObjectIdentifier(0x0000000a22c245a0) deinit ObjectIdentifier(0x0000000a22a2ca80) init ObjectIdentifier(0x0000000a22c245a0) stop This makes no sense to me. Why did my Task stop? Why was my Timer deallocated? Here is a repro: https://github.com/vanvoorden/2026-07-16 Please let me know if you have any ideas why this happened. Thanks!

Hi, I am trying to find out what this effect called or how is it implemented. We use it behind the text or title, where the scrollable content goes behind it and it first starts to blur gradually and fade out. I tried using material, .background(.bar), gradient masks. None of these reproduce the same behavior. Here's what I'm referring to: Please let me know what is it or how is it implemented. Tutorial would be appreciated. Thanks!

Hi, I have created this UI using custom view and not a real sheet component. But the animations and interaction is not as smooth. Earlier I was using sheet component and it was working very well, but then I had a need to add a search button on top of sheet (not inside, that is very important). And so I created this whole sheet with custom view and not the sheet component. But it resulted in loss of fluid working and animations that sheet have. Including changing between Medium detent and Large detent. Is it possible to achieve this UI with native sheet component? Or using some other native swiftui view which will have good animation that sheet has?

Environment: iOS 26; iPad Mini/Air/Pro Problem: In a TextField, I am using a keyboard with the type .decimalPad. When I initially tap into the TextField, the "popover" keyboard (i.e. the decimalPad) shows up and focusses the TextField. However, when I click outside the TextField (to dismiss the keyboard), the TextField is still focussed (the keyboard was dismissed though). When reentering in the TextField, another keyboard (from the bottom of the screen) appears (most likely .numeric). Does anybody know how to solve this? What I already tried: I tried listening to the dismissal of the keyboard to manually set the FocusState to nil. However, the dismissal of the "popover/decimal" keyboard is not recognized as such a dismissal. I also tried to build a custom component out of that, but then I lose the TextField behavior, conflicting with HIG.

I have a few crashes on my project that happen in the wild, and the stack trace looks like this, from a thread that is not the main thread: Crashed: com.apple.SwiftUI.AsyncRenderer 0 libdispatch.dylib 0x36f1c _dispatch_assert_queue_fail + 120 1 libdispatch.dylib 0x37988 dispatch_assert_queue$V2.cold.2 + 114 2 libdispatch.dylib 0x5094 dispatch_assert_queue + 108 3 libdispatch.dylib 0x5094 dispatch_assert_queue$V2 + 108 4 libswift_Concurrency.dylib 0xedfc _swift_task_checkIsolatedSwift + 48 5 libswift_Concurrency.dylib 0x6fc4 swift_task_isCurrentExecutorWithFlagsImpl(swift::SerialExecutorRef, swift::swift_task_is_current_executor_flag) + 356 6 Xogot 0x2585a78 closure #1 in Toolbar3D.dockedBody.getter + 195 (Toolbar3D.swift:195) 7 SwiftUI 0xeae60 ScrollView.init(_:showsIndicators:content:) + 136 8 Xogot 0x2585798 Toolbar3D.body.getter + 207 (Toolbar3D.swift:207) 9 SwiftUICore 0x31614 closure #1 in ViewBodyAccessor.updateBody(of:changed:) + 1068 10 SwiftUICore 0x311b0 ViewBodyAccessor.updateBody(of:changed:) + 348 11 SwiftUICore 0x30f48 protocol witness for BodyAccessor.updateBody(of:changed:) in conformance ViewBodyAccessor<A> + 16 12 SwiftUICore 0x24aa4 closure #1 in DynamicBody.updateValue() + 1136 13 SwiftUICore 0x24224 DynamicBody.updateValue() + 1220 14 SwiftUICore 0x4fffd0 partial apply for implicit closure #1 in closure #1 in closure #1 in Attribute.init<A>(_:) + 32 I have watched the 2025 WWDC Video "Explore Concurrency in SwiftUI" and it does point out that in certain places SwiftUI will use a background thread to run its operations and the documented idiom is that the protocols are non isolated. The issue is that ScrollView is @MainActor, and the content: argument has no special annotations, so it it flagged as @MainActor, and the new Swift dynamic test asserts. My class it not that interesting, it looks like this: struct Toolbar3D: View { var body: some View { #if macOS dockedBody #else someOtherBody #endif } var dockedBody: some View { ScrollView { ... } } } For a second I thought maybe the second layer was the problem, but the stack trace still shows my @MainActor body being invoked by SwiftUI on the background thread. This is happening in iOS 26.5.0, 26.5.1, iOS 26.5.2, iOS 26.2.0 I am not quite sure how to fix this, short of disabling Swift's dynamic actor isolation (which will probably just crash in a more obscure place at a later point in time).