When I set up UIScrollEdgeElementContainerInteraction for a UITableView in iOS 26 like this:
let interaction = UIScrollEdgeElementContainerInteraction()
interaction.scrollView = tableView
interaction.edge = .top
viewHeader.addInteraction(interaction)
the section header remains displayed above the gradient glass effect, but the cells do not exhibit this issue.
Visually, the cells appear beneath the glass layer, while the header appears above the glass layer—even though, in reality, both the header and the cells are positioned below the glass layer in the view hierarchy.
UIKit
RSS for tagConstruct and manage graphical, event-driven user interfaces for iOS or tvOS apps using UIKit.
Posts under UIKit tag
200 Posts
Sort by:
Post
Replies
Boosts
Views
Activity
When I set up UIScrollEdgeElementContainerInteraction for a UITableView in iOS 26 like this:
let interaction = UIScrollEdgeElementContainerInteraction()
interaction.scrollView = tableView
interaction.edge = .top
viewHeader.addInteraction(interaction)
the section header remains displayed above the gradient glass effect, but the cells do not exhibit this issue.
I am observing an unexpected behavior with external keyboard input on iOS.
When I press Command + key (e.g., ⌘ + J) while a UITextView is focused, the system invokes
pressesBegan(_ presses: Set<UIPress>, with event: UIPressesEvent?)
twice:
-> Once with the key press event without any modifier flags.
-> A second time with the same key event but including the Command modifier flag.
This behavior is checked on an iPad with an external keyboard.
Additionally, I noticed that textView(_:shouldChangeTextIn:replacementText:) is not invoked in this case, even if I call super.pressesBegan for event propagation.
Questions:
Is it expected that pressesBegan fires twice for a Command + key combination?
If so, what is the recommended way to distinguish between these two invocations?
Should the UITextView delegate methods (like shouldChangeTextIn) be triggered for such key combinations, or is this by design?
I have an app where the user can choose if the dark / light mode is enabled automatically during the night / day (dusk and dawn times are calculated according to to the date and location of the user).
I also have an UITabBarController, with two tabs which have a GMSMapView (Google Map View from their SDK), and three tabs with UITableViews.
I have noticed that when the automatic change of dark / light mode is performed from dark to light mode, and the user is in a tab with GMSMapView, the tabBar does not change to light model, it remains in dark mode.
I perform the switch by setting the self.window.overrideUserInterfaceStyle of the UIWindow of the UIScene. All the views change to light mode, including the navigation bar, but not the tab bar. If I move between the tabs with GMSMapView, the tabBar stays in dark mode. As soon as I move to a tab which contains a UITableView, the tabBar switches to light mode.
If the switch to light mode is performed while the user is in tab with the UITableViews, the tabBar switches to light mode immediately, as expected. When moving to the tabs with the GMSMapViews, the tabBar stays in light mode, also as expected.
I have also noticed the same problem in CarPlay, in CPMapTemplate (with a UIViewController whose view is GMSMapView), in the buttons with are set with the property “mapButtons”, and with the panning buttons. When the switch from dark mode to light mode is performed by setting the self.window.overrideUserInterfaceStyle of the UIWindow of CarPlay scene, the mapButtons keeps the glyphs in white, and set the background of the buttons to almost white, so the glyphs are barely visible unless you put png images on them instead of SF Symbols.
With the panning buttons there is not workaround, since you cannot set custom images for the panning buttons. This happens even if the panning buttons are not being displayed when the switch is performed to light mode, and you enable them later.
Is this a bug? Why does this only happen with view over GMSMapView (Google Maps view for a map from their SDK)? Can you think of any viable workaround?
Thank you.
I have an app that displays a MapView. While I am in light mode everything is fine. I can scroll around the map and my overlays (made by UIVisualEffectView containing an UIGlassEffect) stay light and look well!
As soon as I change my phone to dark mode, depending on what's underneath the buttons (a light residential area or darker wooded areas) some of my buttons change color. But not all, only where it's supposedly lighter or darker underneath. This makes my whole UI look strange. Some buttons bright, some dark.
Is there a way to lock a "color" or interfaceStyle to the effects-view? In light mode everything is fine, but in dark mode it just looks super strange.
import UIKit
class KeyboardViewController: UIInputViewController {
// MARK: - Properties
private var keyboardView: KeyboardView!
private var heightConstraint: NSLayoutConstraint!
private var hasInitialLayout = false
// 存储系统键盘高度和动画参数
private var systemKeyboardHeight: CGFloat = 300
private var keyboardAnimationDuration: Double = 0.25
private var keyboardAnimationCurve: UIView.AnimationOptions = .curveEaseInOut
// MARK: - Lifecycle
override func viewDidLoad() {
super.viewDidLoad()
setupKeyboard()
}
override func viewWillAppear(_ animated: Bool) {
super.viewWillAppear(animated)
// 在视图显示前更新键盘高度,避免闪动
if !hasInitialLayout {
hasInitialLayout = true
}
}
override func viewDidAppear(_ animated: Bool) {
super.viewDidAppear(animated)
}
// MARK: - Setup
private func setupKeyboard() {
// 创建键盘视图
keyboardView = KeyboardView()
keyboardView.translatesAutoresizingMaskIntoConstraints = false
view.addSubview(keyboardView)
// 设置约束 - 确保键盘贴紧屏幕底部
NSLayoutConstraint.activate([
keyboardView.leftAnchor.constraint(equalTo: view.leftAnchor),
keyboardView.rightAnchor.constraint(equalTo: view.rightAnchor),
keyboardView.bottomAnchor.constraint(equalTo: view.bottomAnchor)
])
// 设置初始高度约束(使用系统键盘高度或默认值)
let initialHeight = systemKeyboardHeight
heightConstraint = keyboardView.heightAnchor.constraint(equalToConstant: initialHeight)
heightConstraint.isActive = true
}
// MARK: - Layout Events
override func viewDidLayoutSubviews() {
super.viewDidLayoutSubviews()
}
override func viewSafeAreaInsetsDidChange() {
super.viewSafeAreaInsetsDidChange()
}
// MARK: - 键盘高度请求
// 这个方法可以确保键盘扩展报告正确的高度给系统
override func updateViewConstraints() {
super.updateViewConstraints()
// 确保我们的高度约束是最新的
if heightConstraint == nil {
let height = systemKeyboardHeight > 0 ? systemKeyboardHeight : 216
heightConstraint = NSLayoutConstraint(
item: self.view!,
attribute: .height,
relatedBy: .equal,
toItem: nil,
attribute: .notAnAttribute,
multiplier: 0.0,
constant: height
)
heightConstraint.priority = UILayoutPriority(999)
view.addConstraint(heightConstraint)
} else {
let height = systemKeyboardHeight > 0 ? systemKeyboardHeight : 216
heightConstraint.constant = height
}
}
}
// MARK: - Keyboard View Implementation
class KeyboardView: UIView {
private var keysContainer: UIStackView!
override init(frame: CGRect) {
super.init(frame: frame)
setupView()
}
required init?(coder: NSCoder) {
super.init(coder: coder)
setupView()
}
private func setupView() {
backgroundColor = UIColor(red: 0.82, green: 0.84, blue: 0.86, alpha: 1.0)
// 创建按键容器
keysContainer = UIStackView()
keysContainer.axis = .vertical
keysContainer.distribution = .fillEqually
keysContainer.spacing = 8
keysContainer.translatesAutoresizingMaskIntoConstraints = false
addSubview(keysContainer)
// 添加约束 - 确保内容在安全区域内
NSLayoutConstraint.activate([
keysContainer.topAnchor.constraint(equalTo: safeAreaLayoutGuide.topAnchor, constant: 8),
keysContainer.leftAnchor.constraint(equalTo: safeAreaLayoutGuide.leftAnchor, constant: 8),
keysContainer.rightAnchor.constraint(equalTo: safeAreaLayoutGuide.rightAnchor, constant: -8),
keysContainer.bottomAnchor.constraint(equalTo: safeAreaLayoutGuide.bottomAnchor, constant: -8)
])
// 添加键盘行
}
}
We are using a column style split view controller as root view of our app and in iOS26 the navigation titles of primary and supplementary view controllers are not visible and secondary view controller title is displayed in supplementary column.
Looks the split view hidden all the child view controllers title and shown the secondary view title as global in macCatlayst. The right and left barbutton items are showing properly for individual view controllers.
Facing this weird issue in iOS26 betas. The secondary navigation title also visible only when WindowScene,titlebar.titleVisibility is not hidden.
Kindly suggest the fix for this issue as we can't use the secondary view navigation title for showing supplementary view's data. The issue not arises in old style split views or when the split view embedded in another splitView.
Refer the sample code and attachment here
let splitView = UISplitViewController(style: .tripleColumn)
splitView.preferredDisplayMode = .twoBesideSecondary
splitView.setViewController(SplitViewChildVc(title: "Primary"), for: .primary)
splitView.setViewController(SplitViewChildVc(title: "Supplementary"), for: .supplementary)
splitView.setViewController(SplitViewChildVc(title: "Secondary"), for: .secondary)
class SplitViewChildVc: UIViewController {
let viewTitle: String
init(title: String = "Default") {
self.viewTitle = title
super.init(nibName: nil, bundle: nil)
}
override func viewDidLoad() {
super.viewDidLoad()
self.title = viewTitle
self.navigationItem.title = viewTitle
if #available(iOS 26.0, *) {
navigationItem.subtitle = "Subtitle"
}
let leftbutton = UIBarButtonItem(barButtonSystemItem: .cancel, target: nil, action: nil)
navigationItem.leftBarButtonItem = leftbutton
let rightbutton = UIBarButtonItem(barButtonSystemItem: .add, target: nil, action: nil)
navigationItem.rightBarButtonItem = rightbutton
}
}
I'm looking for a way to implement Liquid Glass effect in a Text, and I have issues.
If I want to do gradient effect in a Text, no problem, like below.
Text("Liquid Glass")
.font(Font.system(size: 30, weight: .bold))
.multilineTextAlignment(.center)
.foregroundStyle(
LinearGradient(
colors: [.blue, .mint, .green],
startPoint: .leading,
endPoint: .trailing
)
)
But I cannot make sure that I can apply the .glassEffect with .mask or .foregroundStyle. The Glass type and Shape type argument looks like not compatible with the Text shape itself.
Any solution to do this effect on Text ?
Thanks in advance for your answers.
Hello,
I hope you're all doing well! I'm currently working on integrating new iOS 26 features into my app, and so far, the process has been really exciting. However, I've encountered an issue when updating the badge of a UIBarButtonItem, and I’m hoping to get some insights or suggestions.
The app has two UIViewController instances in the navigation stack, each containing a UIBarButtonItem.
On the first controller, the badge is set to 1, and on the second, the badge is set to 2. In the second controller, there is a "Reset" button that sets the badge of the second controller to nil.
However, when I tap the "Reset" button, instead of setting the badge to nil, it sets the value to 1.
I would appreciate any ideas or suggestions on how to solve this problem. Maybe I am using the badge API incorrectly.
Thank you!
class ViewController: UIViewController {
var cartButtonItem: UIBarButtonItem!
override func viewDidLoad() {
super.viewDidLoad()
configureNavigationItem()
}
func configureNavigationItem() {
cartButtonItem = UIBarButtonItem(image: UIImage(resource: .cartNavBar), style: .plain, target: self, action: #selector(showCartTab))
cartButtonItem.tintColor = UIColor.systemBlue
cartButtonItem.badge = .count(1)
navigationItem.rightBarButtonItem = cartButtonItem
}
@objc func showCartTab() {
// Add second view controller in navigation stack
performSegue(withIdentifier: "Cart", sender: nil)
}
}
class CartViewController: UIViewController {
var cartButtonItem: UIBarButtonItem!
override func viewDidLoad() {
super.viewDidLoad()
configureNavigationItem()
}
func configureNavigationItem() {
cartButtonItem = UIBarButtonItem(image: UIImage(resource: .cartNavBar), style: .plain, target: nil, action: nil)
cartButtonItem.tintColor = UIColor.systemBlue
cartButtonItem.badge = .count(2)
navigationItem.rightBarButtonItem = cartButtonItem
}
func updateBadge() {
cartButtonItem.badge = nil
}
@IBAction func resetButtonPressed(_ sender: Any) {
updateBadge()
}
}
What is the recommended way to obtain the concentric corner radius for views within grouped UICollectionView cells?
In the most basic example, a UICollectionView with one section and one cell, we observe the cell takes almost the shape of a capsule, but it is indeed not a capsule.
What is the way to obtain the radius of the grouped area from within the cell or its registration? I would like to layer elements on top that are concentric to the cell's clip shape.
I've tried using custom views with .concentric UICornerConfigurations, setting .cornerConfiguration on the cell and on a custom backgroundView and I've even tried obtaining the .effectiveRadius of the cell after layout (returns 0.0). As of Xcode 26.0 Beta 7, nothing works.
This seems like a huge omission; what am I missing here?
Is the Cancel button intentionally removed from UISearchBar (right side)?
Even when using searchController with navigationItem also.
showsCancelButton = true
doesn’t display the cancel button.
Also:
When tapping the clear ("x") button inside the search field, the search is getting canceled, and searchBarCancelButtonClicked(_:) is triggered (Generally it should only clear text, not cancel search).
If the search text is empty and I tap outside the search bar, the search is canceled.
Also when I have tableview in my controller(like recent searches) below search bar and if I try to tap when editing started, action is not triggered(verified in sample too). Just cancellation is happening.
In a split view controller, if the search is on the right side and I try to open the side panel, the search also gets canceled.
Are these behaviors intentional changes, beta issues, or are we missing something in implementation?
I’m trying to understand the exact role of the return value in the UITextFieldDelegate method textFieldShouldReturn(_:).
From my experiments in Xcode, I observed:
Returning true vs false does not seem to cause any visible difference (e.g., the keyboard does not automatically dismiss either way).
I know that in shouldChangeCharactersIn returning true allows the system to insert the character, and returning false prevents it. That’s clear.
For textFieldShouldReturn, my current understanding is that returning true means “let the OS handle the Return press,” and returning false means “I’ll handle it myself.”
My confusion: what is it that the OS actually does when it “handles” the Return press?
Does UIKit do anything beyond calling this delegate method?
If the system is supposed to dismiss the keyboard when returning true, why doesn’t it happen automatically?
I’d appreciate clarification on the expected use of this return value — specifically, what default behavior the system performs (if any) when we return true.
Thanks!
Note: in this post I discuss sceneDidEnterBackground/WillResignActive but I assume any guidance provided would also apply to the now deprecated applicationDidEnterBackground/applicationWillResignActive and SwiftUI's ScenePhase (please call out if that's not the case!).
A common pattern for applications with sensitive user data (banking, health, private journals, etc.) is to obsurce content in the app switcher. Different apps appear to implement this in two common patterns. Either immediately upon becoming inactive (near immediately upon moving to task switcher) or only upon becoming backgrounded (not until you've gone to another app or back to the home screen).
I’d like to make sure we’re aligned with Apple’s intended best practices and am wondering if an anti-pattern of using sceneWillResignActive(_:) may be becoming popularized and has minor user experience inconviences (jarring transitions to the App Switcher/Control Center/Notification Center and when the system presents alerts.)
Our applications current implementation uses sceneDidEnterBackground(_:) to obscure sensitive elements instead of sceneWillResignActive(_:), based on the recomendations from tech note QA1838 and the documentation in sceneDidEnterBackground(_:)
... Shortly after this method [sceneWillEnterBackground] returns, UIKit takes a snapshot of your scene’s interface for display in the app switcher. Make sure your interface doesn’t contain sensitive user information.
Both QA1838 and the sceneDidEnterBackground documentation seem to indicate backgrounding is the appropriate event to respond to for this pattern but I am wondering if "to display in the app switcher" may be causing confusion since your app can also display in the app switcher upon becoming inactive and if some guidance could be added to sceneWillResignActive that it is not nesscary to obsure content during this state (if that is true).
In our testing, apps seems to continue to play any in-progress animations when entering the app switcher from the application (inactive state), suggesting no snapshot capture. We also discovered that it appears sceneWillResignActive not always be called (it usually is) but occasionally you can swipe into the app switcher without it being called but that sceneDidEnterBackground is triggered more consistently.
It appears the Wallet app behaves as I'd expect with sceneDidEnterBackground on card details screens as well (ejecting you to the card preview if you switch apps) but will keep you on the card details screen upon becoming inactive.
Questions:
Is sceneDidEnterBackground(_:) still Apple’s recommended place to obscure sensitive content, or should apps handle this earlier (e.g. on inactive)?
Would it actually be recommended against using sceneWillResignActive active given it seems to not be gauranteed to be called?
Ask:
Provide an updated version of QA1838 to solidfy the extrapolation of applicationDidEnterBackground -> sceneDidEnterBackground
Consider adding explicit guidance to sceneWillResignActive documentation
Hi there. Our designer is designing our app in Figma with the navigation element with compact size navigation bar, and large title. I couldn't find an API to actually configure the nav bar to be compact while keeping the large title enabled. Figma uses the libraries provided by Apple so it's weird I can't find such configuration in iOS26.
I'm adding a screenshot of the options in Figma.
First option is: Large size & large text.
The one our designer is using is compact size & large text.
I need more time to adapt to the new iOS 26 UI, so I set the "UIDesignRequiresCompatibility" attribute to "Yes."
This works, but now all large titles are not aligned with the content.
Below you can see an example, but I have the issue with all large titles.
All good on iOS 18.
Does anyone have an idea why and how can i fix it?
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.
I’ve been testing out PaperKit from beta 1 up until 3, then took a break and on my return at beta 7 I find that the .drawing property of the PaperMarkup data model has been removed, i.e. a PKDrawing can no longer be added / modified on PaperKit. Also, the shape recognition feature seems to have been removed.
I see this as a tremendous drawback. I filed feedback already: FB19893338
Please bring it back.
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.
This is probably abusing the system more than it should be but maybe it is somehow possible. I have:
An objective-C based storyboard iPad OS app. I'm beginning to adopt SwiftUI.
I have a hosting controller with a content view that has a lazygrid of cards, which have an NSManagedObject for data. On tapping a card, a detail view opens, if in multi-tasking, a new window, if not, pushing the navigation controller (this detail view still exists in UIKit/ObjC, and is handled by sending a notification with the ObjectID, which then triggers a storyboard segue to the detail.)
I have zoom transitions on all my things. They work great in Obj.C, especially now with the bar button source.
On my iPhone target, I still have an old tableview, and I'm able to zoom properly - if someone changes the detail view's managed object (through a history menu), the zoom context looks up where the tableview is, and scrolls to it while popping.
I'd like to somehow do this on the lazygrid - first) to just have an individual card be the zoom source, it should be able to know what the source view is to say in the prepareForSegue method just to zoom at all. and second) if the detail has changed the current ObjectID (which gets passed around as a notification), to somehow scroll the lazygrid to the right object before popping.
I've looked at https://developer.apple.com/tutorials/SwiftUI/interfacing-with-uikit but this seems like swiftUI is the host. I have it the other way around, uikit hosting swiftUI pushing uikit.
TIA for any pointers