Hi there, Upon using List View for tabular information showcase on both iOS and iPadOS, I have come to realize that the drag and drop support works only for iPadOS but not iOS. Although it is possible to workaround this by using a ScrollView wrapping around a LazyVStack instead, the editing mode along with left-wipe to delete feature would be missing. Not to mention that this workaround only supports single item rather than multiple items. Therefore, I am here to ask if the drag and drop will come to support devices running iOS, and if so, when will this feature ship. If not, will LazyVStack/LazyHStack support native editing mode. Thank you for your time.

In iOS 26.1, SwiftUI's tabViewBottomAccessory API cannot control visibility properly. The tabViewBottomAccessory remains always visible, which is inconsistent with the behavior in iOS 26.0 / iOS 26.0.1. ` struct ContentView: View { enum Tabs { case first } @State private var selection: Tabs = .first @State private var showBottomAccessory: Bool = true var body: some View { tabView } var tabView: some View { TabView(selection: $selection) { Tab(value: .first) { content } label: { VStack { Text("first") } } } .tabViewBottomAccessory { if showBottomAccessory { Text("BottomAccessory") } } } var content: some View { Button("change") { showBottomAccessory.toggle() } } } `

Hello. Is there a good SwiftUI approach on getting the TextEditor cursor position? I have a TextEditor and sometimes when we have a longer text inside it, the cursor is not seen because the keyboard is above covering the bottom of the TextEditor. I would like to somehow detect the position of the cursor, and if it's on the last line of the TextEditor, scroll to the bottom. I've already checked a bit and didn't find any good method of doing this in SwiftUI. If you have any ideas on how to do this, or even a different method any help would be highly appreciated. Thank you!

I’m developing a share extension for iOS 26 with Xcode 26. When the extension’s sheet appears, it always shows a full white background, even though iOS 26 introduces a new “Liquid Glass” effect for partial sheets. Expected: The sheet background should use the iOS 26 glassmorphism effect as seen in full apps. Actual behavior: Custom sheets in my app get the glass effect, but the native system sheet in the share extension always opens as plain white. Steps to reproduce: Create a share extension using UIKit Present any UIViewController as the main view Set modalPresentationStyle = .pageSheet (or leave as default) Observe solid white background, not glassmorphism Sample code: swift override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .clear preferredContentSize = CGSize(width: UIScreen.main.bounds.width, height: 300) } Troubleshooting attempted: Tried adding UIVisualEffectView with system blur/materials Removed all custom backgrounds Set modalPresentationStyle explicitly Questions: Is it possible to enable or force the Liquid Glass effect in share extensions on iOS 26? Is this a limitation by design or a potential bug? Any workaround to make extension sheet backgrounds match system glass appearance?

I noticing that Monterey defaults to the NSWindowToolbarStyleAutomatic / NSWindowToolbarStyleUnified toolbar style, which suppresses the "use Small Size" menu item and customization checkbox. So I've set the window to use NSWindowToolbarStyleExpanded. However, the toolbar will no longer change to a smaller icon size, as it did in MacOS 10.14, 10.15, and 11.0. I've tried to set the toolbar item sizing to "Automatic" for all of our toolbar icons, but that results in bad positioning in both Regular and Small Size mode -- the height is way too big. The native size of the icon .png files are 128 x 128. What's odd is that if I resize the window with the toolbar to be wider, the NSToolbarItems in the overflow area will be displayed in the toolbar are 128 x 128, where the rest of the toolbar icons get displayed as a 32 x 32 icon. The only way to get it to layout remotely correct is to make the NSToolbarItem to have an explicit minimum size of 24 x 24 and maximum size of 32 x 32. And that USED to allow "small size", but on Monterey, it no longer does. Anyone had any success with small size icons on Monterey?

