I’m experiencing a UI flickering issue in a SwiftUI application related to navigation and the .searchable modifier. I have the following navigation flow: Case 1: Event Dashboard ↓ Attendee List ↓ Back to Event Dashboard The Event Dashboard contains an event image at the top. The Attendee List has a navigation bar with a .searchable search field. When I navigate back from the Attendee List to the Event Dashboard, the event image briefly becomes smaller and then returns to its original size after approximately one second. Case 2: Event Dashboard ↓ Attendee List ↓ Attendee Detail The Attendee List contains .searchable, while the Attendee Detail screen does not. When navigating from the Attendee List to the Attendee Detail screen, the attendee profile image similarly becomes slightly smaller and then enlarges back to its original size. The behavior appears to be related to the navigation bar/search bar layout changing between screens. For example, the Attendee List currently uses: .searchable( text: $model.searchQuery, placement: .navigationBarDrawer, prompt: "Search" ) If I completely remove .searchable from the Attendee List, the flickering does not occur. I would like to understand whether this is expected SwiftUI behavior or a known issue with .searchable and navigation transitions. I am considering testing the Attendee List with ScrollView + LazyVStack instead of List to determine whether List is contributing to the issue.

struct ContentView: View { @State var searchText: String = "" var body: some View { TabView { Tab { NavigationStack { List { Text("Hello!") Text("Hello!") Text("Hello!") Text("Hello!") Text("Hello!") Text("Hello!") } .navigationTitle("Have a title") .searchable(text: $searchText, placement: .toolbar) .searchToolbarBehavior(.minimize) .toolbar { DefaultToolbarItem(kind: .search, placement: .topBarTrailing) } } } } } } In iOS 26, this worked no problem. In iOS 27, this leaves the search bar either unable to collapse (when pressing the close button) or in a broken state where it cannot be opened again.

On macOS 27.0 (26A428) with Xcode 27.0, Apple's unmodified sample Building a document-based app with SwiftUI stops responding permanently when another process replaces an open document's file through NSFileCoordinator. AppKit reverts the document on the main thread, which then blocks in a semaphore wait inside SwiftUI: -[NSDocument relinquishPresentedItemToWriter:]_block_invoke_8 (in AppKit) -[NSDocument _revertToVersion:preservingFirst:error:] (in AppKit) -[NSDocument revertToContentsOfURL:ofType:error:] (in AppKit) URLPlatformDocument.read(from:ofType:) (in SwiftUI) _dispatch_semaphore_wait_slow (in libdispatch.dylib) No other thread is reading the document. In another app using Document, its DocumentReader was never called, and a document with unsaved changes hung the same way in URLPlatformDocument.write(to:ofType:for:originalContentsURL:). Reproduction (the sample plus a short script): https://github.com/DePasqualeOrg/swiftui-document-revert-hang Feedback report: FB24792850

When I drag and drop a file with flag "shouldAttemptToOpenInPlace: true", I was able to access the original file name in macOS 15. After upgrading to macOS 26, I can't access the original file name anymore. Instead, I got some useless file name such as ".com.apple.Foundation.NSItemProvider.gKZ91u.tmp". The app no longer works with these tmp filenames because it needs the orignal file name to do the file transfer. (Btw, this is a WinSCP like app on Mac platform) Could you please check and fix this issue? Thank you. FileRepresentation(contentType: .item, shouldAttemptToOpenInPlace: true)

I’d like Swift Charts to support pinch-to-zoom, with the data beneath the pinch staying in place and smooth integration with scrolling and selection. This is useful whenever someone wants to explore a chart: zoom into a heart-rate spike, inspect a price change, or investigate a burst of energy consumption without losing their place. Apple Health uses preset time ranges to change the level of detail. Those are useful shortcuts, but they don’t always match the interval someone wants to explore. Pinching would complement them by letting users zoom directly into whatever catches their attention—a familiar interaction from maps and photos that feels natural for charts too. I’ve implemented a workaround using MagnifyGesture, chartXVisibleDomain, and chartScrollPosition. It mostly works, but keeping the pinch anchored requires continuously adjusting the scroll position, which causes chart jumps and visual glitches—even with animations disabled. Native support should handle that coordination, let developers configure zoom limits, and work alongside existing chart gestures. Developers could then offer smooth, interactive charts without each having to solve the same gesture and anchoring problems. I’ve attached a sample project demonstrating the workaround and its limitations. Would native pinch-to-zoom help your app too? I’d be interested in your use cases and any limitations you’ve encountered. I’ve filed this as FB24785962; if you submit related feedback, please reference it and describe your own use case. Sample Project

When I click on a table row, the focus cannot be changed from a TextField to the table. This is a bug in macOS 27 because the focus can be changed from a TextField to the table in macOS 26. Temp workaround: Click a different window, such as Finder or Safari Click the table in my app. The focus can be changed from a different app to the table in my app. Note: Table with focus: the table row is highlighted in blue. Table without focus: the table row is highlighted in grey.

