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

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?

Fatal Exception: NSInternalInconsistencyException Cannot remove an observer <WKWebView 0x135137800> for the key path "configuration.enforcesChildRestrictions" from <STScreenTimeConfigurationObserver 0x13c6d7460>, most likely because the value for the key "configuration" has changed without an appropriate KVO notification being sent. Check the KVO-compliance of the STScreenTimeConfigurationObserver [class.] I noticed that on iOS 26, WKWebView registers STScreenTimeConfigurationObserver, Is this an iOS 26 system issue? What should I do?

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

All system colors are displayed incorrectly on the popover view. Those are the same views present as a popover in light and dark mode. And those are the same views present as modal. And there is also a problem that when the popover is presented, switching to dark/light mode will not change the appearance. That affected all system apps. The following screenshot is already in dark mode. All those problem are occured on iOS 26 beta 3.

According to our crash analytics, the application crashes when trying to share a PDF file in the UIDocumentInteractionController. This crash takes place on iOS 26+ only. Based on analytics, user sessions end when the pdf file is opened in the UIDocumentInteractionController. We couldn't reproduce it on a physical device or a simulator. Can you please help with a fix or at least workaround for this issue? What's your opinion for bug localization (application or framework)? Crash log is attached below. CoreFoundation __exceptionPreprocess + 164 libobjc.A.dylib objc_exception_throw + 88 CoreFoundation -[__NSArrayM insertObject:atIndex:] + 1276 ShareSheet __79-[SHSheetActivityItemsManager loadItemProvidersForRequest:activity:completion:]_block_invoke + 972 ShareSheet __79-[_UIShareServiceActivityProxy _loadItemProvidersFromActivityItems:completion:]_block_invoke + 88 ShareSheet __74+[UIActivity _loadItemProvidersFromActivityItems:withCacheURL:completion:]_block_invoke_4 + 352 libdispatch.dylib _dispatch_call_block_and_release + 32 libdispatch.dylib _dispatch_main_queue_drain.cold.5 + 812 libdispatch.dylib _dispatch_main_queue_drain + 180 CoreFoundation __CFRunLoopRun + 1944

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?

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

in iOS26.4, after installing the app for the first time, opening the app and clicking on the UITextField input box will trigger the system to pop up the network permission application interface. This issue did not exist before iOS 26.3, only in iOS 26.4. This is a fatal bug where the network permission request box should not pop up when the developer has not called the network related API.

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.

"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.

I've created a custom keyboard and implemented the: class KeyboardViewController: UIInputViewController The imlementation looks like this: override func viewDidLoad() { super.viewDidLoad() var stack = UIStackView() stack.axis = .vertical stack.spacing = 8 stack.translatesAutoresizingMaskIntoConstraints = false stack.distribution = .fill stack.heightAnchor.constraint(equalToConstant: 200).isActive = true .... view.addSubview(stack) NSLayoutConstraint.activate([ stack.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 20), stack.trailingAnchor.constraint(equalTo: view.trailingAnchor, constant: -20), stack.topAnchor.constraint(equalTo: view.topAnchor, constant: 10), stack.bottomAnchor.constraint(equalTo: view.bottomAnchor, constant: -10) ]) The problem is that the keyboard seems to start showing in the size (I've printed the parent frame): Optional(<UIView: 0x101008480; frame = (0 0; 390 844); autoresize = W+H; layer = <CALayer: 0x600000207b80>>) and than resizes to my given height. But it's not fast enough so that I can see some glitches whenever I switch from another keyboard to my custom keyboard. Is there a way to prevent this resizing or start the keyboard in a given size? This is just not the best user experience.

I found the following statement on the site https://developer.apple.com/documentation/technotes/tn3187-migrating-to-the-uikit-scene-based-life-cycle: "Soon, all UIKit based apps will be required to adopt the scene-based life-cycle, after which your app won’t launch if you don’t. While supporting multiple scenes is encouraged, only adoption of scene life-cycle is required." Could you please clarify when exactly apps will no longer be able to launch if they do not adopt the scene-based life-cycle? I would like to confirm the deadline as the impact of this change is significant.

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 ?

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.

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.