I have a couple of (older) UIKit-based Apps using UISplitViewController on the iPad to have a two-column layout. I'm trying to edit the App so it will shows the left column as sidebar with liquid glass effect, similar to the one in the "Settings" App of iPadOS 26. But this seems to be almost impossible to do right now. "out of the box" the UISplitViewController already shows the left column somehow like a sidebar, with some margins to the sides, but missing the glass effect and with very little contrast to the background. If the left column contains a UITableViewController, I can try to get the glass effect this way within the UITableViewController: tableView.backgroundColor = .clear tableView.backgroundView = UIVisualEffectView(effect: UIGlassContainerEffect()) It is necessary to set the backgroundColor of the table view to the clear color because otherwise the default background color would completely cover the glass effect and so it's no longer visible. It is also necessary to set the background of all UITableViewCells to clear. If the window is in the foreground, this will now look very similar to the sidebar of the Settings App. However if the window is in the back, the sidebar is now much darker than the one of the Settings App. Not that nice looking, but for now acceptable. However whenever I navigate to another view controller in the side bar, all the clear backgrounds destroy the great look, because the transition to the new child controller overlaps with the old parent controller and you see both at the same time (because of the clear backgrounds). What is the best way to solve these issues and get a sidebar looking like the one of the Settings App under all conditions?

I’m not seeing Liquid Glass on any standard components. A month ago around July 17th I ran our app and saw Liquid Glass on our tab view and various standard components. Those components have not been changed and yet I’m no longer seeing Liquid Glass in our app at all. Components that were previously liquid glass but now are not include TabView and back navigation buttons. I set the UIDesignRequiresCompatibility key explicitly to false but no luck. I was seeing this in Beta 7 and Beta 8 on a real device and on a sim.

I have checked the sample project from the documentation page and noticed there is an issue with image/images not being preselected. The issue happens on iOS 26.1 and above (checked iOS 26.2 beta). I couldn't find any change to the PhotoPicker in the documentation.

When using an image in a List item, you sometimes want to tint that image, but only if the item isn’t selected. When it’s selected, you usually want the contents of the list item to be all-white, for contrast. The backgroundProminence Environment value ostensibly exists for this purpose, but in my tests, it never seems to change. Am I doing something wrong? Is there an alternative solution? For instance, this code: import SwiftUI struct ProminentBackgroundInList: View { var body: some View { List(selection: .constant(0)) { ListItem().tag(0) ListItem().tag(1) } } } struct ListItem: View { @Environment(\.backgroundProminence) var backgroundProminence var body: some View { HStack { Image(systemName: "person.fill") .foregroundStyle(backgroundProminence == .standard ? .orange : .primary) Text("Person") } } } #Preview { ProminentBackgroundInList() } Produces this result:

When I try to show/hide the content in .safeAreaBar(edge: .bottom), especially the content with a large height, the background animation of the toolbar is very laggy. iOS 26 RC Feedback ID - FB19768797 import SwiftUI struct ContentView: View { @State private var isShown: Bool = false var body: some View { NavigationStack { Button("Toggle") { withAnimation { isShown.toggle() } } ScrollView(.vertical) { ForEach(0..<100) { index in Text("\(index)") .padding() .border(.blue) .background(.blue) .frame(maxWidth: .infinity) } } .scrollEdgeEffectStyle(.soft, for: .bottom) .safeAreaBar(edge: .bottom) { if isShown { Text("Safe area bar") .padding(64) .background(.red) } } } } } #Preview { ContentView() }

[Also submitted as FB19313064] The .disabled() modifier doesn't visually disable buttons inside a ToolbarItem container on iOS 26.0 (23A5297i) devices. The button looks enabled, but tapping it doesn't trigger the action. When deployment target is lowered to iOS 18 and deployed to an iOS 18 device, it works correctly. It still fails on an iOS 26 device, even with an iOS 18-targeted build. This occurs in both the Simulator and on a physical device. Screen Recording Code struct ContentView: View { @State private var isButtonDisabled = false private var osTitle: String { let version = ProcessInfo.processInfo.operatingSystemVersion return "iOS \(version.majorVersion)" } var body: some View { NavigationStack { VStack { Button("Body Button") { print("Body button tapped") } .buttonStyle(.borderedProminent) .disabled(isButtonDisabled) Toggle("Disable buttons", isOn: $isButtonDisabled) Spacer() } .padding() .navigationTitle("Device: \(osTitle)") .navigationBarTitleDisplayMode(.large) .toolbar { ToolbarItem { Button("Toolbar") { print("Toolbar button tapped") } .buttonStyle(.borderedProminent) .disabled(isButtonDisabled) } } } } }

