Environment iPadOS 26.0 / 26.1 (Simulator: iPad Air 11-inch (M3)) SwiftUI, NavigationView + .navigationViewStyle(.stack) (also reproduced conceptually with NavigationStack) iPad only Symptom I have a custom split-style layout built with a plain HStack: HStack(spacing: 0) { if showSidebar { Sidebar().frame(width: 80).transition(.move(edge: .leading)) } HStack(spacing: 0) { NavigationStack { MenuList() }.frame(width: 230) Divider() NavigationStack { DetailScreen() } // <- this bar is affected } } Toggling showSidebar inside withAnimation changes the x origin of the right-hand navigation container by 80pt. After that toggle, the Liquid Glass platter (capsule) behind the navigation bar's leading bar button item is drawn at its previous x position, while the button's glyph is laid out correctly. The capsule and the glyph are visually separated by roughly the amount the container moved. Hit testing follows the glyph, so it is purely a rendering/layout mismatch of the platter background. Inspecting the view hierarchy, _UINavigationBarPlatterView / _UINavigationBarPlatterGlassView report a frame that matches the pre-toggle geometry, i.e. the platter container is not re-laid-out when the hosting navigation bar's window-space origin changes without its size changing in a way that triggers a full bar layout pass. Condition It only happens on screens where the navigation bar has exactly one platter group — i.e. a leading item and no trailing items. As soon as the same screen also has a .topBarTrailing item (so UIKit builds two platters), the leading platter is positioned correctly after the toggle. What I tried .id(...) on the toolbar content to force a rebuild: no effect adding a zero-size / hidden trailing ToolbarItem: no effect calling setNeedsLayout() / layoutIfNeeded() on the UINavigationBar after the animation: no effect disabling the animation: no effect The only workaround I found is to opt the leading group out of the system platter entirely and draw my own: ToolbarItemGroup(placement: .topBarLeading) { button .frame(width: 44, height: 44) .glassEffect(.regular.interactive(), in: Circle()) } .sharedBackgroundVisibility(.hidden) This fixes the offset, but it has its own downside — see https://developer.apple.com/forums/thread/811012 — the manually drawn glass does not participate in the navigation push/pop morph the system platter does. Notes The reproduction appears to be sensitive to the exact geometry / device orientation: a reduced sample I built later did not reproduce it reliably, so I have not been able to attach a minimal project yet. If a DTS engineer wants one, I can keep reducing. Questions: Is a plain HStack-based sidebar (rather than NavigationSplitView) an unsupported configuration for the navigation bar platter, i.e. is the platter's position expected to be invalidated only on size changes? Is there a supported way to invalidate the platter layout manually? Is .sharedBackgroundVisibility(.hidden) + manual .glassEffect the recommended escape hatch here, or is it expected to break the push/pop transition?

Hi, I noticed some unexpected layout behavior with Button in SwiftUI: the apparent horizontal padding/inset of a Button seems to change depending on the length of its text label. Here is a minimal example: VStack { Button { } label: { Text("我是一段很长的文字") .lineLimit(nil) .frame(maxWidth: .infinity, alignment: .leading) .border(.red) } Button { } label: { Text("我是一段") .lineLimit(nil) .frame(maxWidth: .infinity, alignment: .leading) .border(.red) } } .frame(width: 100) .border(.red) In Preview, the outer VStack has a fixed width of 100pt, and both Button labels use: .frame(maxWidth: .infinity, alignment: .leading) The red border around each Text shows that the label itself is receiving the expected available width. However, the two Buttons appear to have different horizontal insets between the Button's edge and the Text's edge, even though both Buttons are inside the same VStack and have the same layout configuration. In other words, the Button's apparent internal padding seems to depend on the intrinsic width / length of the label: ┌────────────────────┐ │ ┌──────────────┐ │ │ │ Long text │ │ │ └──────────────┘ │ └────────────────────┘ ┌────────────────────┐ │ ┌────────────┐ │ │ │ Short text │ │ │ └────────────┘ │ └────────────────────┘ What I find particularly confusing is that the label itself has: .frame(maxWidth: .infinity) so I would expect both Button labels to occupy the same available width. I'm trying to understand whether this is expected behavior of the default Button style or a consequence of SwiftUI's layout proposal/intrinsic-size system. Specifically: Why does the Button's apparent horizontal padding change based on the label's text length? Does the default Button style intentionally use the label's intrinsic/ideal size when determining its content inset? Is there an official SwiftUI API to specify a fixed horizontal content inset/padding for a Button, independent of the label's intrinsic size? If I want both Buttons to have exactly the same internal horizontal padding, what is the recommended SwiftUI approach? Is there a way to make the Button give its label the full proposed width before applying its own default styling/insets? I'm aware that I can implement a custom ButtonStyle, but I'm specifically wondering whether there is an existing SwiftUI API or modifier intended for controlling this behavior while retaining the system Button style. I'm seeing this behavior in recent versions of SwiftUI and would appreciate any clarification on the intended layout behavior and the recommended solution. Thanks!

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!

HI, I have an issue displaying SwiftUI previews with Xcode 14. My project has iOS and an watchOS Target. It also includes a lot of SPM, most of them only used by the PhoneApp. The project build successfully for both iOS and watchOS. I can see that when building the watch target, only SPM that are included in this target are build for for watchOS The issue is when I try to build a swiftUI preview of the watch target. In this case I can see on the build for Preview log that Xcode try to build ALL spm defined in the Xcode project, including the one that are not used by the watch Target, As a lot if spm are for iOS only, and doesn't build for watchOS, the build for preview fails, and I'm unable to preview my swiftUI views on the AppeWatch. Note that my project is working fine on Xcode 13. This issue is easy to reproduce in any Xcode projects containing a iOS and watchOS target by adding a SPM that is only for iOS. Any workaround to fix this issue ?

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?

hello. I was going through the Swift tutorial and am seeing that the code for MomentsViews.swift is showing as .sheet(isPresented: $showCreateMoment) { MomentEntryView() } but this makes the navigation title and toolbar not render. ChatGPT recommended this instead: .sheet(isPresented: $showCreateMoment) { NavigationStack { MomentEntryView() } } will the tutorial need to be updated or am I missing something elsewhere?

On visionOS 26.6 and 27 latest beta: PresentationComponent in a volumetric WindowGroup, when looking at the volume from a specific lower/back region create two bugs: buttons inside the presentation have their gaze obstructed by hand presence, no button shows any hover highlight hand movement in that specific area auto dismisses the presentation The focused public repro uses a thin ModelEntity with InputTargetComponent and ordinary SwiftUI buttons. Its README includes two clearer videos: https://github.com/mesqueeb/PresentationAutoCloseInBackOfVolume 1. Gaze obstructed on buttons when hand is at specific location (see "Test Action" has no hover highlight, even though i look at it) 2. Hover state restored on buttons when hand is gone (see "Test Action" has hover highlight) 3. Presentation auto closed when hand comes back The weirdest part: This only happens at a specific location, when walking to the back of the volume, then turning around and interacting with the volume from the lower right back side. Any workaround or fix guidance would be appreciated. Feedback Assistant: FB24569418.

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

Hi everyone, I am currently working on a SwiftUI / Swift client project that visualizes live, distributed infrastructure nodes across a dynamic map interface using MapKit. As the dataset scales and coordinates update dynamically, I want to ensure rendering performance stays smooth and memory overhead remains low. I would appreciate some guidance from the community on best practices for this scenario: Clustering vs. Custom Overlays: For frequently updating data points, is native annotation clustering (MKClusterAnnotation / clusteringIdentifier) the standard recommendation, or does heavy clustering introduce recalculation overhead during rapid state changes? Visible Region Filtering: What is the recommended pattern in modern MapKit (SwiftUI Map vs. MKMapViewRepresentable) for culling off-screen data points vs. letting MapKit handle view recycling? High-Frequency Updates: When coordinates or statuses update frequently (e.g., via polling or streaming data), what are the best practices to avoid unnecessary view rebuilds and maintain 60/120 FPS panning and zooming? Any architectural tips, performance benchmarks, or WWDC sessions you recommend reviewing for large-scale dynamic rendering would be greatly appreciated! Thanks in advance.

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).

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?

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.