Since iPadOS 26.1 I notice a new annoying bug when changing the dark mode option of the system. The appearance of the UI changes, but no longer for view controllers which are presented as Popover. For these view controllers the method "traitCollectionDidChange()" is still called (though sometimes with a very large delay), but checking the traitCollection property of the view controller in there does no longer return the correct appearance (which is probably why the visual appearance of the popover doesn't change anymore). So if the dark mode was just switched on, traitCollectionDidChange() is called, but the "traitCollection.userInterfaceStyle" property still tells me that the system is in normal mode. More concrete, traitCollection.userInterfaceStyle seems to be set correctly only(!) when opening the popover, and while the popover is open, it is never updated anymore when the dark mode changes. This is also visible in the standard Apps of the iPad, like the Apple Maps App: just tap on the "map" icon at the top right to open the "Map mode" view. While the view is open, change the dark mode. All of the Maps App will change its appearance, with the exception of this "Map mode" view. Does anyone know an easy workaround? Or do I really need to manually change the colors for all popup view controllers whenever the dark mode changes? Using dynamic UIColors won't help, because these rely on the "userInterfaceStyle" property, and this is no longer correct. Bugreport: FB20928471

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

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.

Description I'm developing a custom keyboard extension using UIInputViewController and need to set a specific height of 268 points. The keyboard functions correctly, but there's a visible flicker and resize animation during launch that I cannot eliminate. The Problem When the keyboard launches, iOS provides incorrect heights before settling on the correct one. At launch, the view starts at 0×0. Around 295ms later, iOS sets the frame to 440×956 which is full screen height and wrong. Around 373ms, iOS changes it to 440×452 which is still wrong. Finally around 390ms, iOS settles at 440×268 which matches our constraint. This causes visible flicker as the view resizes three times rapidly. The keyboard appears to shrink from full screen down to the correct height, and users can clearly see this animation happening. What I've Tried I've tried adding a height constraint on self.view which gives me the correct height but causes the visible flicker. I created a custom UIInputView subclass and overrode intrinsicContentSize to return my desired height. iOS completely ignores this and gives random heights like 471pt, 680pt, or 956pt instead. I set allowsSelfSizing to true on my UIInputView subclass. iOS ignores this property. I set preferredContentSize on the view controller. iOS ignores this as well. I tried adding the constraint in viewDidAppear instead of viewDidLoad, thinking iOS might have settled by then. It still causes flicker. I overrode the frame and bounds setters on my UIInputView to clamp the height to my desired value. iOS bypasses these overrides somehow. I overrode layoutSubviews to force the correct height after the super call. iOS still applies its own height. Specific Question What is the correct API or technique to specify a keyboard extension's height that iOS will respect immediately upon launch, without triggering the resize animation sequence? Other third-party keyboards like Grammarly and SwiftKey appear to have solved this problem. Their keyboards appear at the correct height without any visible flicker. How do they achieve this? Expected Outcome The keyboard should appear at 268pt height on the first frame with no visible resize animation. Steps to Reproduce Create a new iOS App project in Xcode and add a Keyboard Extension target. In KeyboardViewController.swift, add a height constraint in viewDidLoad: override func viewDidLoad() { super.viewDidLoad() let heightConstraint = view.heightAnchor.constraint(equalToConstant: 268) heightConstraint.priority = .defaultHigh heightConstraint.isActive = true let label = UILabel() label.text = "Demo Keyboard" label.textAlignment = .center label.translatesAutoresizingMaskIntoConstraints = false view.addSubview(label) NSLayoutConstraint.activate([ label.centerXAnchor.constraint(equalTo: view.centerXAnchor), label.centerYAnchor.constraint(equalTo: view.centerYAnchor) ]) } Build and run on a physical device. Enable the keyboard in Settings, then General, then Keyboard, then Keyboards. Open any app with a text field and switch to the custom keyboard using the globe button. Observe the height changing from around 956pt to 452pt to 268pt with visible animation. Environment iOS 17 and iOS 18 and 26.2, Xcode 16 and Xcode 26, affects all iPhone models tested, reproducible on both simulator and physical device.

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

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.

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

Our app supports Full Keyboard Access. We have a scroll view containing content that extends beyond the visible area. When navigating with the keyboard, focusable elements inside the scroll view are reached and the view scrolls to follow focus, but content that has no focusable elements (e.g. long blocks of static text, images, or footer content below the last control) can't be brought into view by the keyboard alone. Is there a supported way for Full Keyboard Access users to scroll a scroll view to see this off-screen, non-focusable content — e.g. a built-in scroll command, or an API to make the scroll view itself focusable/scrollable via the keyboard — without resorting to custom key handling?

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

Hi, I have an app that displays tens of short (<1mb) mp4 videos stored in a remote server in a vertical UICollectionView that has horizontally scrollable sections. I'm caching all mp4 files on disk after downloading, and I also have a in-memory cache that holds a limited number (around 30) of players. The players I'm using are simple views that wrap an AVPlayerLayer and its AVPlayerItem, along with a few additional UI components. The scrolling performance was good before iOS 26, but with the release of iOS 26, I noticed that there is significant stuttering during scrolling while creating players with a fileUrl. It happens even if use the same video file cached on disk for each cell for testing. I also started getting this kind of log messages after the players are deinitialized: <<<< PlayerRemoteXPC >>>> signalled err=-12785 at <>:1107 <<<< PlayerRemoteXPC >>>> signalled err=-12785 at <>:1095 <<<< PlayerRemoteXPC >>>> signalled err=-12785 at <>:1095 There's also another log message that I see occasionally, but I don't know what triggers it. << FigXPC >> signalled err=-16152 at <>:1683 Is there anyone else that experienced this kind of problem with the latest release? Also, I'm wondering what's the best way to resolve the issue. I could increase the size of the memory cache to something large like 100, but I'm not sure if it is an acceptable solution because: 1- There will be 100 player instance in memory at all times. 2- There will still be stuttering during the initial loading of the videos from the web. Any help is appreciated!

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

On iOS 26 (26.0–26.5), a rectangular region in the lower half of the screen sometimes does not render while the content underneath remains laid out and interactive — scrolling works, hit testing succeeds, and rows visibly emerge from behind the floating tab bar as you scroll. This is a render-server / compositor gap, not a layout or safe-area issue. We see it on both UIKit and SwiftUI scroll surfaces inside the same UITabBarController: UIKit: UICollectionView with UICollectionViewFlowLayout (sectionInsetReference = .fromSafeArea) SwiftUI: List(.plain) nested in TabView(.page) inside a UIHostingController Confirmed on iPhone 16 Pro, iPhone 17 Pro, iPhone 13 Pro Max. Community threads (linked below) report the same symptom in Messages, Notes, Safari, Mail, and the App Store. Questions for Apple Is this acknowledged as an OS-level regression, and is a fix targeted for an upcoming iOS 26.x release? Is there a deterministic repro? We've tried background/foreground cycles, push notifications mid-scroll, tab switches during inertia, lock/unlock, orientation flips, simulated memory warnings, layout-invalidation storms, and trait-collection cycles — none reliably trigger it on our test devices. Is there a developer-side mitigation (e.g. avoiding specific UIVisualEffectView / Glass configurations, opting out of a rendering optimization) until a system fix lands? Is there a runtime signal on CALayer or UIScrollView we can inspect to detect this gap state and force a recovery (tile redraw, backing-store discard, etc.)? Notes We cannot reproduce locally. Affected users hit it organically; once it appears it persists across re-layout until the view controller is torn down. Community reports consistently mention Reduce Transparency being enabled on affected devices, and toggling it off clears the issue for many. In our own testing, RT alone is not sufficient to trigger the bug — it appears to be a contributing condition rather than the trigger. References: Apple Discussions: https://discussions.apple.com/thread/256182149 Reddit r/ios (multiple system apps): https://www.reddit.com/r/ios/comments/1nlzn7f/some_apps_cutting_off_half_the_display/ https://www.idownloadblog.com/2026/03/23/webpage-content-cutting-off-safari/

On iOS 26 with Full Keyboard Access enabled, a UITableView(style: .grouped) with custom cells only enumerates section 0 in the Ctrl+Tab focus order (But it works with arrow keys). Cells in sections 1+ are reachable via arrow keys, and canFocusRowAt fires and returns true when arrows spatially reach them — but Tab leaves the table after the last row of section 0 and jumps to the next focus item outside the table. Same code works correctly on iOS 18.x. focusGroupIdentifier strategies (single ID on the table, same ID across view/table/every cell, unique ID per cell) have no effect. tableView.allowsFocus is true. Is this a known iOS 26? Has anyone else run into this? final class CardCell: UITableViewCell { private let cardView = UIView() override init(style: CellStyle, reuseIdentifier: String?) { super.init(style: style, reuseIdentifier: reuseIdentifier) cardView.backgroundColor = .white cardView.translatesAutoresizingMaskIntoConstraints = false contentView.addSubview(cardView) NSLayoutConstraint.activate([ cardView.topAnchor.constraint(equalTo: contentView.topAnchor), cardView.bottomAnchor.constraint(equalTo: contentView.bottomAnchor), cardView.leadingAnchor.constraint(equalTo: contentView.leadingAnchor), cardView.trailingAnchor.constraint(equalTo: contentView.trailingAnchor), ]) } required init?(coder: NSCoder) { fatalError() } } // Table: UITableView(style: .grouped), 3 sections, register CardCell. // Reproduce on iOS 26 with FKA on → Tab from section 0 leaves the table, // skipping every cell in sections 1+.

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 ?

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

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.