Summary On iOS 27, tabBarController(:shouldSelect:) — the long-standing UITabBarControllerDelegate method accepting a UIViewController — is no longer invoked when the user taps a tab inside a SwiftUI TabView. Tab selection now routes exclusively through tabBarController(:shouldSelectTab:), the UITab-based variant introduced in iOS 18. Impact Any code that relies on tabBarController(_:shouldSelect:) to: Intercept or prevent tab switches Detect tab reselection Propagate tab-change events to other subsystems (e.g., a JavaScript bridge in a hybrid app) ...will silently stop working on iOS 27. There are no compiler warnings, no deprecation notices, and no runtime assertions — the method simply is no longer called. This affected react-native-bottom-tabs, a widely used open-source library, causing all tab screens beyond the first to render as blank/white after any tab tap (see: https://github.com/callstack/react-native-bottom-tabs/issues/529). The workaround is to implement tabBarController(_:shouldSelectTab:) Reproduction Create a SwiftUI TabView with 3+ tabs. Set a UITabBarControllerDelegate on the underlying UITabBarController. Implement tabBarController(_:shouldSelect:) — e.g., to log or prevent selection. Run on iOS 26 → delegate method fires correctly. Run on iOS 27 Beta → delegate method is never called. Request / Questions Is this an intentional behavioral change for iOS 27? If so, it constitutes an undocumented, silent API break for any code targeting UITabBarControllerDelegate. The old method still compiles and links without any warning. Will tabBarController(_:shouldSelect:) be formally deprecated with a corresponding compiler warning so developers can find and migrate affected call sites? Is tabBarController(_:shouldSelectTab:) now the exclusive interception point on iOS 27, even for apps that haven't fully migrated to the new UITab-based API? We'd appreciate any official guidance so libraries and apps can ship iOS 27-compatible binaries with confidence. Environment Xcode 26.5 / 17F42 iOS 27 Beta Reproducible in both UIKit and hybrid (React Native) contexts

Hello, After adapting Liquid Glass for iOS 26.5, I encountered an issue: the leftBarButtonItem(s) shift right, leaving a large space on the left after launching and dismissing the camera. I tried adding a negative spacer and setting leading space, but neither worked. This only happens when launching the camera; it does not occur during photo selection.

Hey All! Curious if others are seeing this where UIAlertController style action sheets (and to some extent Alert type) in iPad OS 27.0 B1 seem to be very buggy. By that i mean if you have an action sheet that has 20 items or some, half of them are not visible until you scroll or move the mouse over them (in simulator), and when tapping on them its a hit or miss if it triggers the delegate, sometimes it triggers on the first tap (click) or sometimes it takes 2 to 3 taps (clicks) to the delegate to trigger and the actioinsheet to dismiss. On initial look it seems iOS 27.0 B1 is working just fine, seems iPad Specific. While the list of the items not showing is only for action sheets, the 'sometimes' takes 2 to 3 taps (clicks) to select and item happens in both type ActionSheet and Alert. Sometimes it takes 2 to 3 taps to tigger an alert button etc. Both the above described issues happen on both device and simulator. Ive attached a video and a sample Proj to FB22998239. Hoping one of the UIKit Engineers can take a look, thanks for everything!

UIPageViewController crashes with _UIQueuingScrollView state inconsistency on iOS 26 We are experiencing two types of crashes in UIPageViewController (transition style .scroll) that only occur on iOS 26. These crashes do not occur on iOS 18 or earlier with the same code. Crash 1: "No view controller managing visible view" NSInternalInconsistencyException: No view controller managing visible view <_UIQueuingScrollView: 0x...> -[UIPageViewController _flushViewController:animated:] -[UIPageViewController _setViewControllers:withTransition:animated:completion:] This occurs when calling setViewControllers(_:direction:animated:completion:) after a swipe gesture, particularly when didFinishAnimating delegate method does not fire. Crash 2: "Duplicate states in queue" NSInternalInconsistencyException: Duplicate states in queue for view: <UIView: 0x...> -[_UIQueuingScrollView _enqueueCompletionState:] -[_UIQueuingScrollView _enqueueAnimatedScrollInDirection:withRevealView:coverView:stashedView:translation:] This occurs when programmatic page changes (setViewControllers with animated: true) overlap with internal _UIQueuingScrollView state that has not been fully cleaned up. Reproduction Steps Create a UIPageViewController with .scroll transition style Swipe partially (without completing the page transition), then release Immediately tap a button that calls setViewControllers(_:direction:animated:completion:) Repeat a few times — the crash occurs intermittently Combining swipe gestures with programmatic setViewControllers calls reliably triggers one of the two crashes within a few attempts. Root Cause Analysis On iOS 26, the UIPageViewControllerDelegate method pageViewController(_:didFinishAnimating:previousViewControllers:transitionCompleted:) sometimes does not fire after a swipe gesture is cancelled or completed. This leaves _UIQueuingScrollView in a dirty internal state (pending transition data not cleared). A subsequent setViewControllers call then encounters this stale state and triggers an assertion failure. The crash stack traces are entirely within UIKit internals (_UIQueuingScrollView, UIPageViewController), with no app code in the crashing frames. Environment Xcode 26.4.1 iOS 26 (all beta versions tested) iPhone 17, iPhone 16 Pro, iPhone 16 Pro Max (simulator and device) UIPageViewController with transitionStyle: .scroll Does not reproduce on iOS 18 or earlier

In this iOS app, with UIKit in Swift, I create a UISegmentedControl in stroryboard. I define the text for each segmentTitles in IB ,and need to localise. I have tried in the main.xxx files "id.segmentTitles" = ["a", "b", "c", "d", "e"]; to no avail. I understand this is a very very old issue that UISegmentedControl are not localized from stroryboard: https://stackoverflow.com/questions/12884751/uisegmentedcontrol-and-localization I tried to use a similar approach as for UITextView (which are not either localized) helpTextView.text = NSLocalizedString("id.text", tableName: "Main", comment: "helpTextView") But cannot make it. I found a work around, by localising in code: let seg0 = NSLocalizedString("a", comment: "Segment") segmentedControl.setTitle(seg0, forSegmentAt: 0) However, I get error messages in log unless I clear the segment titles in IB: ERROR: id.segmentTitles[0] not found in table Main of bundle CFBundle 0x600003b101c0 Is there a solution to this ?

My app presents a popover mail controller, which works fine on iPhone and on iPadOS <26.4. However in iPadOS =>26.4, there is no exit or cancel button in the top left corner as usual. The popover can only be closed by tapping the top centre of the view where the 'swipe down bar' is; it cannot be closed by actually swiping down. This is obviously not intuitive for a user. Since the mail controller is not customizable, I'm asking whether this is a bug, a new (unintuitive) design, or if implementations of a mail controller need updating on the new OS.

The view controller stack: UITabBarController ｜__ UINavigationController ｜__ HomeViewController (hidesBottomBarWhenPushed=false) ｜__ DetailViewController (hidesBottomBarWhenPushed=true) The DetailViewController customize the navigation transition via UINavigationControllerDelegate, UIViewControllerAnimatedTransitioning and UIViewControllerInteractiveTransitioning protocols, so that the navigation can be driven by a vertical pan or swipe gesture. Use a real device to : Step 1, drag the DetailViewController down and cancel, the tabBar flashes for a while and keep hidden after dragging. Step 2, repeat the step 1 again, the tabBar remains at the bottom, but without buttons. DetailViewController.swift

I am creating UI elements with glass backgrounds such as: UIVisualEffectView(effect: UIGlassEffect(style: .regular)) And UIButtons such as: var buttonConfig = UIButton.Configuration.glass() This gives the glass a dark background and white tint/labels when the device interface settings are dark, and conversely light backgrounds with black tint/labels when the interface mode is light. Perfect! Now enter the UINavigationBar buttons. I've spent a day trying every configuration possible to make them match the rest of the UI. But they have a mind of their own. They will flash different colors when scrolling the content. They do not respect the user interface mode. Out of desperation, I tried adding my own glass UIVisualEffectView behind the navigation bar and and disabled the button glass background with: someBarItem.hidesSharedBackground = true Even though I don't like that design as much as the individual glass buttons, it at least lets me match the rest of the UI. Alas that setting makes the animation to the next screen visually buggy. Hard to describe, but it's not acceptable. The only thing it seems I can do is make the content view start below the navigation bar area. But then I completely lose the glass effect - though at least I can make them match the rest of the UI and the push/pop animation isn't buggy. I realize I can opt out of glass entirely, but I want to use glass. The problem isn't glass. The problem is the navigation bar does not respect the user interface mode or allow us to set the glass type. I get the system trying to make the glass more legible, but, the buttons that I can set with UIButton.Configuration.glass() and UIGlassEffect(style: .regular) are always legible regardless of the background color because the tint/label color is the opposite of button background color. I've been a full time iOS developer for 15 years, and this is most frustrating UIKit changes I've ever seen. It's a step backward when it's impossible to make the navigation bar match the rest of the UI. It's a step backwards when the navigation bar flickers and changes. All that we need is a glass property for the UINavigationBarItems or UINavigationBarAppearance that works like UIGlassEffect or UIButton.Configuration glass configurations. Or default behavior that just respects traitCollection.userInterfaceStyle or overrideUserInterfaceStyle to begin with. Dark UserInterfaceStyle example. The top buttons should match the bottom UI elements, but does not seem possible.

Summary On iOS 18 and later, Chinese text rendering shows a noticeable performance regression related to the HVF (Hierarchical Variable Font) pipeline. Environment iOS Version: iOS 18+ Framework: libhvf.dylib (Hierarchical Variable Font) Affected Font: PingFangUI.ttc (private system font, automatically used for Chinese text) Related Frameworks: CoreText, CoreGraphics, FontParser Devices: All iOS devices (more noticeable on older hardware) Background iOS 18 Change: PingFang.ttc was removed from /System/Library/Fonts/ Private PingFangUI.ttc was added (inaccessible via normal font APIs) System automatically uses PingFangUI.ttc for all Chinese text rendering PingFangUI.ttc contains HVF tables → utilizes libhvf.dylib HVF Architecture: HVF (Hierarchical Variable Font) organizes glyphs as tree structures Each glyph = Composite → multiple Parts → nested hierarchy Rendering a single character requires traversing this tree Key Observation A single Chinese glyph typically triggers ~20 calls to HVF::LoaderHVGL::loadPartAtIndex. Cache invalidation is triggered via IncrementRenderCount after every 18 glyphs: __ZNK27THierVariationsDataForkFont20IncrementRenderCountEv: ldr w8, [x0, #0x12c] add w8, w8, #0x1 str w8, [x0, #0x12c] cmp w8, #0x12 b.lo return ldr x0, [x0, #0x120] bl HVF_clear_part_cache str wzr, [x19, #0x12c] return: ret This causes the cache to be cleared before a typical sentence finishes rendering. Complete Call Stack (Rendering Hot Path) #0-1 HVF::LoaderHVGL::loadPartAtIndex #2 HVF::FlatPartCache::partAtIndex #3 HVF::PartTransformRenderer::renderComposite #4 HVF::PartTransformRenderer::render #5 HVF::PartTransformRenderer::renderToContext #6 _HVF_render_current_part #7 THierVariationsFontHandler::GetOutlinePath #8 TFontHandler::CopyGlyphPath #9 THierVariationsFontHandler::CopyGlyphPath #10 TFPFont::CopyGlyphPath #11-12 TFPFont::CopyGlyphPath / _FPFontCopyGlyphPath #13 _CGFontCreateGlyphPath #14 _CGGlyphBuilderLockBitmaps #15 _render_glyphs #16 _draw_glyph_bitmaps #17 _ripc_DrawGlyphs #18 CG::DisplayList::executeEntries #19 _CGDisplayListDrawInContextDelegate #20 _CABackingStoreUpdate_ #21-22 CALayer display/layout #23-24 CA::Transaction::commit #25-30 UIApplicationMain / RunLoop HVF::LoaderHVGL::loadPartAtIndex is consistently observed as a hot function in Instruments and in production. Cache Clear Call Stack #0 HVF::FlatPartCache::clear #1 HVF_clear_part_cache #2 THierVariationsDataForkFont::IncrementRenderCount #3 THierVariationsFontHandler::GetOutlinePath #4 TFontHandler::CopyGlyphPath #5 FPFontCopyGlyphPath #6 CGFontCreateGlyphPath #7 _render_glyphs #8 _draw_glyph_bitmaps #9 _ripc_DrawGlyphs This shows that cache clearing occurs within the glyph rendering path. Impact For a typical Chinese sentence (~20 characters): Each glyph requires multiple part loads (~20 per glyph) Cache is cleared before rendering completes Previously loaded parts cannot be reused Observed effects: Increased loadPartAtIndex invocation count Low cache hit rate Increased CPU usage in glyph rendering Main-thread blocking during Core Animation commit Regression iOS 17 and earlier: Rendering is smooth under similar workloads. iOS 18+: Increased rendering cost and visible frame drops. The issue is more pronounced on older devices such as iPhone XS and iPhone 11. Reproduction Render a Chinese text string longer than 18 characters, for example: 刷新测试中文文本用于验证渲染性能问题需要超过十八个字 Observe: Repeated loadPartAtIndex calls Frequent cache clearing Request It would be helpful to review the cache eviction strategy for HVF, particularly for complex scripts such as Chinese. Potential considerations: Adjusting or scaling the cache threshold Avoiding full cache clears during continuous rendering Improving reuse of parts across glyphs within the same rendering batch

Dynamic UISegment control in collection view returns selected segment index 0 on click of other segments after updating iOS and Xcode 26 for first time afterwards its working as expected in iOS less than 26 devices. But woking fine in iOS 26 devices. Please suggest how to resolve Thanks in advance

Environment Device: iPad Pro 11-inch 2nd gen (iPad8,9 / A12X) OS: iPadOS 26.5 (23F77) Xcode: 26.3 Issue App crashes with EXC_BREAKPOINT / SIGKILL when user scrolls through a PDF in PDFView on iPadOS 26.5. Crash Log (ASI) "BUG IN CLIENT OF LIBPLATFORM: Trying to recursively lock an os_unfair_lock" Abort Cause 259 Root Cause (from .ips) Two threads deadlock on os_unfair_lock inside CGPDFPageInsertTableDescriptions: Thread 0 (main): _os_unfair_lock_recursive_abort CGPDFPageInsertTableDescriptions [PDFPageAnalyzerV2 addTablesFromVisionDocument:documentImage:toPage:withBox:]_block_invoke_2 _dispatch_async_and_wait_invoke ← main thread waiting Thread (PDFKit.PDFDocument.formFillingQueue): _dispatch_sync_f_slow ← background queue waiting for main thread +[PDFPageAnalyzerV2 addTablesFromVisionDocument:documentImage:toPage:withBox:] +[PDFPageAnalyzerV2 analyzePage:withBox:requestTypes:] -[PDFView visiblePagesChanged:] ← triggered by scrolling PDFPageAnalyzerV2 dispatches_sync back to the main thread from PDFKit.PDFDocument.formFillingQueue, while the main thread is already blocked in dispatch_async_and_wait for the same operation. This results in a recursive lock on os_unfair_lock in CGPDFPageInsertTableDescriptions → SIGKILL. Notes PDFPageAnalyzerV2 appears to be a new iOS 26 Vision-based table analysis feature No public API found in PDFKit headers to disable this analysis Workaround: pdfView.usePageViewController(true, withViewOptions: nil) appears to reduce frequency of visiblePagesChanged: triggers Question Is there an official API to disable PDFPageAnalyzerV2 table analysis on iOS 26? Is this a known issue with a fix planned?

Hi, I am seeing an issue with UITabBar Liquid Glass tinting on iOS 26. My app is light mode only (UIUserInterfaceStyle is set to Light in Info.plist). Dark mode is disabled. The issue seems to happen only when the light tab contains a UITableView. If I replace the table view with a plain view controller using only a white background, the issue no longer happens. When switching from a dark tab back to a light tab containing a table view, the tab bar can sometimes keep a dark Liquid Glass tint instead of returning to the expected light appearance. Here is a short video showing the issue: https://github.com/user-attachments/assets/d06bbbdd-efe3-4cfc-b596-a8ab89684c96 I also submitted a Feedback Assistant report for this issue: FB22761398. Minimal reproducible example: import UIKit final class TabBarController: UITabBarController { override func viewDidLoad() { super.viewDidLoad() let light = LightController() light.tabBarItem = UITabBarItem(title: "Light", image: UIImage(systemName: "list.bullet"), tag: 0) let dark = DarkController() dark.tabBarItem = UITabBarItem(title: "Dark", image: UIImage(systemName: "barcode.viewfinder"), tag: 1) viewControllers = [light, dark] } } private final class LightController: UIViewController, UITableViewDataSource { private lazy var tableView: UITableView = { let tableView = UITableView(frame: .zero, style: .insetGrouped) tableView.translatesAutoresizingMaskIntoConstraints = false tableView.dataSource = self return tableView }() private let rows = (1...3).map { "Row \($0)" } override func loadView() { super.loadView() configureSubviews() configureConstraints() } private func configureSubviews() { view.addSubview(tableView) } private func configureConstraints() { NSLayoutConstraint.activate([ tableView.topAnchor.constraint(equalTo: view.topAnchor), tableView.leadingAnchor.constraint(equalTo: view.leadingAnchor), tableView.trailingAnchor.constraint(equalTo: view.trailingAnchor), tableView.bottomAnchor.constraint(equalTo: view.bottomAnchor) ]) } func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int { rows.count } func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { let cell = UITableViewCell() cell.textLabel?.text = rows[indexPath.row] return cell } } private final class DarkController: UIViewController { override func loadView() { super.loadView() view.backgroundColor = .black } } I tried forcing the app to light mode and listening to trait changes, but it does not help since there is no actual userInterfaceStyle change. I also tried reapplying UITabBarAppearance, but the tab bar can still keep the previous dark Liquid Glass tint. Is there a recommended way to make UITabBar recompute its Liquid Glass tint when switching back to a light tab containing a UITableView?

"TN3187: Migrating to the UIKit scene-based life cycle" says: "In the next major release following iOS 26, UIScene lifecycle will be required when building with the latest SDK; otherwise, your app won’t launch." Does this mean as long as we keep building with Xcode 26 we'll be okay, but the app won't launch if built with Xcode 27? We intend to do the migration but I'm trying to figure out the deadline more exactly.

This is an iOS app that runs on Mac in iPad mode. on Mac, I want to be able to drop a file (pdf) on the app icon and see it in the app to display some notification that operation was OK. For this, I use notification, sent from sceneDelegate. All VC add observer for the notification, allowing to display whatever the front VC is. It works OK in most cases, except when: I drop a file on the app icon in the dock (app launched from Xcode which creates the icon in dock) In this case, I need to repeat the drop to get the notification sent. After that, it works systematically. The problem does not come from notification, but because func scene(_ scene: UIScene, openURLContexts URLContexts: Set) is not called, as I could test with: func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) { print("dropped") } dropped is logged only on second drop. Why does this occur only for the dock icon ?

When I try to create bindings between a xib file and it's associated objective-c source code, xcode no longer autocompletes to either an action or an outlet binding. The little circles in the code editor that would previously indicate bindings are no longer there. I can now only create bindings in the tree heirarchy of the UIKit editor after manually adding IBOutlets to the header files.

We are facing an issue with VNDocumentCameraViewController where the tick button in the top-right corner becomes completely unresponsive after a document is scanned. When the user taps the tick button immediately after capturing the document — before the "Ready for next Scan" text appears on screen — the button freezes and the documentCameraViewController(_:didFinishWith:) delegate is never called. Through debugging, we observed that if the tick is tapped before the scanned image thumbnail appears in the bottom-left corner, the delegate is never triggered. However, if the user waits for the thumbnail to appear and then taps the tick, it works as expected. This indicates that VNDocumentCameraViewController has an internal processing pipeline that must complete before the tick button becomes truly interactive, but there is no visual indication or API callback to inform the user or the developer when it is safe to tap. We would appreciate Apple looking into this and either disabling the button during processing, queuing the tap, or providing a delegate callback for when the controller is truly ready.

In an Xcode 26.4 + iOS 26.x environment, I called evaluateJavaScript inside webView(_ webView: WKWebView, didCommit navigation: WKNavigation!) and got the following error: Printing description of error: ▿ Optional<Error> - some : Error Domain=WKErrorDomain Code=4 "A JavaScript exception occurred" UserInfo={WKJavaScriptExceptionLineNumber=0, WKJavaScriptExceptionMessage=TypeError: undefined is not a function, WKJavaScriptExceptionColumnNumber=0, NSLocalizedDescription=A JavaScript exception occurred}) However, this worked fine in earlier versions before Xcode 26.4 (> 26.0 and < 26.4, though I do not remember the exact version), still with iOS 26.x. It also works fine in an Xcode 26.4 + iOS 18.x environment. And if I add a slight delay using DispatchQueue.main.asyncAfter in the Xcode 26.4 + iOS 26.x environment, then it works without any issue. So what exactly is going on here? I would really appreciate an explanation.

