Description: 1. When initiating the print flow via UIPrintInteractionController, and no printer is initially connected, iOS displays all possible paper sizes in the paper selection UI. However, if a printer connects in the background after this view is shown, the list of paper sizes does not automatically refresh to reflect only the options supported by the connected printer. 2. If the user selects an incompatible paper size (one not supported by the printer that has just connected), the app crashes due to an invalid configuration. Steps to Reproduce: Launch the app and navigate to the print functionality. Tap the Print button to invoke UIPrintInteractionController. At this point, no printer is yet connected. iOS displays all available paper sizes. While the paper selection UI is visible, the AirPrint-compatible printer connects in the background. Without dismissing the controller, the user selects a paper size (e.g., one that is not supported by the printer). The app crashes. Expected Result: App should not crash Once the printer becomes available (connected in the background), the paper size options should refresh automatically. The list should be filtered to only include sizes that are compatible with the connected printer. This prevents the user from selecting an invalid option, avoiding crashes. Actual Result: App crashes The paper size list remains unfiltered. The user can still select unsupported paper sizes. Selecting an incompatible option causes the app to crash, due to a mismatch between UI selection and printer capability. Demo App Crash : https://drive.google.com/file/d/19PV02wzOJhc2DYI6kAe-uxHuR1Qg15Bu/view?usp=sharing Apple Files App Crash: https://drive.google.com/file/d/1flHKuU_xaxHSzRun1dYlh8w7nBPJZeRb/view?usp=sharing

On iPad running iOS 26, UIKeyboardType.decimalPad sometimes appears as a floating keypad (compact panel) instead of the docked, full-width keyboard. Our app attaches a custom toolbar via inputAccessoryView, so the floating keypad hides the toolbar and breaks the flow. We’d like to opt out of the floating keypad or force the keyboard to remain docked when a toolbar is present. Environment Device: iPad (multiple models) OS: iPadOS 26.0 App type: UIKit Field: UITextField with keyboardType = .decimalPad We present a custom toolbar via inputAccessoryView Expected Docked (full-width) keyboard so the inputAccessoryView toolbar is visible and sized correctly. Actual A floating decimal keypad appears and covers content; our accessory toolbar isn’t visible/attached to it. Why this matters Our toolbar contains required domain actions (Done/Next, Previous). When the keypad floats, the user loses these controls. Questions Is there a supported way to opt out of the floating numeric keypad on iPad when using decimalPad? Is there an API/trait to prefer docked keyboard (e.g., when an inputAccessoryView is present)?

I have an App which supports multiple windows on the iPad. The App can receive URLs from other Apps (via application.openURL()) and also files via "share sheet" (via UIActivityViewController). When receiving a URL from another App the delegate method scene(_ scene: UIScene, openURLContexts URLContexts: Set) will be called on an existing UIScene, however when a file is received through the share sheet from another App, a new UIScene is created and therefore also a new window (eg the delegates application(_ application: UIApplication, configurationForConnecting connectingSceneSession: UISceneSession, options: UIScene.ConnectionOptions) and scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) are called). In both cases I do get the URL and file just fine, however I do not want to get new UIScenes and windows created when receiving a file via share sheet. How can I prevent to get a new UIScene or window? The received files should be used in the existing windows and should not create new ones.

I'm working on an AppIcon selector and would like to do something like UIImage(named: "AppIcon-Alternate") to present the icon for the user to choose using the new IconComposer icons. I've done a fair bit of research on this and it looks like this used to be possible (prior to .icon) with workarounds that were later 'fixed' / removed (appending 60x60 to the icon name). The only 'solution' seems to be bundling the exported images into the app itself but this seems like a terrible idea as it massively bloats the app. Assuming we export from the new IconComposer tool and want to include dark mode that's roughly 3MB per icon which is absolutely shocking bloat and so a terrible solution. Looking into the app the Assets.car actually generates png files for these alternate icons. These are in the json as "MultiSized Image" assets. Interestingly using UIImage(named: is actually attempting to load these but fails to resolve an kCSIElementSignature. Also the OS alert when switching alternate icon shows a preview of the icon so this must be privately possible and using Asset Catalog Tinkerer I'm able to see these pngs. This feels like broken API; I'd guess the new icon format is not correctly generating the entry in the Asset.car to link the generated pngs for usage with UIImage(named:) API. Does anyone have pointers for this? This feels like a developer API afterthought or bug but is it intentional? Edit: I've submitted feedback for this FB20341182.