Over the last two weeks, I’ve had sporadic reports from users who suddenly have a corrupt image in the database for my app. It’s only affecting a few users and may possibly have been fixed with iOS 26.4.1 (I’m not sure). In any case, this started suddenly with the release of iOS 26.4 - our app has not been changed in several months. But I wanted to share what’s happening in case others are experiencing this. My app lets users import photos from the camera roll, photo albums, etc. Once the user has selected an image, the app saves this to a SQLite3 database using “image.heicData()”. For the four or five users who have been affected by this problem, the heicData call returns successfully, with a non-nil Data value. But the image itself is corrupt and unreadable. When the user tries to later open a screen containing the image, the app crashes. I’ve had to manually guide each user through tracking down and removing the affected item or items to resolve it, which is a bad experience for them and time-consuming for us. Our app crashes when it tries to read the image (using “UIImage(data: heicData)”). All users who have this problem have had an ExcUserFault file in their crash reports with our app name in it. It's not possible to symbolicate this file but i've included an excerpt at the bottom of this post: I was able to extract some raw data saved when this error occurs. When you run “file corrupt_image.heic”, you get: AmigaOS bitmap font "rtypheic", fc_YSize 0, 35001 elements which definitely doesn’t seem right. On a valid HEIC file, i get: ISO Media, HEIF Image HEVC Main or Main Still Picture Profile Is anyone else experience this? Or does anyone else have any suggestions about what could be happening? I submitted feedback FB22667639 about this. ExcUserFault example Exception Type: EXC_GUARD Exception Subtype: GUARD_TYPE_USER Exception Message: namespc 7 reason_code 0x0000000000000009 Exception Codes: 0x6000000000000007, 0x0000000000000009 Termination Reason: Namespace LIBXPC, Code 9, XPC_EXIT_REASON_FAULT Thread 0: 0 ??? 0x231fa997c 0x180000000 + 2985990524 1 ??? 0x197eb98b4 0x180000000 + 401316020 2 ??? 0x197ec4e04 0x180000000 + 401362436 3 ??? 0x197ec5ea0 0x180000000 + 401366688 4 ??? 0x19066bdb8 0x180000000 + 275168696 5 ??? 0x19066b968 0x180000000 + 275167592 6 ??? 0x19b5c19a4 0x180000000 + 459020708 7 ??? 0x19b5cfa2c 0x180000000 + 459078188 8 ??? 0x19b5cf838 0x180000000 + 459077688 9 ??? 0x197ec7c74 0x180000000 + 401374324 10 ??? 0x197ec991c 0x180000000 + 401381660 11 ??? 0x1bd74222c 0x180000000 + 1031021100 12 ??? 0x1bd744ba4 0x180000000 + 1031031716 13 ??? 0x1bd730e18 0x180000000 + 1030950424 14 ??? 0x1bd7458f8 0x180000000 + 1031035128 15 ??? 0x1bd730e18 0x180000000 + 1030950424 16 ??? 0x1bd731ae4 0x180000000 + 1030953700 17 ??? 0x1bd73bdac 0x180000000 + 1030995372 18 ??? 0x1bd73b6ac 0x180000000 + 1030993580 19 ??? 0x1e23283b0 0x180000000 + 1647477680 20 ??? 0x1e23278c0 0x180000000 + 1647474880

The app becomes unresponsive when pushing a new page. The screen is covered by the _UIParallaxOverlayView class, blocking all gestures. Are there any scenarios where the transition animation might suddenly stop mid-process? Or could you provide more information to help me troubleshoot this issue? I noticed: When the issue occurs, the FromViewController is displayed on the screen. The ToViewController also exists in the view tree, but it's not visible on the screen. _UIParallaxOverlayView only appears on iOS 18 and above. The animation appears to be controlled by +[UIView _fluidParallaxTransitionsEnabledWithTraitCollection:], which is _os_feature_enabled_impl("UIKit", "fluid_parallax_transitions"). Reference

