Hello everybody! TLDR: Issues with visibleItemsInvalidationHandler. Minimal code to reproduce available. I've been working with Compositional Layout for a while now and recently I've found myself needing to implement custom animation based on scroll position of UI elements. Once I found visibleItemsInvalidationHandler it felt like the exact solution that I needed. Once I implement I've found out it doesn't quite behave as you'd expect. To put it simply, it seems like the animations only work if your whole layout does not use .estimated nor .uniformAcrossSiblings. As soon as you use them then the animations will stop working, I've debugged it deeper and it seems like the invalidation context generated by it does not include the indexPath of the cells, which is always included in the version in which it works. Feel free to swap the line 51 with its comment to flip between the working and failing version of it. Playground Example My final question therefore is... Is this the expected behavior? The documentation doesn't give any clues about such behavior and although I've tried relentlessly to find a workaround for this specific hiccup I was not successful with it.

I have a question about how UIKit expects us to handle interaction events at scale. From what I understand so far: For UIControls (UIButton, UISwitch, UITextField, etc.), we explicitly register with addTarget(_:action:for:). For gestures, we add UIGestureRecognizer instances to views. For UIView subclasses, we can override touch methods like touchesBegan/touchesEnded. All of this must be done on the main thread, since UIKit isn’t thread-safe. Now here’s my main concern If I have a complex UI with hundreds or thousands of widgets, am I expected to perform these registrations individually for each widget and each high-level event (tap, long press, editing changed, etc.)? Or does UIKit provide a more centralized mechanism? In short: Is per-widget, per-event registration the “normal” UIKit approach, or are there best practices for scaling event handling without writing thousands of addTarget or addGestureRecognizer calls? Thanks!

Hello, I have a number of UIViewControllers that are presented as follows: vc.modalPresentationStyle = UIModalPresentationStyle.popover vc.modalTransitionStyle = UIModalTransitionStyle.coverVertical self.present(vc, animated: true, completion: nil) The VC is designed from a Storyboard where I set the 'view' of the VC to have a .clear 'backgroundColor', I have a smaller 'Alert View' added as a subview which is what the user interacts with. In iOS 13 - iOS 18 this would present modally, not take up the entire screen and allow the user to see relevant context from the screen underneath. In iOS 26 Beta 5 and every beta prior the system injects a 'UIDropShadowView' in the View Hierarchy, this view has a solid color backdrop, either white/black depending on light/dark mode. This causes all underlying content to be blocked and essentially forces a full screen modal presentation despite the existing design. I am looking for a way to remove this solid color. I'm not sure if it's intentional or a bug / oversight. I have been able to remove it in a hacky way, I cycle the view hierarchy to find 'UIDropShadowView' and set it's backdrop to transparent. However when you swipe down to partially dismiss the view it turns to Liquid Glass when it is around 75% dismissed and then resets the background color to white/black. I tried creating a custom UIViewControllerTransitioningDelegate so that I could re-implement the existing behaviour but it's incredibly difficult to mimic the partial dismiss swipe down effect on the VC. I have also tried changing my presentation to: vc.modalPresentationStyle = UIModalPresentationStyle.overFullScreen vc.modalTransitionStyle = UIModalTransitionStyle.crossDissolve This works but then the user loses the ability to interactively swipe to dismiss. Any help would be appreciated. Thank you!

An app built on Xcode 26 (beta4) presents various UIViewCOntrollers. Presentation of any UIViewController that contains a UIToolbar leads to a UIKit crash when run on an iOS 18.5 device, it does not crash when run on iOS 26. The exception logged: *** Terminating app due to uncaught exception 'NSInvalidUnarchiveOperationException', reason: 'Could not instantiate class named TtGC5UIKit17UICoreHostingViewVCS_21ToolbarVisualProvider8RootView because no class named TtGC5UIKit17UICoreHostingViewVCS_21ToolbarVisualProvider8RootView was found; the class needs to be defined in source code or linked in from a library (ensure the class is part of the correct target)' Anyone else seen this? I've submitted a bug report via Feedback Assistant, including a minimal Xcode workspace that reproduces the crash, hoping this will get some attention.

The default style for a segmented picker in iOS 26 is now a capsule shape. Is it possible to get back the previous rounded rectangle shape? In SwiftUI I have tried using the clipShape, containerShape, and background modifiers, applying a RoundedRectangle shape with a corner radius, to no avail. In UIKit I have tried to adjust the corner configuration for the UISegmentedControl, also to no avail. Am I missing something really obvious or is it impossible to change the style here? 🤔