In the WWDC 2025 session "Build a UIKit app with the with the new design", at the 23:22 mark, the presenter says: And finally, when you no longer need the glass on screen animate it out by setting the effect to nil. The video shows a UIVisualEffectView whose effect is set to a UIGlassEffect animating away as its effect is set to nil. But when I do this in my app (or a sample app), setting effect to nil does not remove the glass appearance. Is this expected? Is the video out of date? Or is this a bug?

Scenario: Typing Chinese Zhuyin “ㄨㄤ” and then selecting the candidate word “王”. On iOS 18, the delegate (textField:shouldChangeCharactersInRange:replacementString:) is called with: range: {0, 2} replacementString: "王" On iOS 26, the delegate (textField:shouldChangeCharactersInRanges:replacementString:) instead provides: ranges: [{2, 0}] replacementString: "王" This results in inconsistent text input handling compared to earlier system versions. Implement: Limit user input to a maximum of 100 Chinese characters. - (BOOL)textField:(UITextField *)textField shouldChangeCharactersInRange:(NSRange)range replacementString:(NSString *)string { if ([textField markedTextRange]) { return YES; } NSString *changedString = [textField.text stringByReplacingCharactersInRange:range withString:string]; if (changedString.length > 100) { return NO; } return YES; } Questions: Is this an intentional change in iOS 26? If intentional, what is the recommended way to handle such cases in order to support both iOS 18 and iOS 26 consistently?

How does one know the fitting width of a UIDatePicker in a selector hooked up with UIControlEventValueChanged? By fitting width, I mean the width of the grey background rounded box displayed with the date -- I need to get the width of that whenever the date is changed.

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) ]) // 添加键盘行 } }

Summary: When running our iPad app on macOS (“Designed for iPad”), invoking UIPrintInteractionController intermittently fails to show a working print sheet. The same code works reliably on iPad or iOS devices and also on macOS pre 26. This regression started after updating to macOS Tahoe Version 26.0 (25A354) Steps to Reproduce: Launch the attached minimal sample on macOS (Designed for iPad). Tap “Print plain text” Expected Results: The print panel should appear and discover AirPrint printers reliably, as on iPad/iOS or previous mac versions. Actual Results: On macOS, the panel fails to appear. Mac version: macOS Tahoe 26.0 (25A354) xCode version: 26.0 (17A324) Sample Reproduction Code: struct ContentView: View { var body: some View { Button("Print plain text") { printPlainText() } .buttonStyle(.borderedProminent) .padding() } func printPlainText() { let text = "This is just a sample print" guard UIPrintInteractionController.isPrintingAvailable else { NSLog("Printing not available on this device") return } let info = UIPrintInfo(dictionary: nil) info.outputType = .general info.jobName = "Plain Text" let formatter = UISimpleTextPrintFormatter(text: text) formatter.perPageContentInsets = UIEdgeInsets(top: 36, left: 36, bottom: 36, right: 36) let ctrl = UIPrintInteractionController.shared ctrl.printInfo = info ctrl.printFormatter = formatter DispatchQueue.main.async { ctrl.present(animated: true) { _, completed, error in if let error { NSLog("Print error: \(error.localizedDescription)") } else { NSLog(completed ? "Print completed" : "Print cancelled") } } } } } Also I have added the following values to info.plist: <key>NSLocalNetworkUsageDescription</key> <string>This app needs local network access to discover AirPrint printers.</string> <key>NSBonjourServices</key> <array> <string>_ipp._tcp.</string> <string>_ipps._tcp.</string> <string>_printer._tcp.</string> </array>

