What is the correct way to implement scrolling in a looong list that uses ScrollView and LazyVstack Imagine I have some api that returns a longs list of comments with replies The basic usecase is to scroll to the bottom(to the last comment) Most of the time this works fine But, imagine some of the comments have many replies like 35 or more (or even 300) User expands replies for the first post, then presses scroll to bottom. The scrollbar reaches the bottom and I see the blank screen. Sometimes the scrollbar may jump for a while before lazyvstack finishes loading or until I manually scroll up a bit or all the way up and down What should I do in this case? Is this the swiftui performance problem that has no cure? Abstract example: ScrollViewReader { proxy in ScrollView { LazyVStack { ForEach(comments) { comment in CommentView(comment: comment) .id("comment-\(comment.id)") } } } } struct CommentView: View { let comment: Comment @State var isExpanded = false var body: some View { VStack { Text(comment.text) if isExpanded { RepliesView(replies: comment.replies) // 35-300+ replies } } } } ... scroll proxy.scrollTo("comment-\(lastComment.id)", anchor: .bottom)

I was trying to figure out why my bottom sheet looks weird and doesn't have the "proper glass" look. I found that this issue seems to be new to iOS 26.1. See the images below, they show the same view hierarchy (in this case UIHostingController configured as bottom sheet that has NavigationStack and content. On iOS 26.1 there seems to be extra two layers of background - even though I am no adding any. iOS 26: iOS 26.1 Has anyone experienced something similar? Any workarounds? I am happy to completely disable the glass effect for this bottom sheet if it helps. The screenshots show one sheet, but the same thing happens for another ones.

is there anything I can do about this? It's in a navigation controller, and I get a lot of these when I pop and push. eventually it causes glitches with zoom animations making for some really loopy zooms. I posted a movie to FB20439774. If there's anything I can do to fix it would be great. Unable to simultaneously satisfy constraints. ( "<NSAutoresizingMaskLayoutConstraint:0x600002149680 h=-&- v=-&- TtC5UIKitP33_DDE14AA6B49FCAFC5A54255A118E1D8713ButtonWrapper:0x106b0e700.minX == 0 (active, names: '|':TtGC5UIKit22UICorePlatformViewHostGVS_32PlatformViewRepresentableAdaptorVS_P10$186c5d1b020ButtonRepresentation:0x106b08ef0 )>", "<NSAutoresizingMaskLayoutConstraint:0x600002149590 h=-&- v=-&- H:[TtC5UIKitP33_DDE14AA6B49FCAFC5A54255A118E1D8713ButtonWrapper:0x106b0e700]-(0)-| (active, names: '|':TtGC5UIKit22UICorePlatformViewHostGVS_32PlatformViewRepresentableAdaptorVS_P10$186c5d1b020ButtonRepresentation:0x106b08ef0 )>", "<NSLayoutConstraint:0x600002142b20 _TtC5UIKitP33_DDE14AA6B49FCAFC5A54255A118E1D8713ButtonWrapper:0x106b0e700.width == _UIButtonBarButton:0x106b16ef0.width (active)>", "<NSLayoutConstraint:0x60000214a4e0 'UITemporaryLayoutWidth' TtGC5UIKit22UICorePlatformViewHostGVS_32PlatformViewRepresentableAdaptorVS_P10$186c5d1b020ButtonRepresentation:0x106b08ef0.width == 0 (active)>", "<NSLayoutConstraint:0x600002143200 'IB_Leading_Leading' H:|-(1)-[_UIModernBarButton:0x106b09810] (active, names: '|':_UIButtonBarButton:0x106b16ef0 )>", "<NSLayoutConstraint:0x6000021434d0 'IB_Trailing_Trailing' H:[_UIModernBarButton:0x106b09810]-(1)-| (active, names: '|':_UIButtonBarButton:0x106b16ef0 )>" ) Will attempt to recover by breaking constraint <NSLayoutConstraint:0x6000021434d0 'IB_Trailing_Trailing' H:[_UIModernBarButton:0x106b09810]-(1)-| (active, names: '|':_UIButtonBarButton:0x106b16ef0 )>

Hi, I have a List and I want to limit the dynamic text size for some of the elements in the list's row item view. I created a test view below. The ".dynamicTypeSize(.large)" restriction only works if it's applied to the List view, not if it's set for the the ContentItemView in the ForEach below. Is there a reason for this? Do I need to do something else to limit a list row to a certain size? The example only has a text field, but I want to do this for a Image with some text inside it, and I wanted to restrict that text field, but it doesn't seem to work when the view is inside a List row. Please let me know if there's a workaround for it. import SwiftUI import CoreData struct ContentView: View { @FetchRequest( sortDescriptors: [NSSortDescriptor(keyPath: \Item.timestamp, ascending: true)], animation: .default) private var items: FetchedResults<Item> @State private var multiSelectedContacts = Set<Item.ID>() var body: some View { NavigationStack { List (selection: $multiSelectedContacts) { ForEach(items) { item in ContentItemView(item: item) } .dynamicTypeSize(.large) // <-- doesn't works } .dynamicTypeSize(.large) // <-- THIS WORKS } } } struct ContentItemView: View { @Environment(\.managedObjectContext) private var viewContext @ObservedObject var item: Item @State var presentConfirmation = false var body: some View { HStack { if let timestamp = item.timestamp, let itemNumber = item.itemNumber { Text("\(itemNumber) - \(timestamp, formatter: itemFormatter)") } } .popover(isPresented: $item.canShowPopover, content: { Text("Test Item Label") .frame(width: 100, height: 150) }) } } private let itemFormatter: DateFormatter = { let formatter = DateFormatter() formatter.dateStyle = .short formatter.timeStyle = .long return formatter }() #Preview { ContentView().environment(\.managedObjectContext, PersistenceController.preview.container.viewContext) }

In this WWDC talk about liquid glass https://developer.apple.com/videos/play/wwdc2025/219/ they mention that there are two variants of liquid glass, regular and clear. I don't see any way to try the clear variant using the .glassEffect() APIs, they only expose regular, is there some other way to try the clear variant?

When a ScrollView or List is nested in a TabView, you can press on the tab button and the scroll view will scroll to top. import SwiftUI struct SwiftUIView: View { let items = (1...100).map { "Item \($0)" } var body: some View { TabView { Tab("home", systemImage: "house") { ScrollView { ForEach(items, id: \.self) { item in Text(item) .frame(maxWidth: .infinity, alignment: .center) } } } } } } #Preview { SwiftUIView() } But if we add a background to the ScrollView, the scroll to top gesture breaks. import SwiftUI struct SwiftUIView: View { let items = (1...100).map { "Item \($0)" } var body: some View { TabView { Tab("home", systemImage: "house") { ScrollView { ForEach(items, id: \.self) { item in Text(item) .frame(maxWidth: .infinity, alignment: .center) } } // Set background on ScrollView. .background(Color.red) } } } } #Preview { SwiftUIView() } I made a similar post on StackOverflow, but haven't been able to find a proper solution. This feels like a bug of some sort in SwiftUI.

I know iPhone Cannot prohibit screenshots, but I have seen someone else's solution, which is to capture a white page instead of the current design page when taking screenshots. I want to use swift implement iPhone The photo generated when taking a screenshot is a white screen, and I don't want my page to be seen by others

We have encountered a consistent problem with OTP (One Time Password) autofill on iOS versions 26.0.1 through 26.3. The issue pertains to apps implementing OTP input using multiple UITextFields (often 6 or 7 separate text boxes for each digit). Problem Details: When tapping the OTP autofill suggestion from Messages or supported third-party apps, iOS autofill pastes the entire OTP string into just one UITextField (commonly the second or focused field) rather than distributing digits across the individual text fields. The delegated UITextField methods such as textField:shouldChangeCharactersInRange:replacementString: receive an entire OTP string at once, but the usual event handlers like UIControlEventEditingChanged do not always trigger, breaking existing logic relying on those. This results in the OTP input UI showing incorrect or partial OTP, confusing users and forcing manual re-entry. Many popular apps employing multi-field OTP input UIs face similar autofill malfunctions on iOS 26.x, impacting user experience negatively. Setting textContentType = .oneTimeCode on the first text field alone is insufficient to restore the intended autofill behavior on iOS 26.x. This represents a regression or functional deficiency compared to iOS 15-18 autofill handling patterns, which worked reliably for these multi-field OTP UIs.| Expected Behavior: OTP autofill should either automatically split the filled code into each UITextField or trigger consistent delegate/callback events to enable developers to replicate this behavior manually. textDidChange or equivalent events should fire on autofill updates to reflect text changes correctly in multi-field OTP input. Apple’s OTP autofill system should transparently support or provide clear guidelines for handling multi-field OTP input on iOS 26+. What We’ve Tried: Setting .oneTimeCode content type on only the first UITextField. Handling OTP autofill in delegate methods including shouldChangeCharactersInRange. Manual distribution and custom logic triggered by textDidChange and other callbacks. Confirming all relevant system autofill settings are enabled. Testing on multiple devices and iOS versions (26.0.1 through 26.3). Note: its happen for may apps which have text field with 6 box otp fill

Dear random Apple UIKit engineer. This is a question for you. Today let's speak about keyboard notifications. In particular, UIResponder.keyboardWillShowNotification and UIResponder.keyboardWillHideNotification. While working with those, I noticed some undocumented behaviour. First, let me give you some context: extension UIViewController { func registerForKeyboardNotifications() { NotificationCenter.default.addObserver(self, selector: #selector(keyboardNotification), name: UIResponder.keyboardWillShowNotification, object: nil) NotificationCenter.default.addObserver(self, selector: #selector(keyboardNotification), name: UIResponder.keyboardWillHideNotification, object: nil) } /// Override this method to handle keyboard notifications. @objc func keyboardNotification(_ notification: Notification) { ... } } Eventually, I found that latter method with 3 dots has an implicit animation inside it's scope. Here is the [proof.](https://medium.com /uptech-team/why-does-uiresponder-keyboard-notification-handler-animate-10cc96bce372) Another thing I noticed, is that this property definition is perfectly valid let curve = UIView.AnimationCurve(rawValue: 7)!. The 7 btw comes from UIResponder.keyboardAnimationCurveUserInfoKey as a default value during my tests. So, the enum with 4 possible values (0...3) can be initialized with a value out of enum's cases range. Also, how can I initialize UIView.AnimationOption from 7? I will pollute my OptionSet which I feed to options parameter on UIView.animate(...) My questions: Why implicit animation is not documented and can I trust it or it's a subject to change. Why UIView.AnimationCurve(rawValue: 7)! does not crash. How can I convert UIResponder.keyboardAnimationCurveUserInfoKey's value into UIView.AnimationOption properly if I don't want to use implicit value. I don't encroach on UIKit secrets. I just need to know how to work with the API. Thank you!

In macOS 13.2, the NSTrackingEnabledDuringMouseDrag flag for NSTrackingArea is broken, i.e., mouse-entered and mouse-exited events are not sent during a drag. This problem did not exist in macOS 12. I've filed a bug report, FB11973492, just wondering if anyone knows a workaround.

[Submitted as FB21078443] When using .matchedTransitionSource with .navigationTransition(.zoom), swiping back from the left edge to return from a detail view causes the source item to disappear once the transition finishes. It’s only a visual issue—the item is still there and can be tapped to open again. This doesn’t happen when using the Back button; only the swipe-back gesture triggers it. Also, it only reproduces on a physical device, not in Simulator. SYSTEM INFO Xcode 26.1.1 (17B100) macOS 26.1 (25B78) iOS 26.1 (23B85) iOS 26.2 (23C5044b) REPRO STEPS Run the code below on a physical device, tap an image, then swipe from the left edge to dismiss the detail view. ACTUAL The image zooms back to its origin, then disappears once the animation settles. EXPECTED The image card remains visible. SCREENSHOTS CODE import SwiftUI struct Item: Identifiable, Hashable { let id = UUID() let imageName: String let title: String } struct ContentView: View { @Namespace private var namespace let items = [ Item(imageName: "SampleImage", title: "Sample Card 1"), Item(imageName: "SampleImage2", title: "Sample Card 2") ] var body: some View { NavigationStack { ScrollView { VStack(spacing: 16) { ForEach(items) { item in NavigationLink(value: item) { CardView(item: item) .matchedTransitionSource(id: item.id, in: namespace) } .buttonStyle(.plain) } } .padding() } .navigationTitle("Zoom Transition Issue") .navigationSubtitle("Tap image, then swipe back from left edge") .navigationDestination(for: Item.self) { item in DetailView(item: item, namespace: namespace) .navigationTransition(.zoom(sourceID: item.id, in: namespace)) } } } } struct CardView: View { let item: Item var body: some View { GeometryReader { geometry in ZStack(alignment: .bottom) { Image(item.imageName) .resizable() .scaledToFill() .frame(width: geometry.size.width, height: geometry.size.height) .clipped() } } .frame(height: 200) .clipShape(RoundedRectangle(cornerRadius: 16)) } } struct DetailView: View { let item: Item let namespace: Namespace.ID var body: some View { Image(item.imageName) .resizable() .scaledToFill() .clipped() } }

I'm running into an issue where my application will hang when switching tabs. The issue only seems to occur when I include a Swift Chart in a navigation label. The application does not hang If I replace the chart with a text field. This appears to only hang when running on macOS 26. When running on iOS (simulator) or visionOS (simulator, on-device) I do not observe a hang. The same code does not hang on macOS 15. Has any one seen this behavior? The use case is that my root view is a TabView where the first tab is a summary of events that have occurred. This summary is embedded in a NavigationStack and has a graph of events over the last week. I want the user to be able to click that graph to get additional information regarding the events (ie: a detail page or break down of events). Initially, the summary view loads fine and displays appropriately. However, when I switch to a different tab, the application will hang when I switch back to the summary view tab. In Xcode I see the following messages === AttributeGraph: cycle detected through attribute 162104 === === AttributeGraph: cycle detected through attribute 162104 === === AttributeGraph: cycle detected through attribute 162104 === === AttributeGraph: cycle detected through attribute 162104 === === AttributeGraph: cycle detected through attribute 162104 === A simple repro is the following import SwiftUI import Charts @main struct chart_cycle_reproApp: App { var body: some Scene { WindowGroup { TabView { Tab("Chart", systemImage: "chart.bar") { NavigationStack { NavigationLink { Text("this is an example of clicking the chart") } label: { Chart { BarMark( x: .value("date", "09/03"), y: .value("birds", 3) ) // additional marks trimmed } .frame(minHeight: 200, maxHeight: .infinity) } } } Tab("List", systemImage: "list.bullet") { Text("This is an example") } } } } }

The application crashes immediately when the system attempts to display the automatic password input view controller (_SFAutomaticPasswordInputViewController). This occurs during the login or password-filling process. OS Version: iOS 26.2 Beta 1 Build Number: (23C5027f) Fatal Exception: NSInvalidArgumentException *** -[__NSArrayM insertObject:atIndex:]: object cannot be nil

When scrolling a basic NSScrollView there seems to be a sudden jump after each flick. Scrolling does not appear smooth and is disorientating. A scroll jump seems to happen directly after letting go of a scroll flick using a trackpad/mouse. Right at that moment the scroll turns into a momentum scroll, slowly decreasing the speed. But the first frame after the gesture the content jumps forward, more than what is expected. Observations: Counterintuitively, scrolling appears to be smoother when disabling NSScrollView.isCompatibleWithResponsiveScrolling. If disabled using a custom NSScrollView subclass there is no large jump anymore. Scrolling also appears to be smoother using a SwiftUI ScrollView. I assume that has the same behaviour as a disabled isCompatibleWithResponsiveScrolling Ironically a WKWebView scrolls much smoother. No sudden jump is observable. It also seems to scroll with faster acceleration, but the individual frames do appear smoother. Why is this better than a native NSScrollView? Elastic scrolling at the bounds of the scroll view also appears much smoother for WKWebViews. When pulling to refresh there is a jump for NSScrollView/SwiftUI, but not for WKWebView. When using an NSScrollView with isCompatibleWithResponsiveScrolling disabled, scrolling appears just as smooth as WKWebView on macOS 13 Ventura and below. On macOS 14 Sonoma scrolling behaviour is suddenly different. Please see a sample project with 4 different scroll views side by side: https://github.com/floorish/ScrollTest Screen recordings show the sudden jumps when scrolling and when elastic scrolling. Tested on Intel & Arm Macs, macOS 11 Big Sur through 15 Sequoia, built with Xcode 16. Should isCompatibleWithResponsiveScrolling be disabled on Sonoma+? Are there any drawbacks? There is also no overdraw anymore since Monterey, as described in https://developer.apple.com/library/archive/releasenotes/AppKit/RN-AppKitOlderNotes/#10_9Scrolling Even with responsive scrolling disabled, why is WKWebView scrolling much smoother than NSScrollView?

I want to check whether a sandboxed application already has access permission to a specific URL. Based on my investigation, the following FileManager method seems to be able to determine it: FileManager.default.isReadableFile(atPath: fileURL.path) However, the method name and description don't explicitly mention this use case, so I'm not confident there aren't any oversights. Also, since this method takes a String path rather than a URL, I'd like to know if there's a more modern API available. I want to use this information to decide whether to prompt the user about the Sandbox restriction in my AppKit-based app.

Fellow iOS developers, can you tell me how to make UIDatePicker usable on iOS 26?

This is really odd. If you setup a UISearchController with a preferredSearchBarPlacement of .stacked and you setup the search bar with scope buttons, then when the view controller is initially displayed, the currently hidden scope buttons block touch events from reaching the main view just below the search bar. But once the search is activated and dismissed, then the freshly hidden scope buttons no longer cause an issue. This is easily demonstrated by putting a UITableViewController in a UINavigationController. Setup the table view to show a few simple rows. Then setup a search controller using the following code: func setupSearch() { // Setup a stacked search bar with scope buttons // Before the search is ever activated, the hidden scope buttons block any touches in the main view controller // in the area just below the search bar. // Once the search is activated and dismissed, the problem goes away. It seems that displaying and hiding the // scope buttons at least once fixes the issue that exists beforehand. // This issue only exists in iOS/iPadOS 26, not iOS/iPadOS 18 or earlier. let search = UISearchController(searchResultsController: UIViewController()) search.hidesNavigationBarDuringPresentation = true search.obscuresBackgroundDuringPresentation = true search.scopeBarActivation = .onSearchActivation // Ensure button appear immediately let searchBar = search.searchBar searchBar.scopeButtonTitles = [ "One", "Two", "Three" ] self.navigationItem.searchController = search self.navigationItem.hidesSearchBarWhenScrolling = false // Issue appears even if this is true self.navigationItem.preferredSearchBarPlacement = .stacked } When first shown, before any attempt is made to activate the search, any attempt to tap on the upper 2/3 of the first row in the table view (which is just below the search bar) fails. If you tap on the lower 1/3 of the first row it works fine. If you then activate the search (now the scope buttons appear) and then dismiss the search (now the scope buttons are hidden again), then there is no issue tapping anywhere on the first row of the table. But if you restart the app, the problem starts over again. This problem happens on any iPhone or iPad, real or simulated, running iOS/iPadOS 26 RC. This is a regression from iOS 18 or earlier.

NSVisualEffectView in AppKit has two main properties: material and blendingMode. Material is well supported in SwiftUI, but I can't seem to find an equivalent for blendingMode. What is the SwiftUI equivalent to NSVisualEffect.BlendingMode?

An app that is capable of running on iPad can be usually run on Mac if properly designed and that's great. Recently I've tried to launch one of my old apps on macOS 26 in "Designed for iPad" mode and noticed that image picker behaves oddly. Images are barely selectable, you have to click several times and yet it might select image and might not. On iPhone and on iPad any kind of image picking works fine. I've tried all kinds of native pickers (PhotosPicker, PHPickerViewController, UIImagePickerController), but the result is almost the same. So how should I nowadays do image picking in (mostly) iOS app when it is run on macOS? Below is the most canonical and modern code I've tried. The issue is reproduced even with such bare minimum of code with the label not being put to a Form/List or any other factors. import SwiftUI import PhotosUI struct ContentView: View { @State private var selectedItem: PhotosPickerItem? @State private var selectedImage: UIImage? var body: some View { VStack { if let selectedImage { Image(uiImage: selectedImage) .resizable() .scaledToFit() } // Most modern photo library picker, not `PHPickerViewController`, not `UIImagePickerController` based pickerPhotosPicker( selection: $selectedItem, matching: .images ) { Label("Select Photo", systemImage: "photo") } .onChange(of: selectedItem) { newItem inTask { if let data = try? await newItem?.loadTransferable(type: Data.self), let uiImage = UIImage(data: data) { selectedImage = uiImage } } } } } }

Prior to iOS 26, ToolbarItems with .bottomBar placement were convenient for tab-specific frequent actions. With iOS 26’s new tab layering now obscuring such ToolbarItems, it’s unclear whether .tabViewBottomAccessory is the intended replacement or if another pattern (like persistent floating buttons) is encouraged instead. What’s the recommended way to support quick, tab-specific actions under the new system? I’ve tried conditionally rendering a .tabViewBottomAccessory based on the active tab, but this causes a crash, which I’ve reported as FB18479195.