Hello, I'm a bit new to iOS development, so this could be something I've overlooked, but I've tried a bunch of things on my own and with the help of Copilot, as well as some senior engineers here at my company. I let AI summarize what the problem is, what I've tried, what doesn't work, and also some information on the system: Problem: UITabBarAppearance Custom Colors Ignored - All Diagnostics Show Correct Configuration Environment: iOS Deployment Target: 13.4 Xcode: Latest (26.4.1 as of writing) Device/Simulator: Both affected Language: Swift UI: UIKit with Storyboards Description: Tab bar selected item displays system default colors (gray in light mode, white in dark mode) instead of my custom named color from asset catalog. System colors like .systemBlue work correctly, but custom asset catalog colors are completely ignored. Expected behavior: Selected tab bar item should display BlueTVColor2 (RGB 0, 0.173, 0.38 in light mode; RGB 0, 0.569, 1.0 in dark mode) Actual behaviour: Selected tab bar item displays gray/white/black system defaults What I've Verified Works Correctly: Color resolution: let color = UIColor(named: "BlueTVColor2") print(color) // Resolves correctly print(color?.resolvedColor(with: .init(userInterfaceStyle: .light))) // RGB(0, 0.173, 0.38) print(color?.resolvedColor(with: .init(userInterfaceStyle: .dark))) // RGB(0, 0.569, 1.0) Asset Catalog Configuration: BlueTVColor2.colorset has both light and dark variants template-rendering-intent: template set on all tab bar images All images use .alwaysTemplate rendering mode (verified at runtime) UITabBarAppearance Configuration (Although I've also tried just directly in the storyboard, it didn't work, the below is in code-behind): override func viewDidLoad() { super.viewDidLoad() let selectedColor = UIColor(named: "BlueTVColor2")!.resolvedColor(with: traitCollection) let normalColor = UIColor.redTVColor.resolvedColor(with: traitCollection) let appearance = UITabBarAppearance() appearance.configureWithOpaqueBackground() let itemAppearance = UITabBarItemAppearance() itemAppearance.selected.iconColor = selectedColor itemAppearance.selected.titleTextAttributes = [.foregroundColor: selectedColor] itemAppearance.normal.iconColor = normalColor appearance.stackedLayoutAppearance = itemAppearance appearance.inlineLayoutAppearance = itemAppearance appearance.compactInlineLayoutAppearance = itemAppearance tabBar.isTranslucent = false tabBar.standardAppearance = appearance if #available(iOS 15.0, *) { tabBar.scrollEdgeAppearance = appearance } tabBar.tintColor = selectedColor tabBar.unselectedItemTintColor = normalColor } Runtime Diagnostics Confirm Everything is Set Correctly: Appearance selected iconColor: RGB(0, 0.569, 1) // Correct Tab bar standardAppearance selected iconColor: RGB(0, 0.569, 1) // Correct Tab bar tintColor: RGB(0, 0.569, 1) // Correct Tab bar unselectedItemTintColor: RGB(1, 0.259, 0.271) // Correct All tab bar item images: Rendering mode = 2 (.alwaysTemplate) // Correct Settings persist through viewDidAppear // Correct Yet the UI displays system default gray/white/black colors. What I've Tried (All Failed): Deprecated selectedImageTintColor property (returns nil when standardAppearance is set) Both configureWithDefaultBackground() and configureWithOpaqueBackground() Dynamic colors vs resolved fixed colors Configuring all layout appearances (stacked, inline, compactInline) Setting isTranslucent = false Re-applying appearance in viewDidAppear with delayed dispatch Manually re-applying template rendering mode to images at runtime Removing storyboard color configuration entirely Changing global accent color build setting System colors (.systemBlue) work fine; only custom asset catalog colors fail Additional Context: This is a legacy project originally created around 2013-2015, migrated to modern Swift/iOS (not everywhere, major parts are still using objc, UIKit/Storyboard) When I set tabBar.tintColor = .systemBlue it works perfectly The color BlueTVColor2 is used successfully elsewhere in the app (also if setting it as the background of the UITabBar, it works, just not as a tint for the icons/text) Storyboard has no selectedImageTintColor set (removed during debugging) No UITabBar.appearance() proxy calls anywhere in codebase Deployment target is iOS 13.4 (when UITabBarAppearance was introduced) Pre iOS 26.0, the adding of the tint color to the UITabBar worked as intended, so this has come as a result of the update to iOS 26.0 in some way Comparison with Working Test Project: Created a fresh iOS project with same setup - custom asset catalog colors work perfectly in tab bar with identical UITabBarAppearance configuration. Question: Why would UITabBarAppearance properties show correct colors in diagnostics but render with system defaults? Is there a known issue with asset catalog named colors in UITabBarAppearance on iOS 13.4+? Could legacy project settings interfere with modern appearance API? Any insights would be greatly appreciated. I'm running out of ideas and this seems like either a framework bug or some undocumented interaction between asset catalogs and tab bar appearance. Code Sample: I can't release much code besides just things I've worked on, so hopefully this full description of the problem and everything I've tried can help illuminate the issue at hand. I've tried all of the above and probably more the past week and can't make heads or tails of where the issue is located. The best I can come up with right now is some sort of compatibility issues but I have no way of determining where it is that I should investigate and fix.

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.