Hi everyone, I'm experiencing a significant difference in SwiftUI layout behavior between the iPhone Duo simulator and a physical iPhone Duo. I've already adjusted my layout to work correctly in the simulator, but the same app behaves differently on the actual device. 1. Folded Simulator: The tab bar is positioned on the right side, as expected for iPhone Duo. The view respects the right-side layout, and scroll views extend naturally behind the tab bar, behaving as expected. Physical device: The tab bar appears at the bottom, like a regular iPhone, instead of on the right. The view is also cropped on the right side. 2. Unfolded Simulator: The tab bar and navigation view both appear correctly. Physical device: The tab bar remains at the bottom, even in landscape orientation, instead of using the expected Duo layout. The main content also starts from the bottom of the navigation view, resulting in an incorrect layout. The most confusing part is that the layout works correctly in the simulator but not on the physical device. Has anyone encountered this behavior on a physical iPhone Duo? Could this be related to the iOS version, SDK version, SwiftUI's automatic tab bar adaptation, or a device-specific bug? I'd appreciate any insights, especially from developers who have tested their SwiftUI apps on actual iPhone Duo hardware. Environment: Xcode version: 27.1 iOS SDK: 27.1 Physical device iOS version: 27.2 Thanks!

During testing, we found that IMEI AutoFill behaves differently by iOS version, independent of the entitlement, and would like to confirm the expected behavior. TL;DR Setting UITextContentType.cellularIMEI works on iOS 27 without any entitlement while not on prior verisons. is it expected behaviour? Test details Implementation: textContentType = .cellularIMEI on the IMEI input field Entitlement status: no carrier-related entitlements in the test build Observed results iOS 27: The IMEI AutoFill suggestion appears and works in any app, regardless of carrier entitlement. iOS 26 and earlier: The IMEI AutoFill suggestion does not appear. Questions Is it the expected and intended behavior that, on iOS 27, IMEI AutoFill is available to any app without a carrier entitlement? On iOS versions earlier than 27 (iOS 17.4 to 26), is the public cellular plan entitlement required for IMEI AutoFill to work? If not, are there other conditions or requirements? On dual-IMEI devices, which IMEI (IMEI or IMEI2) is filled when .cellularIMEI is used on iOS 27? Should we use .cellularIMEI1 / .cellularIMEI2 to specify it explicitly? Thank you in advance.

Description: The time scale values on the battery usage curve in macOS 27 are displayed incorrectly. The screenshot timestamp is 14:39:11, October 20. Under the "Last 24 Hours" tab for Battery Level and Screen On Time charts, the timeline shows usage extending past 21:00 on October 20. This timestamp does not match the actual current time. It appears the timeline axis failed to shift correctly as time progresses. For comparison: a reference screenshot captured on macOS 26 at 09:30, August 8. Its battery usage timeline rendered correctly. The bottom time span covered August 7 to August 8, which is the expected and proper display behavior. This bug only exists in macOS 27’s battery usage chart. The older macOS 26 implementation works correctly. Device: MacBook Air M5 macOS version: macOS 27.2 RC

If my NSDocument.canConcurrentlyReadDocuments(ofType:) implementation returns true, often when launching the app, an untitled document is created regardless whether another document is restored. If document reading is not concurrent, an untitled document is only created when no other document is restored, as expected. The issue happens on most app launches when a document is restored. If the restored document takes long to load (which can be simulated by putting sleep(1) in the Document.read(from:ofType:) implementation), the issue always happens. Is this expected, or is there a workaround? I created FB25340015.