If an application utilizes MapKit exclusively to render custom content via MKTileOverlay (with canReplaceMapContent = true to entirely suppress Apple’s default map layers), are developers still contractually or technically mandated to display Apple's default "Legal" link? Currently, the hardcoded Apple attribution document details extensive copyright disclaimers for data suppliers like TomTom, Acxiom, and Breezometer. When an application renders entirely standalone, proprietary, or open-source map tiles, displaying this link creates two distinct issues: User Confusion: It incorrectly implies to end-users that the custom data being viewed is sourced from or validated by Apple's third-party data partners. Attribution Inaccuracy: It forces the display of entirely irrelevant copyright data while doing a disservice to the actual copyright holders of the active custom tile layers, who require their own distinct, prominent on-screen credit. It would be a significant UX improvement if the framework could dynamically hide the global data attribution link when canReplaceMapContent is active, allowing developers to provide accurate, context-specific legal text for the data layers actually in use.

I'm trying to get the count of how many windows an iPadOS app has 'open' (open from the user's perspective in the app switcher). This is for the sake of determining whether I should show or hide a button that takes action on every window (if there is only 1 window, the button will be hidden). According to the documentation the proper API for this is this property on UIApplication: // All of the representations that currently have connected UIScene instances or had their sessions persisted by the system (ex: visible in iOS' switcher) @property(nonatomic, readonly) NSSet<UISceneSession *> *openSessions So I print the count (only sessions with role UIWindowSceneSessionRoleApplication) when scenes are added/removed etc via appropriate lifecycle notifications like -sceneDidDisconnect: -sceneDidBecomeActive: and so forth. What I noticed is when I add a new window scene, the count increases by one so cool, that works. But when I kill a window in the App switcher the count does not decrease. I can end up in a situation where the app has only 1 window in the app switcher but the count prints 8, so this is wrong. So am I using the wrong API? How can I just get scene count in the app switcher? The documentation makes it seem like using 'connectedScenes' for this would be wrong because that property is not supposed to include 'archived' scenes in the app switcher (or is it?)? I do know I can't take action on an archived scene 'yet' but I would still show the button because whether or not the scene is archived in the app switcher is a fact that remains hidden from the user. My code will take care of that later after state restoration. Is iPadOS 26 potentially keeping scene sessions open for too long? Is there a good way to reliably detect how many scenes I have in the app switcher? Is a scene session explicitly killed by the user supposed to remain the .openSessions set? I am testing on the Simulator FWIW. iPad 26.5.

I have a barcode scanning app with keyboard extesnion. The keyboard has an option to open the app for barcode scanning app(Barcode Button as in the screenshot). After the scanning is done it will take the result back to host application. If you see the attached screenshot , we are asking the end user to navigate back to host application by clicking on the button at top left corner. Isn't it possible to auto navigate after the scanning is done by getting the host bundle ID.