In the iOS 26 developer preview, I noticed that the new Liquid Glass style only applies when the user’s home screen theme is set to transparent. Is it possible to allow users to directly set the new Liquid Glass style for widgets, instead of having it tied to the home screen theme setting?

According to the WWDC25 Presentation Track workouts with HealthKit on iOS and iPadOS, there is supposed to be a new property for restoring an active workout after a crash on iOS/iPadOS. The developer documentation also supports this. However, this property does not seem to exist in the latest Xcode 26 beta, even in projects targeting iOS 26.0 as the minimum version. Am I missing something? Has this property not been made available yet? It is actually looking like all of the new iOS 26.0 properties are missing UIScene.ConnectionOptions on my system.

How can I remove the "recents" section from long-pressing on my app icon? I've added the following to my AppDelegate, which removes it from the top MenuBar, but not from the app icon context menu. My app has registered a custom filetype, but it is not a document based app. Opening files imports them into the app's user library, and so does not make sense to have a "recents" list. override func buildMenu(with builder: any UIMenuBuilder) { super.buildMenu(with: builder) builder.remove(menu: .openRecent) }

I have a voice chat app that frequently writes to the universal clipboard. This works fine most of the time, but I've noticed that if I don't touch the screen for a long time, the universal clipboard information I read on my Mac won't update until I touch the app screen again. How can I fix this?

Hi, I’m seeing a crash when running my app on iOS 18 simulators or devices using Xcode 26 beta 3. My app’s minimum deployment target is iOS 17, and the crash does not happen when running from Xcode 16.4. The crash occurs specifically at this line: return UIStoryboard(name: storyboard.rawValue, bundle: nil) .instantiateViewController(withIdentifier: view.rawValue) Crash Details: ** Terminating app due to uncaught exception 'NSInvalidUnarchiveOperationException', reason: 'Could not instantiate class named _TtGC5UIKit17UICoreHostingViewVCS_21ToolbarVisualProvider8RootView_ because no class named _TtGC5UIKit17UICoreHostingViewVCS_21ToolbarVisualProvider8RootView_ was found; the class needs to be defined in source code or linked in from a library (ensure the class is part of the correct target)' *** First throw call stack: (0x191c3321c 0x18f0cdabc 0x191c91ea0 0x19d740774 0x19d740a18 0x19d740cac 0x194626680 0x194dbc784 0x19d740890 0x19d740cac 0x1949aadd8 0x19d740890 0x19d740a18 0x19d740cac 0x194802e24 0x1945f008c 0x194ed1808 0x107a8bfa0 0x107a8c05c 0x1945ec128 0x19d740890 0x19d740cac 0x1945eba60 0x19d740890 0x19d740a18 0x19d740cac 0x1945f07dc 0x1945eaea4 0x19492ee80 0x10763de00 0x1076e56fc 0x1076e5674 0x1076e5e04 0x19496108c 0x194f9b9a0 0x1949072c4 0x194f998cc 0x194f9af04 0x19445139c 0x19445ac28 0x194467508 0x1079afaec 0x1079aff5c 0x1944189a0 0x194417be4 0x1944114e4 0x194411404 0x194410ab4 0x19440c1e4 0x191b28a8c 0x191b288a4 0x191b28700 0x191b29080 0x191b2ac3c 0x1ded09454 0x19453d274 0x194508a28 0x1073564f4 0x1b89fff08) terminating due to uncaught exception of type NSException The crash occurs immediately at app launch, when attempting to load a storyboard-based UITabBarController. Works as expected on: Xcode 16.4 + iOS 18 (simulator/device) Xcode 26 beta 3 + iOS 26 (simulator/device) Running from Xcode 26 beta 3 onto iOS 18 simulators or devices and it immediate crash from the particular storyboard Setup: Xcode: 26 beta 3 macOS: 15.5 iOS Simulators: iOS 18.5 Minimum deployment target: iOS 17 UIKit-based app (not using SwiftUI) No custom toolbars or host views in use explicitly Is this a known compatibility issue when building with the iOS 26 SDK and running on iOS 18? Are there any workarounds or recommendations for running apps targeting iOS 17+ on iOS 18 simulators when using Xcode 26?