# iOS 27.2 regression: WKWebView loses left/right safe-area margins and status bar affects layout on physical devices ## Description After upgrading a physical iPhone to iOS 27.2, my Ionic Angular application running on Cordova no longer renders correctly. The left and right black areas that were previously visible along the screen edges have disappeared, and the iOS status bar (time, network connectivity, and battery) is now visible in a way that affects the app's layout. Some UI components are consequently shifted from their expected positions. For example, some of the header components are pushed as the status bar starts to appear(status bar does not show on iOS 27.1 or lower) **The same app works correctly on iOS 27.1 on the same device.** The problem only appears after upgrading to iOS 27.2. Interestingly, I cannot reproduce the issue in the iOS simulator, even when running the same app on the iOS 27.2 simulator. So far, the issue appears to affect physical devices only. ## Expected behavior The app should retain its previous layout, including the black areas on the left and right edges(safe area view). The status bar and safe-area handling should remain consistent with the behavior on iOS 27.1, without unexpectedly shifting UI components. ## Actual behavior - The black areas on the left and right edges disappear. - The iOS status bar becomes visible and appears to affect the page layout. - Some UI components are shifted from their expected positions. - The issue occurs on a physical device running iOS 27.2 but cannot currently be reproduced in the simulator. ## Current configuration My `config.xml` contains: ```xml <preference name="StatusBarOverlaysWebView" value="false" /> ``` My viewport meta tag is: ```html <meta name="viewport" content="viewport-fit=cover, width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0, user-scalable=no"> ``` I am using Ionic Angular with Cordova and an embedded iOS WebView. ## Steps to reproduce 1. Install and launch the app on a physical iPhone running iOS 27.1. 2. Observe that the layout and left/right black areas render as expected. 3. Upgrade the same device to iOS 27.2. 4. Launch the same app build. 5. Observe that the black areas disappear and the status bar/layout behavior changes. The issue has not been reproduced in the simulator. ## Questions 1. Has there been a change in iOS 27.2 affecting `WKWebView` safe-area insets, viewport sizing, or status-bar layout? 2. Could the native WebView frame or safe-area handling behave differently on physical devices compared with the simulator? 3. Is there a known workaround that does not require upgrading `cordova-ios`? 4. Is this more likely to be an iOS/WebKit regression or an incompatibility with the Cordova StatusBar plugin? I would appreciate any guidance on how to diagnose or work around this issue. I can provide screenshots from iOS 27.1 and 27.2, as well as additional diagnostics, if helpful. ## Environment - Framework: Ionic Angular - Platform: Cordova iOS - Affected OS: iOS 27.2 - Previously working OS: iOS 27.1 - Device: iPhone (physical device; exact model to be provided) - Simulator: Issue not reproducible - `StatusBarOverlaysWebView`: `false` - Viewport: `viewport-fit=cover`

Hi, I would like to share an issue with the bottom accessory on iPhone Duo (iOS 27.1 beta 1). When the device is rotated from landscape to portrait and back to landscape, the bottom accessory shrinks and is no longer centered between the edge of the screen and the vertical tab bar. Steps to reproduce: Create UITabBarController with a regular UIView set as bottom accessory Open the app on iPhone Duo in unfolded landscape orientation Rotate the device to portrait and back to landscape The bottom accessory is smaller than prior to the orientation changes and isn’t centered between the edge of the device and the vertical tab bar anymore Set the accessory to nil and back to restore initial width Expected: Bottom accessory keeps its width across orientation changes Actual: Width of the bottom accessory changes after orientation changes (landscape -> portrait -> landscape). I’m using Xcode 27.1 beta and iOS 27.1 beta SDK (24A94403). I submitted a report via Feedback Assistant, here is the report ID: FB25002243. In the report I attached a minimal reproduction example and a video recording of the bug. Here is the minimal reproduction example: // SceneDelegate.swift import UIKit class SceneDelegate: UIResponder, UIWindowSceneDelegate { var window: UIWindow? func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { guard let windowScene = (scene as? UIWindowScene) else { return } let window = UIWindow(windowScene: windowScene) window.rootViewController = TabBarControllerWithAccessory() window.makeKeyAndVisible() self.window = window } } // TabBarControllerWithAccessory.swift import UIKit class TabBarControllerWithAccessory: UITabBarController { override func viewDidLoad() { super.viewDidLoad() tabs = [ UITab(title: "First", image: UIImage(systemName: "1.circle"), identifier: "first") { _ in ScreenViewController() }, UITab(title: "Second", image: UIImage(systemName: "2.circle"), identifier: "second") { _ in ScreenViewController() }, ] bottomAccessory = UITabAccessory(contentView: AccessoryContentView()) } } class ScreenViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .systemBackground let mountButton = UIButton(configuration: .filled(), primaryAction: UIAction(title: "Mount") { [weak self] _ in self?.tabBarController?.bottomAccessory = UITabAccessory(contentView: AccessoryContentView()) }) let unmountButton = UIButton(configuration: .filled(), primaryAction: UIAction(title: "Unmount") { [weak self] _ in self?.tabBarController?.bottomAccessory = nil }) let stackView = UIStackView(arrangedSubviews: [mountButton, unmountButton]) stackView.axis = .vertical stackView.spacing = 16 stackView.translatesAutoresizingMaskIntoConstraints = false view.addSubview(stackView) NSLayoutConstraint.activate([ stackView.centerXAnchor.constraint(equalTo: view.centerXAnchor), stackView.centerYAnchor.constraint(equalTo: view.centerYAnchor), ]) } } class AccessoryContentView: UIView { private let widthLabel = UILabel() override init(frame: CGRect) { super.init(frame: frame) backgroundColor = .systemOrange widthLabel.translatesAutoresizingMaskIntoConstraints = false addSubview(widthLabel) NSLayoutConstraint.activate([ widthLabel.centerXAnchor.constraint(equalTo: centerXAnchor), widthLabel.centerYAnchor.constraint(equalTo: centerYAnchor), ]) } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } override func layoutSubviews() { super.layoutSubviews() let text = "\(bounds.width)" if widthLabel.text != text { widthLabel.text = text } } } Before: After: Thank you in advance!