While testing a native SwiftUI app on macOS 27.0 beta (26A5421a), built with Xcode 27.0 beta (27A5209h), we observed toolbar button groups briefly dimming when a custom sidebar animated open or closed. Filed as FB24782376. Our layout uses an HStack with a .bar sidebar background, animated sidebar width/offset, scrollable detail content, and a persistent root toolbar. The toolbar includes sidebar/add and play/edit/delete groups plus a separate terminal button. The change that removed the measured transition in this app was: .toolbar { // Existing toolbar items } .toolbarBackgroundVisibility(.hidden, for: .windowToolbar) This hides the automatic full-width toolbar backdrop. In our configuration, the standard native glass backgrounds around toolbar buttons remain. It changes the toolbar background design, so test it against your own content, appearance settings, and supported macOS versions. What we measured Read-only NSView/CALayer instrumentation showed a toolbar-wide hosting layer receiving a CATransition of type fade, lasting 0.25 seconds. Toolbar items stayed enabled, button instances stayed stable, and individual view/presentation-layer opacity remained 1. A keyboard-triggered comparison also kept the app/window active, key, and main throughout. Forcing the background visible, restricting the sidebar material’s safe-area extent, and isolating sidebar state below the toolbar-owning view did not remove the transition. Hiding the automatic toolbar background did. With standard SwiftUI buttons and the original layout restored, the hidden-background version recorded no toolbar animations on both opening and closing (91 samples per transition). These are app-side samples, not pixel-by-pixel proof or an independent minimal reproduction. This is a tested workaround for our configuration and a suspected system rendering interaction, not an Apple-confirmed diagnosis or a universal fix for toolbar flicker. We have not established behavior on other macOS versions. Related reports, not confirmed duplicates Toolbar jitter when toggling a sidebar (2022): intermittent movement of a share button during sidebar toggles, with another developer reporting similar behavior. Toolbar flashes above a translucent sidebar (2021): brief white flashes during periodic updates in full screen. Both predate this macOS 27 observation and have different triggers or appearances. They do not establish the same root cause. API reference: Apple’s toolbarBackgroundVisibility documentation. If you see a similar brief dimming on this configuration, comparing automatic versus hidden toolbar background visibility may help narrow it down. Please include your OS build, layout, and whether the comparison changes the symptom when filing feedback.

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.

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

FB24767077 After programmatically setting the ID to B, manually paging back to A causes the binding to update to A and then unexpectedly back to B. The view hangs between pages while SwiftUI attempts to animate toward the stale B target. The issue occurs only when an app built with Xcode 27 runs on iOS 27. It does not occur in: Xcode 27 build running on iOS 26 Xcode 26 build running on iOS 27 Xcode 26 build running on iOS 26 Steps to reproduce: Launch the minimal reproduction project Tap “Set B” to assign B directly to the scrollPosition(id:) binding Swipe right to return to page A Expected result: After paging from B back to A, the scroll position remains A once the pager settles. Actual result: The binding emits A followed by B, even though page A is the visible, settled page. The resulting stale B value causes the animation to hang between pages. Code: struct ContentView: View { @State private var selectedPage: Page? = .a var body: some View { VStack { HStack { Button("Set B") { selectedPage = .b } Text("Selected: \(selectedPage?.rawValue ?? "nil")") } PagerView(selectedPage: $selectedPage) } .onChange(of: selectedPage, initial: false) { _, newValue in print("selectedPage: \(newValue?.rawValue ?? "nil")") } } } struct PagerView: View { @Binding var selectedPage: Page? var body: some View { ScrollView(.horizontal) { LazyHStack(spacing: .zero) { ForEach(Page.allCases) { page in Text(page.rawValue) .font(.largeTitle) .frame(maxWidth: .infinity, maxHeight: .infinity) .background(page.color) .containerRelativeFrame(.horizontal) } } .scrollTargetLayout() } .frame(height: 300) .scrollIndicators(.hidden) .scrollPosition(id: $selectedPage) .scrollTargetBehavior(.paging) .animation(.default, value: selectedPage) } } enum Page: String, CaseIterable, Identifiable { case a = "A" case b = "B" case c = "C" var id: Self { self } var color: Color { switch self { case .a: .red.opacity(0.2) case .b: .green.opacity(0.2) case .c: .blue.opacity(0.2) } } }

Following up on a related discussion here: https://developer.apple.com/forums/thread/797298 "Using the new Liquid Glass effect in iOS 26 for widget backgrounds" I’ve also been looking at the widgetRenderingMode documentation and the “Optimizing your widget for accented rendering mode and Liquid Glass” documentation you mentioned. I understand that the widget should adapt its content based on the rendering mode, and that Liquid Glass is provided by the system when the widget is rendered in the appropriate context. What I’m still trying to understand is the behavior of the widget’s background/container itself. I tested a minimal widget on an iPhone running iOS 27, including: .containerBackground(for: .widget) { Color.clear } I also tried EmptyView(), .clear, containerBackgroundRemovable(true), and several material/glass combinations. What I found is: In Clear/Tinted Home Screen appearance, the widget becomes .accented and the system provides the expected transparent/Liquid Glass presentation. In the normal Home Screen appearance, the widget remains .fullColor (confirmed by logging @Environment(.widgetRenderingMode) directly in the widget view), but the actual Home Screen wallpaper does not show through the widget container. So I’m wondering whether this is simply expected behavior for .fullColor. Is it possible for a Home Screen widget to remain in .fullColor while its system widget container is genuinely transparent, allowing the actual Home Screen wallpaper to remain visible behind the widget? Or is transparency of the system widget container intentionally limited to the system’s Clear/Tinted (.accented) presentation? I’m asking because I’ve seen some third-party widgets that appear to provide a transparent or Liquid Glass-style widget even when the Home Screen is using its normal appearance, so I’m trying to understand whether there is a public WidgetKit/SwiftUI API or configuration that I’m missing. Thanks for any clarification.

Hi, for anyone who is working with LiveActivities and is running a beta of iOS 27, has apple made the ability for LiveActivities to be vertically larger and display more content as they appear in some of the demo images, or are these LiveActivities like the ones in the pictures above just system specific that is only available to apple.

I've run into an issue with my app that I've been able to narrow down to a small reproducer. Any time there is a task associated with the DetailView and you "pop to top", onAppear is called again and the task is re-run. Why is that? Is this a SwiftUI bug? It doesn't happen on iOS 17, only 18. import SwiftUI @Observable class Store { var shown: Bool = true } @main struct MyApp: App { @State private var store = Store() var body: some Scene { WindowGroup { if store.shown { ContentView() } else { EmptyView() } } .environment(store) } } struct ContentView: View { var body: some View { NavigationView { NavigationLink(destination: DetailView()) { Text("Go to Detail View") } } } } struct DetailView: View { @Environment(Store.self) private var store init() { print("DetailView initialized") } var body: some View { Button("Pop to top") { store.shown = false } .task { print("DetailView task executed") } .onAppear { print("DetailView appeared") } .onDisappear { print("DetailView disappeared") } } }

With the new Liquid Glass tab bar, I’m able to customize the color of the textfor the selected tab. However, the unselected tab bar items automatically use the system’s vibrancy effect, and their text color appears to be determined by the Liquid Glass appearance. I would like to manually specify the color of the unselected tab bar item text/icons as well, instead of having the system apply vibrancy. For example, I would like to have: Selected tab → custom color (e.g. blue) Unselected tabs → another custom color (e.g. gray) No automatic vibrancy/color transformation applied to the unselected items Is there a supported API or configuration in UIKit to control the foreground/text/icon color of unselected UITabBarItems when using the Liquid Glass tab bar? I’ve tried using UITabBarAppearance / UITabBarItemAppearance, but the unselected item's color still appears to be affected by the Liquid Glass/vibrancy behavior. Is there a recommended way to achieve this while retaining the Liquid Glass tab bar?

How do you add custom macOS target properties in a SwiftUI Multi-platform target? I only see custom iOS target properties. I want to add keys such as BAAppGroupID, but only for macOS.

I’m seeing inconsistent right-to-left behavior when using the new SwiftUI swipeActionsContainer() API with a ScrollView. The swipe-action buttons are positioned correctly according to the layout direction, but the gesture direction itself is not mirrored. Minimal reproducible example: import SwiftUI struct ContentView: View { var body: some View { ScrollView { LazyVStack { Text("Hello, World!") .padding() .frame(maxWidth: .infinity) .background(.blue.quinary) .swipeActions { Button(role: .destructive) { // Delete action } label: { Label("Delete", systemImage: "trash") } } } .padding() } .swipeActionsContainer() } } Steps to reproduce: Run the example using a left-to-right language such as English. Swipe the row from right to left. The trailing swipe actions appear correctly. Change the app language to Arabic. Swipe the row from left to right, which should reveal the trailing actions in an RTL layout. Nothing happens. Swipe from right to left instead. The actions appear, but from the correct visually mirrored edge. Expected behavior: Because the default swipe-action edge is .trailing, both the action placement and the gesture direction should follow the current layout direction: English/LTR: swipe from right to left. Arabic/RTL: swipe from left to right. Actual behavior: The action buttons visually respect the RTL layout, but the gesture recognizer still requires the LTR swipe direction. Environment: Xcode: 27.0 RC iOS: 27.0 RC Device: iPhone 17 Swift language version: Swift 6

I've encountered crashes when trying to reorder items using the new reordering API. Fatal error: Unexpected identifier type. Expected UUID, got UUID To reproduce, simply run one of the 2 first tests and comment out the others: import SwiftUI @main struct MyApp: App { var body: some Scene { WindowGroup { ContentView() } } } struct Task: Identifiable { let id = UUID() var title: String } struct ContentView: View { @State private var tasks = [ Task(title: "Design Invoice"), Task(title: "Send Proposal"), Task(title: "Review Feedback"), Task(title: "Publish Update") ] @State private var showingPopover: Bool = false var body: some View { ScrollView { LazyVGrid( columns: [ GridItem(.adaptive(minimum: 100)) ] ) { ForEach(tasks) { task in // Test 1: This will crash when reordering if #available(iOS 26.0, macOS 26, *) { Text(task.title) .frame(maxWidth: .infinity) .padding() .background(.blue.opacity(0.1)) .clipShape(.rect(cornerRadius: 12)) } else { Text(task.title) .frame(maxWidth: .infinity) .padding() .background(.blue.opacity(0.1)) .clipShape(.rect(cornerRadius: 12)) } // Test 2: This will also crash Text(task.title) .frame(maxWidth: .infinity) .padding() .background(.blue.opacity(0.1)) .clipShape(.rect(cornerRadius: 12)) .popover(isPresented: $showingPopover) { Text("Popover") } // Test 3: This is ok Text(task.title) .frame(maxWidth: .infinity) .padding() .background(.blue.opacity(0.1)) .clipShape(.rect(cornerRadius: 12)) } .reorderable() } .reorderContainer(for: Task.self) { difference in tasks.apply(difference: difference) } } } } extension Array { mutating func apply<CollectionID: Hashable & Sendable>( difference: ReorderDifference<Element.ID, CollectionID> ) where Element: Identifiable, Element.ID: Sendable { // Find the source element that moved. guard let sourceIndex = firstIndex( where: { $0.id == difference.sources[0] } ) else { return } let movedElement = remove(at: sourceIndex) // Find the destination of that element. var destination: Int switch difference.destination.position { case let .before(value): guard let index = firstIndex( where: { $0.id == value } ) else { return } destination = index case .end: destination = endIndex } insert(movedElement, at: destination) } } I hope this is not just a limitation for the 27 release and is a bug that will be addressed in the next betas. Perhaps I'm just doing something wrong? In such case, thanks for pointing out what. FB23640379

I have CarPlay Video enabled for my account and App ID. I tested both my main app and a completely new minimal iOS app with a new Bundle ID. The minimal app only contains: UIApplicationDelegate CPTemplateApplicationScene configuration CPTemplateApplicationSceneDelegate A single CPListTemplate root Results: With com.apple.developer.carplay-audio only, CarPlay launches normally. When com.apple.developer.carplay-video is added, CarPlay opens a blank screen. No CarPlay callbacks are called: application(:configurationForConnecting:options:) CPTemplateApplicationSceneDelegate.templateApplicationScene(:didConnect:) CPApplicationDelegate.didConnectCarInterfaceController The signed app and embedded provisioning profile both contain com.apple.developer.carplay-video. Does CarPlay Video require an additional runtime allowlist, specific head unit support, a different scene configuration, or another entitlement beyond com.apple.developer.carplay-video?

A paged ScrollView loses its page when the window is resized on iPadOS 27: ScrollView(.horizontal) { HStack(spacing: 0) { ForEach(pages) { page in PageView(page).containerRelativeFrame(.horizontal) } } .scrollTargetLayout() } .scrollTargetBehavior(.paging) .scrollPosition(id: $selection) Expected: the selected page stays edge-aligned after the resize (as TabView(.page) does). Actual: The content offset is preserved in points, not pages — the view rests between pages. scrollPosition(id:) writes nil during the resize, so the selection can't be recovered from the binding. Both .paging and .viewAligned are affected. Repro project (broken ScrollView, TabView control, and workaround side by side, with live instrumentation): https://github.com/katebrr/PagedScrollResizeLab Why not TabView(.page): it has no API for scroll position/progress observation (our analytics depend on it), inter-page spacing, partial-width peeking pages, or pausing the swipe mid-gesture. Workaround (Workaround/View+ScrollPositionResize.swift in the repo): restore the last non-nil selection via scrollTo one Task.yield() after the resize. Works, but lands a frame late and relies on undocumented behavior. Questions: Is this behavior intended, or a bug? Is there a supported way to keep a paged ScrollView anchored to its page across resizes? Is there a more robust formulation than scrollTo after Task.yield()? Filed as FB24688033.

Right now, the traffic light buttons overlapped on my iPad app top corner on windows mode (full screen is fine). How do I properly design my app to avoid the traffic light buttons? Detect that it is iPadOS 26?