A bottom accessory view is set on the UITabBarController. When changing the window size either by dragging the resizing grip or when going to portrait mode, the accessory view shrinks down to the smaller width. When resizing the window to make it larger, the accessory view doesn’t resize to the full available width. During a workshop setup by Apple, folks from Apple told me that the view set as the content view of the UITabAccessory should not have its frame changed, either by using Auto Layout or by setting the frame. It seems logical since the view in the bottom accessory is supposed to resize accordingly to several factors, like when going inline inside the tab bar. Am I missing something? Maybe there is additional setup required not mentioned in the dedicated video. Feedback is FB19017330. It contains a sample project and videos demonstrating the issue. Reproduced on Xcode 26 beta 6 (17A5305f) I copy and paste the sample code that setups the bottom accessory for good measure. final class MiniPlayer: UIView { let label = UILabel() override init(frame: CGRect) { super.init(frame: frame) label.text = "Mini Player" label.numberOfLines = 0 label.textAlignment = .center addSubview(label) label.translatesAutoresizingMaskIntoConstraints = false NSLayoutConstraint.activate([ label.centerXAnchor.constraint(equalTo: centerXAnchor), label.centerYAnchor.constraint(equalTo: centerYAnchor) ]) } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } } // MARK: - View Controller class ViewController: UIViewController { let rootTabBarController = UITabBarController() let miniPlayer = MiniPlayer() override func viewDidLoad() { super.viewDidLoad() let items: [UITab] = [ UITab(title: "Tab 1", image: UIImage(systemName: "archivebox.fill"), identifier: "tab-1") { _ in UIViewController() }, UITab(title: "Tab 2", image: UIImage(systemName: "books.vertical.fill"), identifier: "tab-2") { _ in UIViewController() }, UISearchTab { _ in UIViewController() } ] rootTabBarController.tabs = items rootTabBarController.view.backgroundColor = .secondarySystemBackground view.addSubview(rootTabBarController.view) rootTabBarController.view.translatesAutoresizingMaskIntoConstraints = false NSLayoutConstraint.activate([ rootTabBarController.view.leadingAnchor.constraint(equalTo: view.leadingAnchor), rootTabBarController.view.topAnchor.constraint(equalTo: view.topAnchor), rootTabBarController.view.trailingAnchor.constraint(equalTo: view.trailingAnchor), rootTabBarController.view.bottomAnchor.constraint(equalTo: view.bottomAnchor) ]) rootTabBarController.bottomAccessory = UITabAccessory(contentView: miniPlayer) } }