Hi, I would like to share an issue with UITabBarController's vertical tab bar and iPhone Duo's unfolded pose. On iPhone Duo (27.2 beta 3), when tab bar controller is added to the view controller while in unfolded pose, the vertical tab bar doesn't appear unless the tab bar controller view's frame is set manually before adding it to the parent's view. Show any VC. Use unfolded Duo pose. After some time/on button press add a UITabBarController to it: (https://developer.apple.com/documentation/uikit/creating-a-custom-container-view-controller#Add-a-child-view-controller-programmatically-to-your-content) with Auto Layout constraints. Vertical tab bar does not appear. Fold and unfold the device. The tab bar appears. Expected: Tab bar appears after adding the UITabBarController in unfolded Duo pose. Actual: Tab bar does not appear after adding the UITabBarController in unfolded Duo pose. In Feedback Assistant report (FB25261013) I attached minimal reproduction example and recordings showing the different behavior in folded and unfolded poses and behavior with manual frame application fix (commented out in minimal reproduction example). Minimal reproduction example: // SceneDelegate.swift import UIKit class SceneDelegate: UIResponder, UIWindowSceneDelegate { var window: UIWindow? func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { guard let windowScene = (scene as? UIWindowScene) else { return } window = UIWindow(windowScene: windowScene) window?.rootViewController = ViewController() window?.makeKeyAndVisible() } } // ViewController.swift import UIKit class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .systemBackground let button = UIButton(configuration: .filled(), primaryAction: UIAction(title: "Show Tab Bar Controller") { [weak self] _ in self?.showTabBarController() }) button.translatesAutoresizingMaskIntoConstraints = false view.addSubview(button) NSLayoutConstraint.activate([ button.centerXAnchor.constraint(equalTo: view.centerXAnchor), button.centerYAnchor.constraint(equalTo: view.centerYAnchor), ]) } private func showTabBarController() { let tabBarController = UITabBarController() tabBarController.tabs = ["First", "Second", "Third"].map { title in UITab(title: title, image: UIImage(systemName: "circle"), identifier: title) { _ in let viewController = UIViewController() viewController.view.backgroundColor = .systemBackground return viewController } } addChild(tabBarController) // Uncomment to show the tab bar on the unfolded iPhone Duo. tabBarController.view.frame = view.bounds view.addSubview(tabBarController.view) tabBarController.view.translatesAutoresizingMaskIntoConstraints = false NSLayoutConstraint.activate([ tabBarController.view.topAnchor.constraint(equalTo: view.topAnchor), tabBarController.view.bottomAnchor.constraint(equalTo: view.bottomAnchor), tabBarController.view.leadingAnchor.constraint(equalTo: view.leadingAnchor), tabBarController.view.trailingAnchor.constraint(equalTo: view.trailingAnchor), ]) tabBarController.didMove(toParent: self) } } Thank you in advance.

What's the best practices to adopt iPhone Duo for a production UIKit app? What few things we need to consider during the development? "As long as we use auto layout, it should be fine" is this correct term for iPhone Duo? Meaning, as long as our app use proper auto layout, our app should be able to support iPhone Duo properly.