I have been playing around with the new AsyncImage Api in SwiftUI I am using the initialiser that passes in a closure with the AsyncImagePhase, to view why an image may not load, when I looked at the error that is passed in if the phase is failure, the localised description of the error is "Cancelled" but this is happening before the view is being displayed. I am loading these images in a list, I imagine I am probably doing something which is causing the system to decide to cancel the loading, but I cannot see what. Are there any tips to investigate this further?

Since macOS 26 Beta 1, I notice that the window reopening behavior had changed. Say there are two desktops (spaces), one might: open an app window in desktop 1 close that window switch to desktop 2 reopen the app window (by click on dock tile, spotlight search...) Prior to macOS 26, that window will always reopen in current desktop. This is IMO the right behavior because these windows are most likely transient (message app, chat app, utilities app or note app). In macOS 26, however, will switch to desktop 1 (where the window is closed) and reopen the window in desktop 1. This is weird to me because: Window is "closed", hence it should not be attached to desktop 1 anymore, unlike minimize. Switching desktop interrupts user's current workflow. It's annoying to switch back specially when there're many desktops. This behavior is inconsistent. Some reopen in current desktop, some reopen in previous desktop. Apps like Music, Notes and Calendar reopened in previous desktop, while Mail, Messages, and Freeform reopened in current desktop. I did a little bit of experiment, and find out that apps that reopened in current desktop are most likely because they take an extra step to release the window when it's closed. I believe this is a bug, so I fire a feedback (FB18016497) back in beta 1. But I did not get any response or similar report from others, to a point that I kinda wonder if this is intended. I can easily force my app to reopen in current desktop by nullifying my window controller in windowWillClose, but this behavior essentially change how one can use the Spaces feature that I think I should bring this up to the community and see what other developers or engineers thinks about it.

I was wondering what the recommended way is to persist user settings with SwiftData? It seems the SwiftData API is focused around querying for multiple objects, but what if you just want one UserSettings object that is persisted across devices say for example to store the user's age or sorting preferences. Do we just create one object and then query for it or is there a better way of doing this? Right now I am just creating: import SwiftData @Model final class UserSettings { var age: Int = 0 var sortAtoZ: Bool = true init(age: Int = 0, sortAtoZ: Bool = true) { self.age = age self.sortAtoZ = sortAtoZ } } In my view I am doing as follows: import SwiftUI import SwiftData struct SettingsView: View { @Environment(\.modelContext) var context @Query var settings: [UserSettings] var body: some View { ForEach(settings) { setting in let bSetting = Bindable(setting) Toggle("Sort A-Z", isOn: bSetting.sortAtoZ) TextField("Age", value: bSetting.age, format: .number) } .onAppear { if settings.isEmpty { context.insert(UserSettings(age: 0, sortAtoZ: true)) } } } } Unfortunately, there are two issues with this approach: I am having to fetch multiple items when I only ever want one. Sometimes when running on a new device it will create a second UserSettings while it is waiting for the original one to sync from CloudKit. AppStorage is not an option here as I am looking to persist for the user across devices and use CloudKit syncing.

When using my app's complications with either Siri Intents or App Intents after syncing .watchface files, the complications appear without names in the iOS Watch app's complication picker. This leads to complications showing as blank entries without previews in the native watch app selector. I'm using WidgetKit to create Watch complications with both approaches: AppIntents and Siri Intents. We've tried multiple approaches with our WidgetKit watch complications: Switching between IntentConfiguration and StaticConfiguration Using different naming conventions for kind strings Ensuring display names are properly set Testing across different watchOS versions But the result is always the same: after syncing .watchface files, our complications appear unnamed in the Watch app's complication picker. Is this a known limitation with .watchface syncing, a bug in the current implementation, or is there a specific requirement we're missing to maintain complication names during the sync process?

It appears that hidesBottomBarWhenPushed no longer works in iOS 26 Beta 1. Is it supposed to work, is it going away or is there a alternate behavior we should be using?