When trying to use a UISearchController setup with a UISearchBar that has scope buttons, the search controller's scopeBarActivation property is set to .onSearchActivation, the navigation item's preferredSearchBarPlacement property is set to .integrated. or .integratedButton, and the search bar/button appears in the navigation bar, then the scope buttons never appear. But space is made for where they should appear. Some relevant code in a UIViewController shown as the root view controller of a UINavigationController: private func setupSearch() { let sc = UISearchController(searchResultsController: UIViewController()) sc.delegate = self sc.obscuresBackgroundDuringPresentation = true // Setup search bar with scope buttons let bar = sc.searchBar bar.scopeButtonTitles = [ "One", "Two", "Three", "Four" ] bar.selectedScopeButtonIndex = 0 bar.delegate = self // Apply the search controller to the nav bar navigationItem.searchController = sc // BUG - Under iOS/iPadOS 26 RC, using .onSearchActivation results in the scope buttons never appearing at all // when using integrated placement in the nav bar. // Ensure the scope buttons appear immediately upon activating the search controller sc.scopeBarActivation = .onSearchActivation // This works but doesn't show the scope buttons until the user starts typing - that's too late for my needs //sc.scopeBarActivation = .automatic if #available(iOS 26.0, *) { // Under iOS 26 put the search icon in the nav bar - same issue for .integrated and .integratedButton navigationItem.preferredSearchBarPlacement = .integrated // .integratedButton // My toolbar is full so I need the search in the navigation bar navigationItem.searchBarPlacementAllowsToolbarIntegration = false // Ensure it's in the nav bar } else { // Under iOS 18 put the search bar in the nav bar below the title navigationItem.preferredSearchBarPlacement = .stacked } } I need the search bar in the navigation bar since the toolbar is full. And I need the scope buttons to appear immediately upon search activation. This problem happens on any real or simulated iPhone or iPad running iOS/iPadOS 26 RC.

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.

Dear Apple Support, We are encountering an issue with deep linking on iOS 26 when using Safari and App Store redirection. Below are the detailed steps to reproduce the problem: The app is not installed on the device. User clicks on a Branch link: For example:- https://qewed.app.link/99u88ef9f?uuid=88dbwh5ubd4b Safari opens and displays the fallback page. User taps on “Get the App”, which navigates to the App Store. User installs and opens the app. Expected Behavior:
The app should receive the Branch link parameters (in this case, uuid=88dbwh5ubd4b) upon first open. Actual Behavior:
The app opens successfully, but the uuid parameter is not passed to the app. This issue seems specific to the Safari → App Store → App flow on iOS 26, as other flows behave correctly. Could you please advise whether this is a known issue or if there are recommended adjustments on our side to ensure parameters are consistently delivered after App Store redirection? Note: We are using Branch SDK version 3.11.0 (Cocoapods dependency) Thank you for your assistance.

Hey there, Link to the sample project: https://github.com/dev-loic/AppleSampleScrolling Context We are working on creating a feed of posts in SwiftUI. So far, we have successfully implemented a classic feed that opens from the top, with bottom pagination — a standard use case. Our goal, however, is to allow the feed to open from any post, not just the first one. For example, we would like to open the feed directly at the 3rd post and then trigger a network call to load elements both above and below it. Our main focus here is on preserving the scroll position while opening the screen and waiting for the network call to complete. To illustrate the issue, I created a sample project (attached) with two screens: MainView, which contains buttons to open the feed in different states. ScrollingView, which initially shows a single element, simulates a 3-second network call, and then populates with new data depending on which button was tapped. I am currently using Xcode 26 beta 6, but I can also reproduce this issue on Xcode 16.3. Tests on sample project I click on a button and just wait the 3 seconds for the call. In this scenario, I expect that the “focused item” stays at the exact same place on the screen. I also expect to see items below and above being added. Simulator iPhone 16 / iOS 18.4 with itemsHeight = 100 position = 0, 1, 2, 3 ⇒ works as expected position = 4, 5, 6, 7, 8, 9 ⇒ scroll is reset to the top and we loose the focused item Simulator iPhone 16 / iOS 18.4 with itemsHeight = 500 position = 0, 1, 2, 3, 4 ⇒ works as expected position = 5, 6, 7 ⇒ I have a glitch (the focused element moves on the screen) but the focused element is still visible position = 8, 9 ⇒ scroll is reset to the top and we loose the focused item Simulator iPhone 16 / iOS 26 with itemsHeight = 100 or 500 position = 0, 1, 2, 3, 4 ⇒ works as expected position = 5, 6, 7, 8, 9 ⇒ I have a glitch (the focused element moves on the screen) but the focused element is still visible Device iPhone 15 / iOS 26 with itemsHeight = 100 position = 0, 1, 2, 3, 4 ⇒ works as expected position = 5, 6, 7, 8, 9 ⇒ I have a glitch (the focused element moves on the screen) but the focused element is still visible Device iPhone 15 / iOS 26 with itemsHeight = 500 position = 0, 1, 2, 3 ⇒ works as expected position = 4, 5, 6, 7, 8, 9 ⇒ I have a glitch (the focused element moves on the screen) but the focused element is still visible Not any user interaction Moreover, in this scenario, the user does not interact with the screen during the simulated network call. Regardless of the situation, if the ScrollView is in motion, its position always resets to the top. This behavior prevents us from implementing automatic pagination when scrolling upward, which is ultimately our goal. My conclusion so far As far as I know it seems not possible to have both keeping scroll possible and upward automatic pagination using a SwiftUI LazyVStack inside a ScrollView. This appears to be standard behavior in messaging apps or other feed-based apps, and I’m wondering if I might be missing something. Thank you in advance for any guidance you can provide on this topic. Cheers

Hello, I have been receiving crash reports on iOS 26 related to a view containing a UITextField. Although I have not been able to reproduce the issue locally and the exact reproduction steps are unknown, the call stack suggests the crash may be related to language or input method changes. If anyone has encountered a similar crash on iOS 26 or has any insights regarding language/input-related issues impacting UITextField behavior, your help would be greatly appreciated. The call stack from the reports is attached below. Exception NSInvalidArgumentException -[__NSPlaceholderArray initWithObjects:count:] attempt to insert nil object from objects[1] Fatal Exception: NSInvalidArgumentException 0 CoreFoundation 0xc98c8 __exceptionPreprocess 1 libobjc.A.dylib 0x317c4 objc_exception_throw 2 CoreFoundation 0xe1d7c -[__NSPlaceholderArray initWithObjects:count:] 3 CoreFoundation 0x1485d0 +[NSArray arrayWithObjects:count:] 4 UIKitCore 0xfc4d44 -[UIInlineInputSwitcher updateInputModes:withHUD:] 5 UIKitCore 0xfc4fe0 -[UIIndicatorInputSwitcher switchMode:withHUD:withDelay:] 6 UIKitCore 0xfc31d4 -[UIInputSwitcher showsLanguageIndicator:] 7 UIKitCore 0xa16dc8 __140-[_UIKeyboardStateManager _setupDelegate:delegateSame:hardwareKeyboardStateChanged:endingInputSessionIdentifier:force:delayEndInputSession:]_block_invoke_4 8 libdispatch.dylib 0x1abc _dispatch_call_block_and_release 9 libdispatch.dylib 0x1b7cc _dispatch_client_callout 10 libdispatch.dylib 0x38af0 _dispatch_main_queue_drain.cold.5 11 libdispatch.dylib 0x10ea8 _dispatch_main_queue_drain 12 libdispatch.dylib 0x10de4 _dispatch_main_queue_callback_4CF 13 CoreFoundation 0x6b520 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ 14 CoreFoundation 0x1dd14 __CFRunLoopRun 15 CoreFoundation 0x1cc44 _CFRunLoopRunSpecificWithOptions 16 GraphicsServices 0x1498 GSEventRunModal 17 UIKitCore 0xaa6d8 -[UIApplication _run] 18 UIKitCore 0x4ec24 UIApplicationMain Thank you!

When preparing the app for the new iOS 26, I came across an unpleasant design decision. Specifically, in the new design, the keyboard has rounded corners, under which the system background is visible. And here we have only two options, a light/dark background, which breaks all keyboard calls in the application. Can you tell me if there is any way around this problem?

I'm using UIDocumentPickerViewController to open a url. Works fine in debug mode but version on the App Store is failing. Code to create the document picker is like: NSArray *theTypes = [UTType typesWithTag:@"docxtensionhere" tagClass:UTTagClassFilenameExtension conformingToType:nil]; UIDocumentPickerViewController *documentPicker = [[UIDocumentPickerViewController alloc]initForOpeningContentTypes:theTypes]; documentPicker.delegate = self;   [self presentViewController:documentPicker animated:YES completion:nil]; So in debug mode this is all gravy. -documentPicker:didPickDocumentsAtURLs: passes back a URL and I can read the file. In release mode I get a URL but my app is denied access to read the file. After inspecting some logging it appears the sandbox is not granting my app permission. error Domain=NSCocoaErrorDomain Code=257 "The file “Filename.fileextensionhere” couldn’t be opened because you don’t have permission to view it." UserInfo={NSFilePath=/private/var/mobile/Library/Mobile Documents/comappleCloudDocs/Filename.fileextensionhere, NSUnderlyingError=0x2834c9da0 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}} -- If I'm doing something wrong with UIDocumentPickerViewController it is a real shame that permission is not being denied in Debug mode, as devs are more likely to catch in prior to release. Anyone know where I'm going wrong and if not have a workaround? Thanks in advance.

Hello, I’m seeing a layout issue where the system window controls overlap the navigation bar’s right-side buttons when the app window is resized on iPadOS 26. Environment Xcode: 16.4 Simulator: iPadOS 26.0, device profile iPad Pro 13-inch Physical device: iPad updated to iPadOS 26 (same behavior) UI stack: UIKit + Storyboards (no SwiftUI) App structure: Root UINavigationController Summary Since iPadOS 26 introduced freely resizable app windows, the system’s window management controls (close/minimize/resize at the top-right) begin to overlap the navigation bar buttons as the window size becomes smaller. At maximum window size there’s no issue. Additionally, the navigation bar buttons themselves appear to scale down visually when the window gets smaller. Steps to Reproduce Build with Xcode 16.4 and run on iPadOS 26.0 (simulator or device). Open a screen embedded in a UINavigationController with right-side bar button items. Resize the app window to a smaller size. Observe the top-right system window controls overlapping the navigation bar buttons. Expected Result System window controls should not overlap app content; the navigation bar should remain usable and properly spaced at all supported window sizes. Actual Result When the window is small, the system window controls overlap the right-side navigation bar buttons. The bar button items also appear to shrink as the window size decreases. Notes Reproducible on both simulator and a real device updated to iPadOS 26. Project uses UIKit + Storyboards only (no SwiftUI). Safe areas and basic constraints look fine, so the root cause is unclear. Questions Is this a known issue with iPadOS 26 resizable windows? Any recommended workaround (e.g., API to reserve space near the window controls, UINavigationBar configuration, or trait/size-class handling)? I can provide a minimal sample project and screenshots if helpful. Thank you!

Platform: iOS 26 RC / Xcode 26 RC Component: UIKit - UITextField Description: When typing a Japanese character (or other IME input) as the first character in a UITextField and then losing focus (by pressing Enter or tapping elsewhere), the character is incorrectly duplicated. This issue only happens in iOS26 beta. Steps to Reproduce: Create a UITextField with shouldChangeCharactersIn delegate Switch to Japanese keyboard Type "あ" (or any hiragana character) Press Enter or tap outside the text field Observe the character count becomes 2 instead of 1 Expected Result: Character count should remain 1 Actual Result: Character is duplicated, count becomes 2 Sample Code: func shouldChangeText( in range: NSRange, replacementText string: String, maximumNumberOfCharacters: Int, regexValidation: String? = nil) -> (String, Bool) { guard let stringRange = Range(range, in: currentText) else { return (currentText, false) } if let regex = regexValidation, string != "", // delete key !string.room.checkPattern(regex) { return (currentText, false) } let changedText = currentText.replacingCharacters(in: stringRange, with: string) let allowChange = changedText.utf16.count <= maximumNumberOfCharacters print("=== stringRange: \(stringRange), currentText: \(currentText), replacementText: \(string) changedText: \(changedText), allowChange: \(allowChange) ===") guard !allowChange else { return (changedText, allowChange) } // Accept text deletion even if changedText count is more than maximumNumberCharacters guard !string.isEmpty else { return (changedText, true) } insert(text: string, maximumNumberOfCharacters: maximumNumberOfCharacters) return (currentText, allowChange) }

I’m creating a UITabBarController with a simple array of UITab instances. I’m setting the mode to .tabSideBar. How do I prevent editing? I don’t want the Edit button to appear at all. I’ve tried setting the tab controller’s customizableViewControllers property to both nil and an empty array but neither is preventing the Edit button from appearing. I scanned the various delegates and I don‘t see any relevant methods. So far I’ve tested this on a simulated iPad running iPadOS 26 using Xcode 26 RC.

After updating to iPad OS 26, when moving around the app, I can not see the back button, title, and the right menu button on the navigation bar unless I scroll down, then everything is fine. Any advice ? Thanks