I have an App where I use the UISheetPresentationController to present a menu as a "drawer" (like the "FindMy" or "Maps") App. Because the sheet is presented over a map, I made the sheet semi-transparent/blurry, so the Map shines through, which looks nice. The sheet is using a UITableView with the "insetGroup" style, so the table cells have the nice rounded borders and there are margins to the sheet borders. When running the App on the iPhone Duo (Simulator) on the outer display, the tableView does no longer respect the "insetGroup" style, it is rendered like it would have the "plain" style, which destroys everything that look good. No rounded borders, no margins. However if I opt-out of the automatic "vertical toolbar behavior" (overriding preferredVerticalBarBehavior so it returns "disabled"), then everything looks great again, however then the sheet content might overlap with the sidebar icons and camera because it now covers the whole area up to the right screen border. Is this supposed to be this way (if yes, why?), is there a way to fix this, or do we have to wait for a bugfix within iOS 27.1? The tableview still claims to have the "insetGrouped" style, just it does not render this way. I did not see any similar issues under other circumstances. Only UISheetPresentationController seems to be affected by this. Is there a way to correctly detect if the App is running on an iPhone Duo, so we could use this detection to add workarounds for such issues?

Will the App Store surface apps that are optimised for iPhone Duo, for example a badge, a filter or editorial placement? And is "optimised" decided just by building against 27.1, or by something else? Will App Store Connect require dedicated iPhone Duo screenshots for the outer and inner displays?

Summary: With all Multitasking Gestures disabled and Full Screen Apps enabled, four/five-finger pinch or swipe gestures are still intercepted by the system and swallow all touch points, so the foreground app stops receiving touch input. This is most noticeable in games that rely on multi-finger controls. The issue has persisted from iPadOS 26.0 RC through 27.2 — over a year — and remains unfixed(open). Multiple Feedback reports have been marked Open without a fix. one related report was marked “Potential Fix Identified – For a Future OS Update” and later reverted. Environment: iPad running any iPadOS version from 26.0 RC through 27.2 Settings > Multitasking & Gestures > all gestures disabled Full Screen Apps enabled (not Stage Manager or windowed apps) Steps to Reproduce: On the above configuration, open any app (most noticeable in games). Perform a four-finger pinch, or a four/five-finger left/right swipe. Observe that all touch points are immediately swallowed by the system, and the foreground app stops receiving touch input. Expected Result: Since all multitasking gestures are disabled in Settings, four/five-finger gestures should not respond at all, and the app should continue receiving touch input normally. Actual Result: The system still intercepts touches in the gesture area, causing the app to lose touch input temporarily or persistently. In games that rely on multi-finger input, this effectively breaks controls. FB Number: FB24795986

If we have create a custom Navigation back item, while running on iPhone Duo simulator, we see it at normal position i.e. on screen's top left side. How can we move it to the safe area like when we use default back button?

On iPhone Duo (iOS 27.1), when UIKit moves a navigation controller's system back button into the vertical bar, the button always shows the system chevron. Every public API for customizing the back indicator image is ignored there, although the same configuration is honored in the horizontal (top) navigation bar. APIs tested (each one alone, on the second view controller of a UINavigationController stack, with no leftBarButtonItem): A. Nothing set (default). B. UINavigationBar.standardAppearance set to a UINavigationBarAppearance on which setBackIndicatorImage(_:transitionMaskImage:) was called. C. Same appearance assigned to all four UINavigationBar properties: standardAppearance, compactAppearance, scrollEdgeAppearance, compactScrollEdgeAppearance. D. Same appearance assigned to all four UINavigationItem properties of the pushed view controller: standardAppearance, compactAppearance, scrollEdgeAppearance, compactScrollEdgeAppearance. E. Legacy UINavigationBar.backIndicatorImage and UINavigationBar.backIndicatorTransitionMaskImage, with no appearance objects set. F. UINavigationBar.appearance() proxy: all four appearance properties, set before the navigation controller is created. G. UINavigationItem.backBarButtonItem of the previous view controller set to UIBarButtonItem(image:style:target:action:). H. Control: UINavigationItem.leftBarButtonItem set to UIBarButtonItem(image:style:target:action:) with the same image (axisBehavior left at .automatic). The marker image is UIImage(systemName: "arrow.uturn.backward"), so it cannot be mistaken for the system chevron. Results: Top navigation bar (iPhone 17 Pro iOS 27.0, and iPhone Duo open with portrait UI): B, C, D, E and F show the custom image. G shows the chevron followed by the image. Vertical bar (iPhone Duo closed; iPhone Duo open with landscape UI; also inside a UITabBarController with the tab bar hidden or visible): A through G all show the system chevron. Only H shows the custom image. At viewDidAppear, the app confirms that the configuration is in place: navigationBar.standardAppearance.backIndicatorImage is the marker image (B, C), navigationItem.standardAppearance is non-nil (D), and traitCollection.verticalBarEdge is .trailing. This contradicts the guidance given by an Apple Technology Evangelist in https://developer.apple.com/forums/thread/847875: "If you are only replacing the icon on the back button, you could use set the backIndicatorImage and maintain default system behavior. This would be the recommended approach." As things stand, the only way to show a custom back icon in the vertical bar is to replace the system back button with a leading item. That loses the system behavior that comes with it: UINavigationController.interactivePopGestureRecognizer, interactiveContentPopGestureRecognizer and the back-history menu.