@MainActor class KeyboardObserver { var token: NotificationCenter.ObservationToken! func registerObserver(screen: UIScreen) { let center = NotificationCenter.default token = center.addObserver(of: screen, for: .keyboardWillShow) { keyboardState in print("+++ Keyboard showed up!") } } } The notification is never called. The sample code from the sessions also does not work for me. let keyboardObserver = NotificationCenter.default.addObserver( of: UIScreen.self for: .keyboardWillShow ) { message in UIView.animate( withDuration: message.animationDuration, delay: 0, options: .flushUpdates ) { // Use message.endFrame to animate the layout of views with the keyboard let keyboardOverlap = view.bounds.maxY - message.endFrame.minY bottomConstraint.constant = keyboardOverlap } } @MainActor class KeyboardObserver { func registerObserver(screen: UIScreen) { let center = NotificationCenter.default let token = center.addObserver( of: screen, for: .keyboardWillShow ) { keyboardState in let startFrame = keyboardState.startFrame let endFrame = keyboardState.endFrame self.keyboardWillShow(startFrame: startFrame, endFrame: endFrame) } } func keyboardWillShow(startFrame: CGRect, endFrame: CGRect) {} }

I’m trying to detect a double-tap action on a UIButton. There seem to be two possible approaches: Using a UITapGestureRecognizer with numberOfTapsRequired = 2. Using the .touchDownRepeat event of UIControl.Event. What is the recommended approach for reliably handling double-taps on UIButton? Are there any practical differences in terms of behavior, performance, or best practices between these two methods? Additionally, I noticed that UIControl.Event defines a large set of events (like .editingChanged, .valueChanged, etc.). Can all these events be applied to any UIControl subclass such as UIButton, or are they only valid for specific controls like UITextField, UISlider, etc.? If not all events are supported by all controls, what is the rationale behind exposing them under a shared UIControl.Event enum? Thanks in advance!

The default cell height is 44pt in iOS 18 and 52pt in iOS 26. I'm trying to reduce the height back to 44pt in one screen that needs to fit as much content on screen as possible. How do you do that when using UIListContentConfiguration? I expected this would do the trick but alas it doesn't reduce the cell height. let cellRegistration = UICollectionView.CellRegistration<UICollectionViewListCell, Item> { cell, indexPath, item in cell.contentConfiguration = { var config = UIListContentConfiguration.valueCell() config.text = "Title" config.secondaryText = "Value" // This only removes horizontal margins, does not change vertical margins config.axesPreservingSuperviewLayoutMargins = [] config.directionalLayoutMargins = .zero return config }() }

On iPhone SE (2nd/3rd generation) running iOS 26 beta , the safeAreaInsets.top unexpectedly returns 0 instead of the expected 20 points, causing UI elements that rely on safe area layout to be overlapped by the status bar. You can see that i works fine with iOS 18, whereas iOS 26 the status bar is overlapped. Is this a known bug or there is new API changes that I might not be aware of.

I’m working with UIButton and I’d like to register multiple UIControl.Events (e.g. .touchUpInside, .touchDown, .touchCancel, .primaryActionTriggered) using the same selector. For example: button.addTarget(self, action: #selector(handleButtonEvent(_:forEvent:)), for: [.touchUpInside, .touchDown, .touchCancel, .primaryActionTriggered]) @objc func handleButtonEvent(_ sender: UIButton, forEvent event: UIEvent) { // How do I tell which UIControl.Event triggered this? } From my understanding: If I use the single-parameter version (@objc func handleButtonEvent(_ sender: UIButton)), I can’t distinguish which event fired. If I use the two-parameter version with UIEvent, I can inspect touch.phase or event.type, but that feels indirect. Questions: Is there a recommended way to directly know which UIControl.Event caused the selector to fire? Is sharing a single selector across multiple control events considered a good practice, or is it more common to register separate selectors per event? Would appreciate guidance on what Apple recommends here.

I’m working with UIButton and finding different examples for event handling. Currently, I have a single action method like this, which receives the sender and the UIEvent: @objc func buttonHandler(_ sender: UIButton, forEvent event: UIEvent) { if let touches = event.allTouches, let touch = touches.first { switch touch.phase { case .began: print("TouchDown") case .ended: if sender.bounds.contains(touch.location(in: sender)) { print("TouchUpInside") } else { print("TouchUpOutside") } case .cancelled: print("TouchCancel") default: break } } if event.type == .presses { print("PrimaryActionTriggered") } } Is this considered best/recommended practice in UIKit, or should I use separate selector methods for each event type (e.g. .touchDown, .touchUpInside, .touchUpOutside) using addTarget(_:action:for:)? Are there any advantages or disadvantages to using a single handler with UIEvent versus multiple selectors for UIControlEvents? Thanks in advance!

I'm using a standard UITabBarController on iPad. When first selecting any tab, the corresponding menu bar items are grayed out for this view controller. It's only when I tap any button in that view controller, like in the toolbar, that the view controller truly becomes the first responder (you can see the sidebar selection turns to gray from blue), enabling those menu bar items. Am I doing something wrong here? A video of the issue can be found here: https://mastodon.social/@nicoreese/114949924393554961 AppDelegate: ... builder.insertChild(MenuController.viewModeMenu(), atStartOfMenu: .view) class func viewModeMenu() -> UIMenu { let listViewModeCommand = UICommand( title: String(localized: "As List"), image: UIImage(systemName: "list.bullet"), action: #selector(GamesViewController.setListViewMode), propertyList: SettingsService.ViewMode.list.rawValue ) ... let viewModeMenu = UIMenu( title: "", image: nil, identifier: .viewModeMenu, options: .displayInline, children: [listViewModeCommand...] ) return viewModeMenu } GamesViewController: @objc func setListViewMode() { updateViewMode(.list) } I can do this, but then the sidebar selection instantly turns gray, which looks odd and other system apps do not behave this way. override func viewDidAppear(_ animated: Bool) { super.viewDidAppear(animated) becomeFirstResponder() } override var canBecomeFirstResponder: Bool { return true }

I'm using multiple scenes in my iPad app. When I open a new scene from my main window, that new window is always the same size as the previous window. When I make the main window very small and then create a new scene, that new window is also tiny. When I make the main window very big, you guessed it. UIWindowScene.sizeRestrictions does not seem to help here. How can I give new windows a default size (it's okay if they're resizable after presenting)? This is such a weird behavior. Video of the problem in action: https://mastodon.social/@nicoreese/115033539035249909

It appears from my testing that the following is true: If you close all windows of an app, the app terminates entirely. Minimizing the last window sends it into multitasking. This is different from previous behavior and might have implications on your app's logic. If you close the last window and quickly tap the app icon again, that same window will come back. Waiting a second before tapping the app icon will bring up the main window (likely because by that point the app was terminated and relaunched). Is this expected behavior? I did not see any announcement of this. I find this a bit counterintuitive and would presume that closing the last window would just send the app to multitasking, just like previously. Quitting the app should be reserved by swiping up on it in the multitasking UI or with a new context menu command.