struct ContentView: View {   @State var isPresented = false   var body: some View {     Button {       isPresented.toggle()     } label: {       Text("Button")     }     .sheet(isPresented: $isPresented) {       SubView()     }   } } struct SubView: View {   @State var text = ""   var body: some View {     NavigationStack {       TextEditor(text: $text)         .toolbar {           ToolbarItemGroup(placement: .bottomBar) {             Button("Click") {             }           }           ToolbarItemGroup(placement: .keyboard) {             Button("Click") {             }           }         }     }   } }

I've been experimenting with Liquid Glass quite a bit and watched all the WWDC videos. I'm trying to create a glassy segmented picker, like the one used in Camera: however, it seems that no matter what I do there's no way to recreate a truly clear (passthrough) bubble that just warps the light underneath around the edges. Both Glass.regular and Glass.clear seem to add a blur that can not be evaded, which is counter to what clear ought to mean. Here are my results: I've used SwiftUI for my experiment but I went through the UIKit APIs and there doesn't seem to be anything that suggests full transparency. Here is my test SwiftUI code: struct GlassPicker: View { @State private var selected: Int? var body: some View { ScrollView([.horizontal], showsIndicators: false) { HStack(spacing: 0) { ForEach(0..<20) { i in Text("Row \(i)") .id(i) .padding() } } .scrollTargetLayout() } .contentMargins(.horizontal, 161) .scrollTargetBehavior(.viewAligned) .scrollPosition(id: $selected, anchor: .center) .background(.foreground.opacity(0.2)) .clipShape(.capsule) .overlay { DefaultGlassEffectShape() .fill(.clear) // Removes a semi-transparent foreground fill .frame(width: 110, height: 50) .glassEffect(.clear) } } } Is there any way to achieve the above result or does Apple not trust us devs with more granular control over these liquid glass elements?

On testing my app with tvOS 18, I have noticed the Siri Remote back button no longer provides system-provided behavior when interacting with tab bar controller pages. Instead of moving focus back to the tab bar when pressed, the back button will close the app, as if the Home button was pressed. This occurs both on device and in the Simulator. Create tvOS project with a tab bar controller. Create pages/tabs which contain focusable items (ie. buttons) Scroll down to any focusable item (ie. a button or UICollectionView cell) Hit the Siri Remote back button. See expect behavior below: Expected behavior: System-provided behavior should move focus back to the tab bar at the top of the screen. Actual results: App is closed and user is taken back to the Home Screen. Has anyone else noticed this behavior?

Hello, I’ve encountered what seems to be a bug with the keyboard dismissal animation on iOS 26.0 Beta (25A5349a), Xcode Version 26.0 beta 5 (17A5295f). When dismissing the keyboard from a SwiftUI TextField using @FocusState, the keyboard does not animate downward as expected. Instead, it instantly disappears, which feels jarring and inconsistent with system behavior. I am attaching a short video demonstrating the issue. Below is the minimal reproducible code sample: // // ContentView.swift // TestingKeyboardDismissal // // Created by Sasha Morozov on 27/08/25. // import SwiftUI struct ContentView: View { @State private var text: String = "" @FocusState private var isFocused: Bool var body: some View { ZStack { Color.clear.ignoresSafeArea() VStack(spacing: 20) { TextField("Enter text here...", text: $text) .textFieldStyle(.roundedBorder) .focused($isFocused) .padding(.horizontal) HStack { Button("Focus") { isFocused = true } .buttonStyle(.borderedProminent) Button("Unfocus") { isFocused = false } .buttonStyle(.bordered) } } .frame(maxWidth: .infinity, maxHeight: .infinity, alignment: .center) .padding() } .ignoresSafeArea(.keyboard, edges: .bottom) } } #Preview { ContentView() } Steps to reproduce: Run** the app on iOS 26.0 beta 5 (17A5295f). Tap Focus → keyboard appears as expected. Tap Unfocus → keyboard disappears instantly without the usual slide-down animation. Expected result: Keyboard should animate smoothly downwards when dismissed. Actual result: Keyboard instantly vanishes without animation. p.s. we should be really able to upload videos here for demostration