Hi, I've discovered that my Keyboard Extension is unable to detect any hinge status update on iPhone Duo. I tired both UIKit and SwiftUI approach - nothing works. Is there any workaround to make it work? Reproducible demo: https://www.icloud.com/iclouddrive/0460exMJtAdRkpk8EDjb751nw Xcode 27.1 (27A9269) iOS 27.1 beta 1 (24A94401) I also created a bug report: FB24883137

Hi, it seems there's an issue with back button on iOS 27 when it has a custom title defined and the title is forced to collapse in runtime due to other items taking space in the header. I have the following setup in the header of the second screen in a stack: a back button that displays custom title and 2 rightBarButtonItems. There is a toggle that adds the third item to rightBarButtonItems or removes it. This forces to hide the back title or display it again. I expect the button to resize as needed and go back to previous state as needed, without flashing, and correctly respond to presses at all times. What actually happens: I repeat the action multiple times (up to 5 times should be enough), the back button goes blank and unresponsive. There is only the glass background present, which does correctly resize. I filed the issue in Feedback Assistant: ID FB24801640 Is there a way to workaround this?

I'm seeing a delayed appearance change when moving a row between two collections using the new SwiftUI reordering APIs. The data updates immediately, but the dragged row retains its source appearance throughout settling, then abruptly switches to its destination appearance about 0.9 seconds after the move callback. Environment Xcode 27.0 (27A266a), macOS 26.7 (25G229) iOS Simulator 27.0 (24A434), iPhone 17 Pro Feedback: FB25054984 These observations are from the original simulator tests. I haven't established whether the same behavior occurs on a physical device or a newer runtime. Structure and observed behavior The hierarchy is a ScrollView containing a LazyVStack with sections. Each section uses ForEach(...).reorderable(collectionID:), under one .reorderContainer(for:in:move:). A dragContainer supplies transferable items, with DragConfiguration(allowMove: true). The same item has a compact appearance inside a group and a wider card appearance when standalone. Moving it between those collections updates membership, order, and the state driving its appearance synchronously in the move callback. Item IDs remain stable. Drag a compact grouped row into the standalone collection. Drop it between two standalone rows. The model and live presentation state update immediately. The dropped row keeps the source appearance during settling, then snaps to the destination appearance approximately 0.9 seconds later. Moving it back shows the same behavior. Different row heights also cause adjacent rows to step when the appearance changes. Measured delays in the application's synthetic-data sandbox were approximately 930 ms out and 921 ms back in. What I've tried Removing role-dependent content identity. Moving into an already populated destination collection. Giving source and destination rows equal occupied height. Using identity transitions. Bypassing the app's drawer modifier. None removed the late appearance switch. Equal occupied height removed the displacement of adjacent rows, but not the delayed visual change. A comparison using custom drop handling updated the appearance promptly, but did not preserve native insertion-position reordering. The feedback contains the original video, relevant logs and before/after frames. I also have a reduced standalone project that builds, but its manual drag-and-drop reproduction hasn't yet been verified; the timings above are from the application's sandbox, not that standalone sample. Questions Is retaining the source row's appearance until after settling expected when moving between collections? Is there a supported API or recommended row structure that lets the destination appearance and geometry participate in the settling animation? Has anyone reproduced this on iOS 27, or found it fixed in a newer runtime? I'd like to keep native reordering without timed refreshes, container identity resets, or private APIs.

