I'm trying to understand why would a single button appear twice in the toolbar, like so: Do you see the eclipsed button peeking from underneath the top button? It's the same button, somehow doubled or cloned, or replicated. To reproduce it, I only needed to create a fresh iOS project in Xcode and apply this code change: diff --git a/BugRepro20260409/ContentView.swift b/BugRepro20260409/ContentView.swift index 426b298..d22433f 100644 --- a/BugRepro20260409/ContentView.swift +++ b/BugRepro20260409/ContentView.swift @@ -28,7 +28,7 @@ struct ContentView: View { ToolbarItem(placement: .navigationBarTrailing) { EditButton() } - ToolbarItem { + ToolbarItem(placement: .bottomBar) { Button(action: addItem) { Label("Add Item", systemImage: "plus") } This is all I needed to do for the double-vision button. Why would this button appear twice when moved to .bottomBar? By the way, when moved to the side and displayed on a smaller device like iPhone SE, the duplication is quite jarring: Interestingly, both buttons are active, and both trigger the same code path. Any ideas what's going on? ContentView.swift

I encountered a SwiftUI navigation issue on iOS 26.3.1 with this structure: TabView NavigationStack(path:) custom root ScrollView The navigation stack hides the system Tab Bar while a destination is presented. When the root ScrollView is near its bottom, an interactive pop briefly exposes the root list at a lower vertical position, then snaps it back when the transition completes. Measured geometry on an iPhone 17 Pro Max simulator: Before navigation: offset 754.67, container height 733, bottom inset 107 During pop: offset 705.67, container height 782, bottom inset 58 After pop: offset 754.67, container height 733, bottom inset 107 The effective Tab Bar occupancy on this device was 49 points. During the transition, the container became 49 points taller and its bottom inset became 49 points smaller, causing SwiftUI to clamp the content offset near the bottom. The following approaches did not prevent the visible intermediate state: Adding more bottom spacing Disabling scroll content offset adjustment in the navigation path transaction Saving and restoring ScrollPosition after the pop .defaultScrollAnchor(.top, for: .sizeChanges) Moving Tab Bar visibility ownership to each destination view; this also produced a noticeable delay before the Tab Bar returned The workaround that has been reliable is: Keep Tab Bar visibility synchronized with whether the tab-owned NavigationStack path is empty. This preserves the normal system animation timing. Measure the Tab Bar's effective occupancy from public geometry: root ScrollView bottom inset window bottom safe-area inset the app's normal trailing scroll margin While navigation depth is greater than zero, preserve that measured amount with a clear safeAreaInset on the root ScrollView. When onScrollGeometryChange reports that the root page's system bottom inset has returned, release the reserved inset in a transaction with animations disabled. With this approach, the offset remained 754.67 throughout push and pop. The Tab Bar also returned at its original system-controlled time. The implementation uses public APIs only. It does not hard-code 49 points, traverse the UITabBar view hierarchy, poll system UI state, or restore an offset after the transition. Has anyone found an Apple-recommended alternative, or observed the same behavior on other iOS 26 versions?

On iOS 26.5, combining the .inlineLarge navigation bar mode with a custom ToolbarItem(placement: .largeTitle) breaks the collapsed bar: after any scroll collapse, the compact bar renders with no title, no bar material or scroll edge treatment, and content draws through the status bar. It recovers on re-expansion. Details from my minimal repro (filed as FB24528594, single-file project attached to the report): The .title item is not required to trigger it. .inlineLarge plus only a custom ToolbarItem(placement: .largeTitle) reproduces it on every collapse. A .largeSubtitle item alone does not trigger it. Adding one alongside the .largeTitle item breaks the same way, with the subtitle content vanishing too. Reproduces 100% on the iOS 26.5 simulator (Xcode 26.6), light and dark. Workarounds tried without success: setting navigationItem.titleView does not hold, because SwiftUI re-renders the compact title after toolbar churn. Two questions for the engineering team: is this a known bug, and is there any supported way to keep a custom large-title toolbar arrangement while preserving the compact bar's title and material through collapse? I have a design that places an avatar in the large-title row and this is currently the blocker. Happy to provide anything beyond what's in FB24528594.

How do I disable the "Ask Siri" button in the SwiftUl context menu in macOS?

When you use .navigationTransition(.zoom(sourceID: "placeholder", in: placehoder)) for navigation animation, going back using the swipe gesture is still very buggy on IOS26. I know it has been mentioned in other places like here: https://developer.apple.com/forums/thread/796805?answerId=856846022#856846022 but nothing seems to have been done to fix this issue. Here is a video showing the bug comparing when the back button is used vs swipe to go back: https://imgur.com/a/JgEusRH I wish there was a way to at least disable the swipe back gesture until this bug is fixed.

When I try to apply .presentationPlacement(), I get this error: dyld[7938]: Symbol not found: _$s7SwiftUI21PresentationPlacementV7leadingACvgZ Referenced from: <CB0145C5-9776-3B71-9209-70D2B3EDB772> /private/var/containers/Bundle/Application/101B4DDE-56D9-4742-AABB-AE11E2415145/ShopperTransit2026.app/ShopperTransit2026.debug.dylib Expected in: <1FA062F0-69E6-3C8A-962D-F3DEF020CB94> /System/Library/Frameworks/SwiftUI.framework/SwiftUI Even having the method show up when using an extension View {}, it still causes this problem I'm not sure exactly why this is caused. Guessing from the missing symbol error, that Xcode does not have this symbol in the code. However, this line of code does work in #Preview {}. So I am completely unsure as to why it doesn't work on regular hardware. Does anyone have a clue why?

On iOS 26, a nested Menu (a drill-in submenu) visibly jumps and repositions for about a second the first time a submenu is opened, when the menu lives inside a .sheet that is at any partial-height detent — .medium, or a custom .height(...)/.fraction(...) detent. Reopening the same submenu is smooth. The problem does not occur on iPad, does not occur when the sheet is at full height (.large), and does not occur for a flat (single-level) menu. It reproduces with a completely stock Menu, and also with a UIKit UIButton + UIMenu, so it does not appear to be tied to any specific app code. The trigger is purely that the sheet's presentation host is shorter than the screen — the specific detent type does not matter. Minimal reproducible example (stock SwiftUI only) import SwiftUI struct MinimalRepro: View { @State private var showSheet = false var body: some View { Button("Open sheet") { showSheet = true } .sheet(isPresented: $showSheet) { VStack { Menu("Status") { Menu("Category A") { Button("Option 1") {} Button("Option 2") {} Button("Option 3") {} } Menu("Category B") { Button("Option 4") {} Button("Option 5") {} Button("Option 6") {} } Menu("Category C") { Button("Option 7") {} Button("Option 8") {} Button("Option 9") {} } } .padding() Spacer() } .presentationDetents([.medium, .large]) } } } Steps to reproduce Run on an iPhone (or iPhone simulator) on iOS 26. Tap Open sheet. The sheet appears at the .medium (half-height) detent. Tap Status to open the outer menu, then tap Category A to open the submenu. Observe the submenu on this first open. Expected The submenu appears anchored to its parent item and animates in place, exactly as on iPad and exactly as on the second open. Actual On the first open, the submenu appears in the wrong position / at the wrong size and then jumps (snaps) into place over roughly one second. Subsequent opens of the same submenu are smooth. Has anyone found a way to keep drill-in submenus in a partial-height sheet without the first-open jump? So far the only workarounds I've found change the UX (flatten the menu to a single level, present at full height).

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.

We're getting user reports that the App Store rating prompt appears repeatedly — one user says they're prompted roughly every day, and that they still get the prompt after they've already left a rating. This contradicts the documented behavior, so I want to check whether others are seeing the same thing or whether there's a known regression. What the docs say should happen The system limits display to 3 occurrences per app within a 365-day period. For a user who has already rated/reviewed, StoreKit should only display again if the app version is new and more than 365 days have passed since their previous review. Has anyone else experience it?

I have isolated a reproducible animation issue involving SwiftUI List, system .swipeActions, variable row heights, and ProMotion. Environment: iPhone 17 Pro Max iOS 26.6 Xcode 26.5 Low Power Mode off “Limit Frame Rate” off iOS screen recording off When a List contains alternating single-line and two-line rows whose heights are determined naturally, slowly dragging a row left to reveal .swipeActions causes a visible pause. The row briefly stops following the finger, then jumps left. The trailing action buttons appear suddenly instead of being progressively revealed. Fast swipes are usually smooth. I created a minimal project with two modes: Variable: alternating single-line and two-line rows use their natural heights. Uniform: the same contents are constrained to a uniform height. Both modes use the same List, SF Symbol, tap gesture, and .swipeActions. The issue reproduces consistently in Variable mode, while Uniform mode remains smooth. A simplified version of the Row is: ForEach(0..<20, id: \.self) { index in HStack { Image(systemName: "folder") .frame(width: 28) VStack(alignment: .leading) { Text("Category \(index + 1)") if index.isMultiple(of: 2) { Text("Secondary information") .font(.caption) .foregroundStyle(.secondary) } } Spacer() } .swipeActions(edge: .trailing, allowsFullSwipe: false) { Button("Delete", systemImage: "trash") {} .tint(.red) Button("Hide", systemImage: "eye.slash") {} .tint(.orange) } } The unusual part is that the issue immediately disappears when any of the following is enabled: Low Power Mode Accessibility → Motion → Limit Frame Rate iOS screen recording It returns as soon as those conditions are disabled. I can also observe highly similar behavior in: Settings → General → iPhone Storage Rows with a “Last Used” subtitle appear taller than rows without it. Slowly swiping those rows can produce the same pause followed by the action UI suddenly appearing. The same frame-rate-related workarounds make that system list smooth as well. I have filed this through Feedback Assistant: FB24515209. Has anyone reproduced this on another ProMotion device, another iOS 26 version, or an iOS 27 beta? I am especially interested in whether there is a framework-supported workaround other than keeping all swipeable rows at a uniform height.

Hi everyone, I am currently implementing the new Search API in a UIKit app using @AppIntent(schema: .system.search), ShowInAppSearchResultsIntent, and UISceneAppIntent. While testing on the iOS beta, I’ve hit a significant lifecycle disparity between how UIKit and SwiftUI apps process system intents during a process-cold launch. According to the documentation for UIScene.ConnectionOptions.appIntent, this property should contain the intent that triggered the scene creation. However, in a UIKit app with a single-window scene lifecycle, this isn't happening consistently. Here is the behaviour breakdown I am seeing: Cold Launch (Siri/Search → App completely closed) SwiftUI App: Works as documented. The intent is present in connection options. scene(_:willPerformAppIntent:) is not called. UIKit App (with AppIntentSceneDelegate): The connectionOptions.appIntent property is completely nil inside scene(:willConnectTo:options:). Instead, the intent is delivered late via scene(:willPerformAppIntent:) right after scene connection completes. Warm Launch (Siri/Search → App already suspended in memory) Both SwiftUI and UIKit: Behave identically. The intent is delivered directly to scene(_:willPerformAppIntent:). The Problem Because of this gap, there is no unified way to handle a process-cold launch under UIKit. There is no LaunchOptionsKey available to identify that an App Intent initiated the launch, and the missing connection option forces us to bifurcate our routing logic. I have already filed a bug report via Feedback Assistant: FB24513291 and attached a minimal reproducible sample project. Has anyone else run into this specific AppIntentSceneDelegate race condition on the iOS beta? If so, what architecture or unified pattern are you using to normalize the lifecycle routing between cold and warm launches in UIKit? Any insights or clean workaround ideas would be highly appreciated!

I've discovered an issue with using iOS 16's Transferable drag-and-drop APIs for SwiftUI. The dropDestination modifier does not work when applied to a subview of a List. This code below will not work, unless you replace the List with a VStack or any other container (which, of course, removes all list-specific rendering). The draggable modifier will still work and the item will drag, but the dropDestination view won't react to it and neither closure will be called. struct MyView: View { var body: some View { List { Section { Text("drag this title") .font(.largeTitle) .draggable("a title") } Section { Color.pink .frame(width: 400, height: 400) .dropDestination(for: String.self) { receivedTitles, location in true } isTargeted: { print($0) } } } } } Has anyone encountered this bug and perhaps found a workaround?

I'm developing a tvOS application using SwiftUI, and I have a custom video player presented using fullScreenCover. .fullScreenCover(isPresented: $isPlayerPresented) { PlayerView() } I would like to implement the same kind of behavior commonly seen in video players: The player is presented full screen. When the playback controls are visible, pressing the Siri Remote Back button should hide the controls. The player should remain presented. Only when the controls are already hidden should pressing Back dismiss the player. However, I am unable to intercept the Back button before the fullScreenCover is dismissed. I have tried several approaches, including: .onExitCommand { // Handle Back } and handling UIPress / .menu events through UIKit. The problem is that when the Siri Remote Back button is pressed while the view is presented using fullScreenCover, the fullScreenCover is dismissed directly. My custom view does not appear to be able to prevent the dismissal. I also tried placing a custom UIView / UITapGestureRecognizer inside the fullScreenCover to intercept the remote button event, but the presentation is still dismissed. According to the SwiftUI documentation, onExitCommand responds to the tvOS exit command generated by the Menu button, but it does not appear to provide a way to prevent the system from dismissing a fullScreenCover in response to the Siri Remote Back button. I also noticed that interactiveDismissDisabled(_:) does not appear to provide a solution for this particular tvOS behavior. My questions Is the Siri Remote Back button expected to automatically dismiss a SwiftUI fullScreenCover on tvOS? Is there a supported API to intercept the Back button before the fullScreenCover is dismissed? Is there a way to tell SwiftUI that a fullScreenCover should not be dismissed by the Siri Remote Back button? If fullScreenCover is not intended for this use case, what is the recommended way to implement a custom full-screen video player that needs to control Back-button behavior? The desired behavior is essentially: Back button ↓ Are playback controls visible? ├── Yes → hide controls, keep player presented └── No → dismiss player I would appreciate any guidance on the intended tvOS API or recommended architecture for implementing this behavior. Thanks!

A regression has been introduced with SwiftUI Menu in iOS 27 betas (still present in beta 6). This regression prevents objects whose properties are bound to contained Menu items from being correctly deallocated. In the example below, Player was immediately deallocated when the surrounding ModalView was dismissed on iOS 26 (or below): import Observation import SwiftUI @Observable final class Player { var playbackSpeed: Double = 1 } struct ModalView: View { @State private var player = Player() var body: some View { Menu { Picker(selection: $player.playbackSpeed) { ForEach([0.5, 1, 1.5, 2], id: \.self) { speed in Text("\(speed, specifier: "%g×")").tag(speed) } } label: { Text("Speed") } .pickerStyle(.inline) } label: { Text("Menu") } } } This is not the case anymore on iOS 27 beta. The Player instance is not deallocated anymore. A dedicated feedback (FB24486991) has been opened.

Having custom view inside safeAreaBar(edge: .top) breaking title. NavigationStack { VStack { List { CustomView() .listRowBackground(.customBackground) } .listStyle(.insetGrouped) .scrollContentBackground(.hidden) } .frame(maxWidth: .infinity, maxHeight: .infinity) .background(LinearGradient(...)) .toolbar { ToolbarItem(placement: .title) { Text("Test") } .safeAreaBar(edge: top) { Picker() .pickerStyle(.segmented) .padding([.horizontal, .bottom]) } .navigationTitle("Favorites") } } I have tried to replace .safeAreaBar with .safeAreaInset and then bug of large title is not anymore, but you are loosing blurry background when you scrolling. https://ibb.co/938zXbPV Its also affected in iOS 26, not just iOS 27

FB24091347 On macOS 27.0 beta (26A5388g), MacBook Pro M4 Pro, the built-in ProMotion display never settles on a stable refresh cadence. Scrolling in SwiftUI judders constantly. The same app binary was smooth on macOS 26, and is smooth on a 120 Hz ProMotion iPad. I captured two 60-second Instruments traces — same app, same scene, same scrolling, no external display — changing only the display's refresh-rate setting. On ProMotion the vsync interval standard deviation is 4.093 ms across six different cadences, mostly flip-flopping between 120 Hz and 60 Hz. Forced to a fixed 60 Hz it drops to 0.391 ms with a single cadence. The app presented an identical 59 fps median in both runs — frame production is perfectly steady, the display just holds each frame for an unpredictable length of time. That's what makes this nasty: it's invisible to every frame-rate metric, so it looks like the app got slow when nothing about the app changed. I spent most of a day profiling my own code before realising the app was never the problem. Workaround: force the built-in display to 60 Hz. Worth noting, because it complicates the picture: attaching a 60 Hz Studio Display makes the built-in smooth, but the Studio itself then judders — despite its own vsync cadence measuring perfectly stable. So refresh rate alone isn't the whole story, and there may be a second mechanism. The clean, reproducible, single-variable result is the ProMotion vs forced-60 Hz comparison on the built-in panel. If you can reproduce this on an M-series MacBook Pro on 27 beta, please file a duplicate referencing FB24091347.

On macOS 26 I can see the dividers when I open my Help menu: However, on iPadOS 26 the dividers don't appear: I am simply using Divider() to separate my menu bar items in my CommandGroup. iPadOS does support dividers as I can see them for the system generated Edit menu but for some reason it's not working here. Does anyone know if I am doing something wrong with the iPadOS implementation?

Hi, My Mac app allows a customer to drag and drop a file package onto a SwiftUI view. I can't seem to find a way to successfully call .startAccessingSecurityScopedResource() with the file/dir that was dropped into the view. I put together a simple test app. Here is the code: struct ContentView: View { @State var isTargetedForDrop: Bool = false var body: some View { VStack { Image(systemName: "globe") .imageScale(.large) .foregroundStyle(.tint) Text("Hello, world!") Rectangle() .stroke(Color.gray) .onDrop(of: [UTType.fileURL], isTargeted: $isTargetedForDrop) { providers in guard let provider = providers.first(where: { $0.hasItemConformingToTypeIdentifier(UTType.fileURL.identifier) }) else { return false } provider.loadItem(forTypeIdentifier: UTType.fileURL.identifier, options: nil) { item, error in if let error = error { print("Drop load error: \(error)") return } if let url = item as? URL { print("Dropped file URL: \(url)") } else if let data = item as? Data, let url = URL(dataRepresentation: data, relativeTo: nil) { print("Dropped file URL (from data): \(url)") let access = url.startAccessingSecurityScopedResource() if access { print("Successfully accessed file at URL: \(url)") } else { print("Failed to access file at URL: \(url)") } url.stopAccessingSecurityScopedResource() } else { print("Unsupported dropped item: \(String(describing: item))") } } return true } } .padding() } } When I drop a file package into this view I see, "Failed to access file at URL: <the_full_file_path>" I'm running Xcode 26 on macOS 26.

On iOS/iPadOS 27 Beta 5 (24A5408d), I can consistently reproduce SwiftUI Button actions being ignored when the buttons are placed inside a horizontal ScrollView near the top of a view. This occurs on physical iPhone and iPad devices and on an iPhone 16 Simulator. Equivalent UI was reliable on the preceding beta. Minimal shape: struct ContentView: View { @State private var selection = "All" var body: some View { NavigationStack { VStack(spacing: 0) { ScrollView(.horizontal, showsIndicators: false) { HStack { ForEach(["All", "Food", "Transport"], id: \.self) { item in Button(item) { selection = item } .padding() } } } Text("Selected: \(selection)") Button("Control below") { selection = "Control" } Spacer() } .navigationTitle("Touch Hit-Test Repro") .navigationBarTitleDisplayMode(.inline) } } } The standalone reproducer includes an XCUITest comparison. Results on the iOS 27 Beta 5 iPhone 16 Simulator: Horizontal ScrollView: fails; the chip is reported as hittable but tap() does not invoke its action. Remove .searchable: still fails. Remove the sheet: still fails. Remove only the horizontal ScrollView: passes. Tap a normal button below the strip: passes. Final result: 3 failed, 2 passed. This points to a Beta 5 hit-testing or gesture arbitration regression involving Button inside a horizontal ScrollView, rather than application state or a transparent overlay. Feedback filed: FB24307724 Has anyone found a framework-level workaround that preserves both native button semantics and horizontal scrolling? Related historical reports include https://developer.apple.com/forums/thread/763436 and https://developer.apple.com/forums/thread/794212.

When a view combines .navigationBarBackButtonHidden(true) with a custom ToolbarItem(placement: .navigationBarLeading) back button, both controls render side by side in the navigation bar — the system back button is not fully suppressed, only visually emptied. This appears to be related to the new Liquid Glass toolbar platter system introduced this cycle. Environment Xcode 27 beta 3 iOS Version : 27.0 Reproduces on: Simulator 16.0 (1063.4) SimulatorKit 955.7 CoreSimulator 1168 Steps to Reproduce Create a NavigationStack with a root view and a pushed detail view. On the detail view, set .navigationBarBackButtonHidden(true). Also add a custom back button via .toolbar { ToolbarItem(placement: .navigationBarLeading) { Button { dismiss() } label: { HStack { Image(systemName: "chevron.backward"); Text("Back") } } } }. Expected Result Only the custom "Back" button (chevron + text) is visible. Actual Result Two back-button-shaped controls appear side by side: an empty/default system back button platter, and the custom "Back" button. Confirmed via Xcode's View Debugger (Debug ▸ View Debugging ▸ Capture View Hierarchy): two sibling UIPlatformGlassInteractionView nodes exist under NavigationBarPlatterContainer_v2 ▸ PlatterContainerHostingView. One wraps a bare, unlabeled _UIButtonBarButton (the system-generated back control); the other wraps a BarItemView containing the app's custom Button (chevron + "Back" text). Both are laid out as independent glass platters rather than being merged into one leading toolbar group. Minimal Reproducible Project Attached: [BackButtonDuplicationRepro.zip] — a stripped-down single-screen repro isolating just this behavior (no navigation stack customization, no third-party code). Related report This looks like the same underlying issue as thread 812048 ("Toolbar Rendering Bug — ToolbarItem Duplication when Back Button Hidden"), which an Apple DTS engineer has already responded to requesting a reproducible project — hopefully this attached project + View Debugger evidence helps move that along. Also potentially related: thread 814816 (hidesSharedBackground not working for backBarButtonItem), which points at the same general area of the new Liquid Glass toolbar/platter system.