I am building a centralized event handling system for UIKit controls and gesture recognizers. My current approach registers events using static methods inside a handler class, like this: internal class TWOSInternalCommonEventKerneliOS { internal static func RegisterTouchUpInside(_ pWidget: UIControl) -> Void { pWidget.addTarget( TWOSInternalCommonEventKerneliOS.self, action: #selector(TWOSInternalCommonEventKerneliOS.WidgetTouchUpInsideListener(_:)), for: .touchUpInside ) } @objc internal static func WidgetTouchUpInsideListener(_ pWidget: UIView) -> Void { print("WidgetTouchUpInside") } } This works in my testing because the methods are marked @objc and static, but I couldn’t find Apple documentation explicitly confirming whether using ClassName.self (instead of an object instance) is officially supported. Questions: Is this approach (passing ClassName.self as the target) recommended or officially supported by UIKit? If not, what is the safer alternative to achieve a similar pattern, where event registration can remain in static methods but still follow UIKit conventions? Would using a shared singleton instance as the target (e.g., TWOSInternalCommonEventKerneliOS.shared) be the correct approach, or is there a better pattern? Looking for official guidance to avoid undefined behavior in production.

Hi all, Sharing a reproducible UIKit issue I’m seeing across multiple iPadOS 26 betas, with a tiny sample attached and a short video. Short video https://youtu.be/QekYNnHsfYk Tiny project https://github.com/yoasha/ListSwipeOvershootReproSwift Summary In a UISplitViewController (.doubleColumn), a UICollectionView using list layout shows a large leading-swipe overshoot when the split view is expanded (isCollapsed == false). The cell content translates roughly 3–4× the action width. Repros with appearance = .plain and .grouped Does not repro with .insetGrouped Independent of trailing provider (issue persists when trailing provider is nil) Collapsed split (compact width) behaves correctly Environment Devices: iPad Air (3rd gen), iPadOS 26.0 (23A5326a) → Repro Simulators: iPad Pro 11-inch (M4), iPadOS 26.0 beta 6 → Repro Also tested on device: iPadOS 26 beta 5, 6, 7, 8 Xcode: 26.0 beta 6 (17A5305f) Steps to reproduce Launch the sample; ensure the split is expanded (isCollapsed == false). In the secondary list, set Appearance = Plain (also repros with Grouped). Perform a leading swipe (LTR: swipe right) on any row. Actual: content shifts ~3–4× the action width (overshoot). Expected: content translates exactly the action width. Switch Appearance = InsetGrouped and repeat the leading (swipe right) gesture → correct (no overshoot). Feedback Assistant FB ID: FB19785883 (full report + attachments filed; this forum thread mirrors the repro for wider visibility) Minimal code (core of the sample) If anyone from Apple needs additional traces or a sysdiagnose, I can attach promptly. Thanks! // Secondary column VC (snippet) var cfg = UICollectionLayoutListConfiguration(appearance: .plain) // also .grouped / .insetGrouped cfg.showsSeparators = true cfg.headerMode = .none cfg.leadingSwipeActionsConfigurationProvider = { _ in let read = UIContextualAction(style: .normal, title: "Read") { _,_,done in done(true) } read.backgroundColor = .systemBlue let s = UISwipeActionsConfiguration(actions: [read]) s.performsFirstActionWithFullSwipe = false return s } // Trailing provider can be nil and the bug still repros for leading swipe: cfg.trailingSwipeActionsConfigurationProvider = nil let layout = UICollectionViewCompositionalLayout.list(using: cfg) let collectionView = UICollectionView(frame: view.bounds, collectionViewLayout: layout) // … standard data source with UICollectionViewListCell + UIListContentConfiguration // Split setup (snippet) let split = UISplitViewController(style: .doubleColumn) split.preferredDisplayMode = .oneBesideSecondary split.viewControllers = [ UINavigationController(rootViewController: PrimaryTableViewController()), UINavigationController(rootViewController: SecondaryListViewController()) ]

All of these issues appear when the search controller is set on the view controller's navigationItem and the search controller's searchBar has its scopeButtonTitles set. So far the following issues are affecting my app on iOS/iPadOS 26 as of beta 7: When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to .integratedButton, and the searchBarPlacementAllowsToolbarIntegration is set to false (forcing the search icon to appear in the nav bar), on both iPhones and iPads, the scope buttons never appear. They don't appear when the search is activated. They don't appear when any text is entered into the search bar. FB19771313 I attempted to work around that issue by setting the scopeBarActivation to .manual. I then show the scope bar in the didPresentSearchController delegate method and hide the scope bar in the willDismissSearchController. On an iPhone this works though the display is a bit clunky. On an iPad, the scope bar does appear via the code in didPresentSearchController, but when any scope bar button is tapped, the search controller is dismissed. This happens when the app is horizontally regular. When the app on the iPad is horizontally compact, the buttons work but the search bar's text is not correctly aligned within the search bar. Quite the mess really. I still need to post a bug report for this issue. But if issue 1 above is fixed then I don't need this workaround. When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to .stacked, and the hidesSearchBarWhenScrolling property of the navigationItem is set to false (always show the search bar), and this is all used in a UITableViewController, then upon initial display of the view controller on an iPhone or iPad, you are unable to tap on the first row of the table view except on the very bottom of the row. The currently hidden scope bar is stealing the touches. If you activate and then cancel the search (making the scope bar appear and then disappear) then you are able to tap on the first row as expected. The initially hidden scope bar also bleeds through the first row of the table. It's faint but you can tell it's not quite right. Again, this is resolved by activating and then canceling the search once. FB17888632 When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to integrated or .integratedButton, and the toolbar is shown, then on iPhones (where the search bar/icon appears in the toolbar) the scope buttons appear (at the top of the screen) the first time the search is activated. But if you cancel the search and then activate it again, the search bar never appears a second (or later) time. On an iPad the search bar/icon appears in the nav bar and you end up with the same issue as #1 above. FB17890125 Issues 3 and 4 were reported against beta 1 and still haven't been fixed. But if issue 1 is resolved on iPhone, iPad, and Mac (via Mac Catalyst), then I personally won't be affected by issues 2, 3, or 4 any more (but of course all 4 issues need to be fixed). And by resolved, I mean that the scope bar appears and disappears when it is supposed to each and every time the search is activated and cancelled (not just the first time). The scope bar doesn't interfere with touch events upon initial display of the view controller. And there are no visual glitches no matter what the horizontal size class is on an iPad. I really hope the UIKit team can get these resolved before iOS/iPadOS 26 GM.

I have a few view controllers in a large UIKit application that previously started showing content right below the bottom of the top navigation toolbar. When testing the same code on iOS 26, these same views have their content extend under the navigation bar and toolbar. I was able to fix it with: if #available(iOS 26, *, *) { self.edgesForExtendedLayout = [.bottom] } when running on iOS 26. I also fixed one or two places where the main view was anchored to self.view.topAnchor instead of self.view.safeAreaLayoutGuide.topAnchor. Although this seems to work, I wonder if this was an intended change in iOS 26 or just a temporary bug in the beta that will be resolved. Were changes made to the safe area and edgesForExtendedLayout logic in iOS 26? If so, is there a place I can see what the specific changes were, so I know my code is handling it properly? Thanks!

Hello, First of all, I've already made a bug report here : https://feedbackassistant.apple.com/feedback/19731998 I'm facing a problem while using UIGraphicsImageRenderer to create an image, that is use to create a UIColor with a pattern via UIColor(patternImage:). It's well displayed for iOS 18.2 and lower, whereas the whole color is blank with iOS 26. -> Please find a sample project linked to the bug report ViewController.swift post that illustrates the issue, in the ViewController.swift file. I'll also link screenshots of the sample app, one built with iOS 18.2 and another with iOS 26.0. Reproduction steps : I create an image with UIGraphicsImageRenderer : let image = UIGraphicsImageRenderer().image { context in // Do anything here } Then I use this image to create a UIColor : UIColor(patternImage: image) I apply this color to the fillColor of a CAShapeLayer : shapeLayer.fillColor = UIColor(patternImage: image) Expected result : Run on iOS 26 and lower and the layer filled with the pattern color is correctly displayed, as it is on iOS 18.2 and lower. Observed result : Run on iOS 26 and the layer is filled with a blank/white color instead of the intended pattern color. Has anyone been facing the problem ? Thanks, Thibault Poujat

In iPadOS 26, Apple introduced macOS-style window control buttons (close, minimize, fullscreen) for iPad apps running in a floating window. I'm working on a custom toolbar (UIView) positioned near the top of the window, and I'd like to avoid overlapping with these new controls. However, I haven't found any public API that exposes the frame, layout margins, or safe area insets related to this new UI region. I've checked the window's safeAreaInsets, additionalSafeAreaInsets, and UIWindowSceneDelegate APIs, but none of them seem to reflect the area occupied by these buttons. Is there an officially supported way to: Get the layout information (frame, insets, or margins) of the window control buttons on iPadOS 26? Or, is there a system-defined guideline or padding value we should use to avoid overlapping this new UI? Any clarification or guidance would be appreciated!

I am trying to use Zone Sharing in my SwiftUI app. I have been attempting to get the UICloudSharingController to show an initial share screen to pick users and the mechanism to send the invitation. From the documentation, it appears that the UICloudSharingController .init(preparationHandler:) API is deprecated so I am not using that approach. Following the Apple documentation, I am creating a Zone Share and NOT saving it and presenting using the UICloudSharingController(share:container:) API. However, this presents a UI that is the 'mgmt' API for a Share. I can get to the UI I was expecting by tapping on the 'Share with More People' option, but I want to start on that screen for the user when they have not shared this before. So, I found an example app from Apple at: https://github.com/apple/sample-cloudkit-zonesharing. It has the same behavior. So we can simply discuss this problem based on that example code. How do I get the next View presented when tapping 'Share Group' to be the invitation for new users screen? Here is the UI it presents initially: And here is the UI (on the bottom half of the screen) I am trying to start the share process with: Thanks, Charlie

Issue Description: When toggling between the system keyboard and a custom input view, the keyboard height reported in subsequent keyboard notifications becomes incorrect!!! specifically missing the predictive text/suggestion bar height. Environment: Device: iPhone 11 Expected keyboard height: 346pt Actual reported height: 301pt (missing 45pt suggestion bar) Reproduction Steps: Present system keyboard → Height correctly reported as 346pt Switch to custom input view → Custom view displayed Switch back to system keyboard(no suggestion bar) → Height correctly reported as 301pt Trigger keyboard frame change → Height still incorrectly reported as 301pt despite suggestion bar being visible Expected Behavior: Keyboard height should consistently include the suggestion bar height (346pt total). Actual Behavior: After switching from custom input view, keyboard height excludes suggestion bar height (301pt instead of 346pt). key code private func bindEvents() { customTextField.toggleInputViewSubject.sink { [weak self] isShowingCustomInput in guard let strongSelf = self else { return } if isShowingCustomInput { strongSelf.customTextField.inputView = strongSelf.customInputView strongSelf.customInputView.frame = CGRect(x: 0, y: 0, width: strongSelf.view.frame.size.width, height: strongSelf.storedKeyboardHeight) } else { strongSelf.cusTextField.inputView = nil } strongSelf.customTextField.reloadInputViews() strongSelf.customTextField.becomeFirstResponder() }.store(in: &cancellables) }

In our app we have a UICollectionView with Drag&Drop functionality enable and collection view is covering the entire screen. When we drag a collection view item to the edge of the screen it does not scroll the UICollectionView instead that our item turns into the app icon and scrolling blocked. It is happening only if Stage Manager is enabled in the device and if Stage Manager is disabled it is working fine. This issue we are facing after iOS 18.6 release, before 18.6 it was working fine i.e, collection view was scrolling to next items when we dragging an item to edge of the screen, similar to the iOS calendar app when we drag an event to edge it starts scrolling the date. And in iOS 26 if we drag an item to edge, Springboard is getting crashed.

Verbatim of a feedback report (FB18431713) I submitted, duplicated here since we can't see each other's feedbacks, and I wanted a centralized place to track the resolution of this as I'm surely not the only one facing this. When building the app using Xcode 26 beta 2 and running it in an iOS 26 simulator, I'm experiencing a retain cycle in the UINavigationController. From the data I saw in Xcode's memory graph debugger, it seems that _UIViewControllerOneToOneTransitionContext is retaining it. I base this on the fact that the line connecting a view controller and _UIViewControllerOneToOneTransitionContext has a "strong" reference, as indicated in Xcode. (However, I'm reporting this as a retain cycle in UINavigationController, as that's what seems to hold onto this transition-context.)

I've noticed that in iOS 26, Navigation Bar Items' Image Insets parameters as set in Xcode are not being read correctly. Specifically, it appears that on iOS 26 beta, negative inset numbers are being read as positive. Feedback report FB19838333 includes a sample project demonstrating this bug.

Since the ios 26 beta our app is crashing when calling LoadRequest() on the wkwebview class. The app crashes out completely when it occurs even in the debugger, I was able to get a stack trace from our Sentry crash handler. See below It seems that calling LoadRequest from the mainthread fixes the issue but I don't understand why, theres no documentation to suggest this must be done. Any ideas? Below is the stack trace I got from Sentry: WebKit +0x0054e00 WebKit::allDataStores WebKit +0x0bf34f4 WebKit::NetworkProcessProxy::preconnectTo WebKit +0x0acef64 WebKit::WebPageProxy::preconnectTo WebKit +0x0b0d92c WTF::Detail::CallableWrapper::call WebKit +0x0ab6cf8 WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle WebKit +0x0ab84dc WebKit::WebPageProxy::loadRequestWithNavigationShared WebKit +0x0ab7adc WebKit::WebPageProxy::loadRequest WebKit +0x05d0704 -[WKWebView loadRequest:] Grid3iOS +0x5240944 xamarin_dyn_objc_msgSendSuper In App Grid3iOS +0x187dec4 wrapper_managed_to_native_ObjCRuntime_Messaging_NativeHandle_objc_msgSendSuper_NativeHandle_intptr_intptr_ObjCRuntime_NativeHandle In App Grid3iOS +0x512fac4 Microsoft_iOS_WebKit_WKWebView_LoadRequest_Foundation_NSUrlRequest (WKWebView.g.cs:572)

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.

An app with a UIToolbar pinned to the bottom of a view controllers view extends to the screen edge (behind the safe area) when run on iOS 18.X but not iOS 26. This UIToolbar is set as constrained to the safeAreaLayoutGuide with the following constraints. self.view.addConstraints([ bottomToolbar.leadingAnchor.constraint(equalTo: self.view.leadingAnchor), bottomToolbar.trailingAnchor.constraint(equalTo: self.view.trailingAnchor), bottomToolbar.bottomAnchor.constraint(equalTo: self.view.safeAreaLayoutGuide.bottomAnchor), bottomToolbar.heightAnchor.constraint(greaterThanOrEqualToConstant: 44.0) ]) This is especially noticeable when the UIToolbar background color differs from the view background color. This occurs on iOS 26 beta 6, app built with Xcode 26 beta 5. I've posted a Feedback FB19664903 including a minimal Xcode workspace that reproduces this issue. Anyone suggestions would be appreciated ... this definitely seems like a regression.

When adding a glass effect to my UIControl: let effectView = UIVisualEffectView() let glassEffect = UIGlassEffect() glassEffect.isInteractive = true effectView.effect = glassEffect effectView.cornerConfiguration = .capsule() addSubview(effectView) effectView.snp.makeConstraints { $0.edges.equalToSuperview() } effectView.contentView.addSubview(stackView) for subview in effectView.subviews { subview.backgroundColor = .clear } self.effectView = effectView I find that I get this visual effect: These controls are the only view within a UICollectionViewCell. Nothing in the hierarchy of the collectionview to the control has a background color. The grey background only seems to appear when I place the glass effect. Without the glass effect, there is no grey shading.

When using a custom keyboard set via UIResponder.inputView, a gap appears between the text field and the custom keyboard after rotating from portrait to landscape and back to portrait. On a portrait screen, when switching to a custom keyboard: The input field at the top and the custom keyboard below it appear normally, with no empty space in between. When I rotate from portrait to landscape, a gap appears in the middle.

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!

An iOS app has a UINavigationController with a UINavigationBar that is non-translucent (e.g. black). When performing a push (or pop) to navigate to or from another UIViewController the UIBarButtonItems on the navigation bar are flashing a white background. With a dark navigation bar this is very noticeable and not desirable. This only occurs when run on iOS 26 and is related to Liquid Glass I've created FB19660024 with a minimal Xcode workspace to reproduce, along with a video showing the behavior. This is a cosmetic bug, not affecting functionality, but is a very undesirable effect on apps with dark and non-translucent navigation bars. Has anyone else seen this and found a workaround?

This issue was in the first iOS 26 beta and it still there with Xcode 26 beta 6 (17A5305f). Feedback is FB18581605 and contains sample project to reproduce the issue. I assign a target and action to a UISlider for the UIControl.Event.valueChanged value: addTarget(self, action: #selector(sliderValueDidChange), for: .valueChanged) Here’s the function. @objc func sliderValueDidChange(_ sender: UISlider, event: UIEvent) { print(event) } When printing the event value, there is a crash. When checking the event value with lldb, it appears uninitialized.

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!