I removed version 21.0 (build 23.0/25) from the review queue 3 days ago because I needed to submit an updated build. Since then, every attempt to resubmit gives this error: "You've reached the maximum number of submissions allowed in review for this platform. To submit another, wait until one of your existing submissions has been reviewed or remove one from review." The App Review page still shows the submission as stuck/processing, and it hasn't cleared after 3 days. I already opened a support ticket but haven't heard back yet. Has anyone else run into a submission stuck in a "cancellation in progress" state for this long? Is there anything else I can do besides wait for support to manually clear it? App: Nexora AI Version: 21.0 Build: 25.0 Any guidance appreciated, this is blocking a time-sensitive release. #App Store Connect, #AppSubmission, #AppReview

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.

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

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.

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.

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.

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!

I'm seeing a regression in SwiftUI Charts on iOS 27 beta 1. Any view placed inside a BarMark's overlay annotation no longer receives the size of the parent BarMark. It collapses to zero, so any content sized from geo.size (e.g. a Rectangle meant to fill the bar) renders empty or incorrectly. Expected: The GeometryReader reports the BarMark's rendered width/height, and the Rectangle fills the BarMark (this is the behavior in iOS 26 and earlier). Actual: On iOS 27 beta 1, geo.size is effectively zero, so the overlay content has an extremely small size. I suspect this could be a small bug with the new ContentBuilder / ViewBuilder changes but that's just a hunch. Here's a code sample which reproduces the issue. // MARK: - Mock Data Models struct ScheduleSeries: Identifiable { let id = UUID() let data: [ScheduleItem] } struct ScheduleItem: Identifiable { let id = UUID() let startDate: Date let startHour: Double let endHour: Double let secondaryText: String? } // MARK: - Minimal Reproducible Example struct ContentView: View { // Generate two consecutive days for the mock data let mockSchedule: [ScheduleSeries] = [ ScheduleSeries(data: [ ScheduleItem( startDate: Date(), startHour: 9.0, endHour: 11.5, secondaryText: "Morning Event" ), ScheduleItem( startDate: Calendar.current.date(byAdding: .day, value: 1, to: Date())!, startHour: 13.0, endHour: 16.0, secondaryText: "Afternoon Event" ) ]) ] var body: some View { VStack(alignment: .leading) { Text("FB: Annotation Sizing Bug") .font(.headline) .padding(.bottom, 8) Text("Expected: The gray Rectangle should stretch to fill the BarMark.\nActual: GeometryReader/Annotation fails to size to the parent BarMark.") .font(.caption) .foregroundColor(.secondary) .padding(.bottom) Chart(mockSchedule) { series in ForEach(series.data, id: \.startDate) { element in BarMark( x: .value("Day", element.startDate, unit: .day, calendar: .current), yStart: .value("Start", element.startHour), yEnd: .value("End", element.endHour), width: .ratio(0.99) ) .annotation(position: .overlay, alignment: .topLeading) { item in ZStack { VStack(alignment: .leading, spacing: 0) { // BUG DEMONSTRATION: // This GeometryReader and Rectangle previously filled the BarMark, but in Xcode 27 it does not GeometryReader { geo in Rectangle() .fill(Color.black.opacity(0.15)) .frame(width: geo.size.width, height: geo.size.height) } } .foregroundColor(.white) .font(.caption2) } } } } .chartYScale(domain: 0...24) // Lock the Y-axis to a 24-hour scale } .padding() } } Environment: Xcode 27 beta 1 / iOS 27 beta 1 Reproduces on device and Simulator Worked as expected on iOS 26 and earlier Here's what the issue looks like in our app with zero code changes: iOS 26 iOS 27 I've filed a feedback report (FB23016343) with a sample project attached. Has anyone else hit this, or found a workaround for sizing overlay annotation content to a BarMark in iOS 27? Thanks!

On Mac Catalyst 26, a Button bar item in a bottom toolbar look squished. This happens only when the "Mac Catalyst Interface" option is set to "Optimize for Mac". When it is set to "Scale to match iPad", the buttons look fine. For example, in the screenshots below, the text button should say "Press Me", instead of "…" A simple reproducible snippet and a screenshot below. The toolbar button comparison between "Scale to match iPad" and "Optimize for Mac" are shown. Optimize for Mac Scale to match iPad import SwiftUI struct ContentView: View { @State private var selectedItem: String? = "Item 1" let items = ["Item 1", "Item 2"] var body: some View { NavigationSplitView { List(items, id: \.self, selection: $selectedItem) { item in Text(item) } .navigationTitle("Items") } detail: { if let selectedItem = selectedItem { Text("Detail view for \(selectedItem)") .toolbar { ToolbarItemGroup(placement: .bottomBar) { Text("Hello world") Spacer() Button("Press Me") { } Spacer() Button { } label: { Image(systemName: "plus") .imageScale(.large) } } } } else { Text("Select an item") } } } }

In the Swift docs, it says cancellation uses a cooperative model, which I understand as that all jobs (ie function calls) need to handle cancellation manually even if the task containing them got cancelled. I am assuming this is still the case even with using the SwiftUi.task? The documentation for it should include a reference for how cancellation works to be complete.

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

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

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

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

Hello to anyone reading this. I am a bit lost as to what is the correct approach for enabling Collaboration for a Document based SwiftUI app. If I understand correctly, after setting up all the relevant entitlements and capabilities for enabling sharing, you only need to use ShareLink to begin a collaboration/send a copy by passing in the URL of the document. The collaboration is then handled with SWCollaborationView, which there have been NSViewRepresentable wrapper implementations posted around the web. My main question is; how do I know whether the document has been shared to create a collaboration? Do I have to have 2 sharing ToolbarItems? Basically, is there any documentation for implementing collaborations from a document based app, other than simply saying that starting a share is done by passing the url into a ShareLink? This seems to massively missing, or have I massively missed something?

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

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

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