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!

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?

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.

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

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.

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.

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

If a ViewAttachmentComponent moves into frame, it is low resolution until something changes the view while it is in frame. Video demonstrating the behavior: https://youtu.be/KXEFFiAnv1s I am on visionOS 27 beta 4. This did not occur when I was on visionOS 26.5. Also using Xcode 27.0 beta 4 and macOS 27.0 beta 4. To reproduce, have a ViewAttachmentComponent in an immersive space, look away, then look back, and it'll be low resolution. Anything which would change the view while it's in frame will then cause it to update in full resolution. Screenshot of low-resolution view after it moves back into frame from being out of frame: Screenshot after updating the view, making it high-resolution again: I've submitted feedback as FB24116473.

In a sheet, the gaze hover effect stops working after interacting with a button, until the sheet is closed and re-opened. As a result, I have no visual feedback on what UI elements are selected until I interact with them or until the sheet is re-opened. I'm using visionOS 27 beta 5 and Xcode 27 beta 5. I've submitted feedback as FB24299285 Video demonstrating the issue: https://youtu.be/l-t1ZEHDSzo

i've been struggling to get the SwiftUI instrument to work during the betas. It never produces any results on simulator, while on device it throws an error which prevents any results from other instruments from appearing. the error is: Failed to stop recording session: Data Providers emitted errors: Required I've tried on my iPad Pro 11-inch (M4) (iPadOS27 beta 3), and iPhone 17 Pro Max (iPadOS27 beta 2). And I get the same result running from my mac studio & MacBook air. Is this a known thing? cheers, Mike

Looking to see if anyone has experienced this issue, and is aware of any workarounds. With an app migrating towards SwiftUI Views but still using UIKit for primary navigation, my app makes use of UIHostingController to push SwiftUI Views onto a UINavigationController stack in a lot of areas. With iOS 26, I notice that SwiftUI's Menu view really struggles to present when contained in a UIHostingController. An error is logged to the console on presentation, and depending on the UI, the Menu won't present inside of it's container, or will jump around the screen. The bug, it seems is based in a private class UIReparentingView and I am curious if anyone has found a work around for this issue. The error reported is: Adding '_UIReparentingView' as a subview of UIHostingController.view is not supported and may result in a broken view hierarchy. Add your view above UIHostingController.view in a common superview or insert it into your SwiftUI content in a UIViewRepresentable instead. The simplest way to see this issue is to create a new storyboard based project. From the ViewController present a UIHostingController with a SwiftUI view that has a Menu and then simply tap to open the Menu. Thanks for any input!