I have a macOS app with a WidgetKit widget extension, distributed two ways: a notarised Developer ID download, and a Mac App Store build (same bundle identifiers, same team, different signature). When a user replaces the Developer ID copy in /Applications with the store-signed copy, the desktop widget draws only the grey placeholder and never recovers. The app itself runs normally. What I saw (8 October 2026, macOS 27): An iMac had the Developer ID build 47 (version 1.6.3) in /Applications with the widget on the desktop. I installed build 48 (version 1.6.4), signed for the store, from TestFlight. It replaced the Developer ID copy in /Applications. The app worked. The large widget showed grey placeholder bars and no data, for at least five minutes. killall chronod in Terminal brought the widget back straight away. On a MacBook, updating from one TestFlight build to the next (builds 46, 47, 48) redrew the widget each time. So it is the change from a Developer ID signature to a store signature, not an ordinary update. What I think is happening, and would like confirmed or corrected: the widget process that was started from the Developer ID copy keeps running after the app is replaced, and the system refuses what it draws (or never asks it for a new timeline), while the widget gallery and desktop keep showing that process's placeholder. What I already do: The Developer ID build ships a small helper outside the sandbox that ends the old widget process after an update. The Mac App Store build cannot carry that helper. The widget extension compares the build number in its bundle's Info.plist on disk with the one it started with, and exits if they differ. This ran in the case above (the build numbers were 47 and 48) and did not clear the placeholder. I suspect the check only runs when the system asks the widget for a snapshot or timeline, and the system had stopped asking. I call WidgetCenter.shared.reloadAllTimelines() after the app writes new data. Questions: Is there a supported way for a sandboxed app (or its widget extension) to make the system replace or restart a widget process that belongs to an earlier, differently signed copy of the same app? Without a Terminal command, and without a helper outside the sandbox. Is it expected that chronod keeps the old extension process after the containing app is replaced by a copy with a different signing identity, and that the widget then stays on the placeholder? Is there a log subsystem or predicate that shows why the old extension process was kept, or what the system refused? Thank you.

On iPad, text in a web view is always rendered at the same font size regardless of device orientation, sidebar presence, and window resizing. The text simply reflows according to the available space, as you would expect. In comparison, there appears to be a bug in iPhone Duo (or the Duo simulator) that causes web views to scale inconsistently depending on device orientation, presense/absence of the sidebar, and inner vs. outer screens. For example, showing and hiding the sidebar causes text in a web view to be rendered at different sizes rather than reflowing the text. Likewise, switching between portrait and landscape orientations causes text to be rendered at different sizes rather than reflowing. This occurs with the modern WebPage APIs introduced in iOS 26 as well as the older WKWebView APIs. Is this a known bug on the iPhone Duo? Is it just a simulator problem? Are there any recommended workarounds? Here's a quick example: import SwiftUI import WebKit struct ContentView: View { let webPage = WebPage() var body: some View { NavigationStack { WebView(webPage) } .task { webPage.load(html: """ <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <title>Test page</title> </head> <body> <h1>This is a title</h1> <p>This is a paragraph.</p> </body> </html> """ ) } } }

Let's say we start with a fully open iPhone Duo. We then present a view controller as a form sheet or page sheet. If the device is then rotated between landscape and portrait, the view controller's viewWillTransition(to:with:) is called to reflect the change in size between orientations. So far so good. Now put the fully open Duo in landscape. Then partially close the Duo. The presented view controller will automatically move off to the left half of the screen to avoid the fold. That's expected. However, the view controller's viewWillTransition(to:with:) is NOT called in this case even though its size has changed. Does this seem like a bug or is this somehow expected? I have a particular view controller that needs to know its size has changed so it can make some adjustments. Other lifecycle methods such as viewDidLayoutSubviews are called but I'd prefer to have viewWillTransition(to:with:) called.

I have a destructive action exposed as a toolbar item, which might be collapsed into a ToolbarOverflowMenu. I'd present the delete confirmation as a confirmation dialog anchored to the button that triggered it. But when the action is inside the overflow menu, the menu item isn't a view I can anchor it to. What's the recommended pattern for the delete confirmation in that case? Is an alert the intended fallback, is there a supported way to anchor a confirmation dialog to a toolbar overflow item, or would you recommend a different approach altogether?