I'm developing with the following setup: Xcode 26.2 Minimum Deployment Target: iOS 15.0 Currently using AppDelegate only I have three questions: Screen Display on iPhone Duo From what I understand, when an app built with this configuration runs on iPhone Duo, the content appears in the center area while both sides show vertical empty bars. Does this layout stay the same when the device is rotated? Camera Rotation Behavior When I open the camera and rotate the device, does the camera view automatically rotate to match the device's rotation direction? UI Rendering Differences Between Xcode Versions If I build the same app with Xcode 27 and Xcode 26, and then install both versions on the same devices (regular iPhone and iPhone Duo), are there any differences in how the UI is drawn? If there are differences, does this mean the UI rendering follows the build environment (Xcode version) rather than the runtime environment?

I have a UIBarButtonItem created with init(customView:). The custom view draws some content outside its own bounds (clipsToBounds = false). On iOS 26, that content is clipped to the item's Liquid Glass capsule all the time, both at rest and while the item is pressed. On iOS 27, the clipping is inconsistent. At rest, the content outside the custom view's bounds is fully visible. While I press the item, it gets clipped to the shape of the Liquid Glass bubble. When I let go, it's fully visible again. So the item's content changes shape during a touch. iOS 26.2, at rest: clipped to the capsule iOS 26.2, while pressed: clipped to the capsule iOS 27, at rest: not clipped, the overflowing content is visible iOS 27, while pressed: clipped to the bubble Reproduced on the iPhone Duo simulator (iOS 27.1) and an iPhone 18 Pro (iOS 27). On an iPhone 17 Pro simulator with iOS 26.2 the behavior is consistent. Filed as FB25001846. Steps: Put the view controller below in a UINavigationController and run it on iOS 27. Look at the right bar button item at rest: the yellow area is visible around the green button. Press and hold the button: the yellow area is clipped to the rounded bubble. Run the same code on iOS 26: the yellow area is never visible. final class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() title = "Clipping" view.backgroundColor = .systemBackground // A button used as the bar button item's custom view. let button = UIButton(type: .custom) button.backgroundColor = .systemGreen button.setTitle("Press me", for: .normal) button.setTitleColor(.white, for: .normal) button.addAction(UIAction { _ in print("Pressed") }, for: .touchUpInside) button.sizeToFit() let size = button.bounds.size // The custom view is exactly as big as the button, but draws a yellow background // that extends 12pt outside its bounds on every side. let customView = UIView() customView.clipsToBounds = false customView.translatesAutoresizingMaskIntoConstraints = false NSLayoutConstraint.activate([ customView.widthAnchor.constraint(equalToConstant: size.width), customView.heightAnchor.constraint(equalToConstant: size.height), ]) let overflow = UIView(frame: CGRect(origin: .zero, size: size).insetBy(dx: -12, dy: -12)) overflow.backgroundColor = .systemYellow customView.addSubview(overflow) customView.addSubview(button) navigationItem.rightBarButtonItem = UIBarButtonItem(customView: customView) } }

I inherited an App which was pulled of the AppStore some time ago. I want to revive the project as I am convinced that there’s an interest in it. I am not experienced in iOS development, let alone UIKit (or Swift). Project has been setup as a non-public GIT repo. The project needs to stay non-profit. MIT license. I have a domain where I will host the web page for help etc. All non-profit! About: UIKit with reference to add’l framework for mathematical calculations (a nice fellow from this community helped me out on this :). former name Multiplans (Internet Archives still has the old webpage). navigation app using exclusively offline maps. very basic functionality, focus on the important stuff while you’re exploring the outdoors. POI/Track management. lots of map formats supported. Todo: maintenance, replace deprecated functions. a few minor bugs. implement a couple of functions in track management (like splitting track segments).

Summary On iOS 27 the top scroll edge effect of a UITableView is sized around the UIRefreshControl as an edge element, but appears to key on the control's presence in the scroll view rather than its current height. After endRefreshing(), the control collapses to zero height but stays attached, and the effect region keeps reserving a refresh-control's worth of space. The first row stays blurred and dimmed even though it is scrolled fully clear of the navigation bar. Environment iOS 27 (beta), iPhone Xcode 27.0.0 Beta 4 UIKit, UITableView inside a UINavigationController Reproduces with the default edge effect style and with an explicit .soft Steps to reproduce Push a UITableViewController with a UIRefreshControl onto a navigation stack. Ensure content extends under the navigation bar (default for UITableViewController). Pull to refresh and let the refresh end. Observe the first row after the refresh control has retracted. Expected Once the control retracts, the edge effect returns to its pre-pull height and the first row renders crisply. Actual The region stays roughly one refresh-control height too tall and the first row stays blurred. Row positions are unaffected — content offset and adjustedContentInset are correct. Only the extent of the effect is wrong. It corrects itself on the next push/pop. Two probes that isolate it These narrow the cause to the control's presence rather than a general staleness: Re-assigning tableView.topEdgeEffect.style after endRefreshing(), including on a later runloop turn, does NOT correct the region. The style is not what is stale. Detaching the control DOES correct it immediately: tableView.refreshControl = nil So the region is measured from the control being in the hierarchy, and is never re-measured when the control merely collapses. Secondary issue A UIRefreshControl that has been detached is inert if the same instance is re-assigned: tableView.refreshControl = nil tableView.refreshControl = sameInstance // never triggers again A freshly constructed UIRefreshControl must be assigned instead. This is not documented and looks like a second bug. Minimal sample Attached. A UITableViewController with a refresh control and a "Push" bar button that pushes and pops an empty view controller, so the incorrect region and the post-navigation correction can be compared in one run. Related FB20756572 reports the same "edge-effect extent is stale until the next navigation" behaviour for UIScrollEdgeElementContainerInteraction sizing, and notes a change in iOS 27 seed 1. That report received no reply.

I've noticed a strange issue with the SceneDelegate lifecycle in iOS 27. [Environment] iOS 27 (Also tested on physical devices) UIKit / SceneDelegate based App [Description & Steps to Reproduce] When the app is in the foreground and the user locks the screen (presses the power button): In iOS 26 and earlier: sceneWillResignActive is called exactly once. (Expected behavior) In iOS 27: The following sequence is called rapidly in succession: sceneWillResignActive (Screen lock initiated) sceneDidBecomeActive sceneWillResignActive (Locks completely) When the user unlocks the screen later, sceneDidBecomeActive is called once as usual. [Impact] Because sceneDidBecomeActive is unexpectedly fired while the device is locking, it triggers foreground logics right before the app is pushed to the background. This is causing unwanted side-effects and glitches. Has anyone else encountered this unbalanced lifecycle issue in iOS 27? I'd like to know if there's a better approach or if Apple is aware of this. Thanks!

On the iPhone Duo's narrow display, the navigation bar's back button sits in the trailing column below the status bar. During an interactive swipe-back from a screen whose navigation bar is hidden to a screen whose navigation bar is visible, the back button briefly renders in the leading (top-left) position of the bar for one or more frames. In those same frames the trailing-column button is blank. It then jumps back to the trailing column. The result is a visible flicker. Steps to reproduce: Open the attached code in Xcode 27.1 and run it on the iPhone Duo simulator (iOS 27.1), using the narrow display in portrait. Tap "Push". This pushes a screen with a visible navigation bar. Tap "Push without header". This pushes a screen that hides the navigation bar. Slowly swipe back from the leading edge to return to the previous screen. Expected: the back button of the revealed navigation bar stays in the trailing column for the whole transition, the same as with a programmatic pop. Actual: for one or more frames during the gesture, the back button renders at the leading edge of the navigation bar (top-left), and the trailing column is blank. Then it returns to the trailing column. Repro: import UIKit @main final class AppDelegate: UIResponder, UIApplicationDelegate {} final class SceneDelegate: UIResponder, UIWindowSceneDelegate { var window: UIWindow? func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options: UIScene.ConnectionOptions) { guard let windowScene = scene as? UIWindowScene else { return } let window = UIWindow(windowScene: windowScene) let nav = SwipeableNavigationController(rootViewController: ScreenVC(title: "header 0", showsHeader: true)) window.rootViewController = nav window.makeKeyAndVisible() self.window = window // Auto sequence when launched with `-auto YES`: push header, push no header, pop. guard UserDefaults.standard.bool(forKey: "auto") else { return } DispatchQueue.main.asyncAfter(deadline: .now() + 1.5) { nav.pushViewController(ScreenVC(title: "header 0", showsHeader: true), animated: true) } DispatchQueue.main.asyncAfter(deadline: .now() + 3.0) { nav.pushViewController(ScreenVC(title: "no header", showsHeader: false), animated: true) } DispatchQueue.main.asyncAfter(deadline: .now() + 4.5) { nav.popViewController(animated: true) } } } final class ScreenVC: UIViewController { private let showsHeader: Bool init(title: String, showsHeader: Bool) { self.showsHeader = showsHeader super.init(nibName: nil, bundle: nil) self.title = title } required init?(coder: NSCoder) { fatalError() } override func viewWillAppear(_ animated: Bool) { super.viewWillAppear(animated) navigationController?.setNavigationBarHidden(!showsHeader, animated: animated) } override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .systemGroupedBackground let push = UIButton(configuration: .plain(), primaryAction: UIAction(title: "Push") { [weak self] _ in self?.navigationController?.pushViewController(ScreenVC(title: "header 0", showsHeader: true), animated: true) }) let pushNoHeader = UIButton(configuration: .plain(), primaryAction: UIAction(title: "Push without header") { [weak self] _ in self?.navigationController?.pushViewController(ScreenVC(title: "no header", showsHeader: false), animated: true) }) let back = UIButton(configuration: .plain(), primaryAction: UIAction(title: "Go back") { [weak self] _ in self?.navigationController?.popViewController(animated: true) }) let stack = UIStackView(arrangedSubviews: [push, pushNoHeader, back]) stack.axis = .vertical stack.translatesAutoresizingMaskIntoConstraints = false view.addSubview(stack) NSLayoutConstraint.activate([ stack.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor, constant: 10), stack.centerXAnchor.constraint(equalTo: view.centerXAnchor), ]) } } final class SwipeableNavigationController: UINavigationController, UIGestureRecognizerDelegate { override func viewDidLoad() { super.viewDidLoad() interactivePopGestureRecognizer?.delegate = self if #available(iOS 26.0, *) { interactiveContentPopGestureRecognizer?.delegate = self } } func gestureRecognizerShouldBegin(_ gestureRecognizer: UIGestureRecognizer) -> Bool { viewControllers.count > 1 } } Thank you in advance!

Summary: On iOS 26, UISwitch has a Liquid Glass dynamic highlight/shadow effect that is not clipped by an ancestor view's bounds, even inside a UIModalPresentationFormSheet card. This is visible in two ways: (1) a plain tap on a switch positioned near the form sheet's edge already shows the highlight/shadow rendering outside the card's rounded border; (2) pressing and dragging the finger away from the switch drags this effect along with the touch, and it can end up rendered far outside the form sheet, well past the presentation area. Steps to Reproduce: Run the attached minimal project on an iOS 26 device/simulator. Tap "Present Form Sheet" to present a UIModalPresentationFormSheet containing a UITableView, with a UISwitch near the trailing edge of each row. Simply tap a switch near the sheet's edge — notice the dynamic highlight/shadow already overflows past the form sheet's rounded border. Now press and hold a switch, then quickly swipe/drag the finger downward (or in any direction) without lifting — notice the highlight/shadow follows the finger and gets dragged far outside the form sheet's bounds, over the dimmed presentation background. Expected Results: The Liquid Glass dynamic highlight/shadow effect should be clipped to the bounds of the form sheet card at all times, whether triggered by a plain tap or a drag gesture. Actual Results: On a plain tap near the edge: the highlight/shadow already overflows just past the form sheet's rounded border, unclipped. On press-and-drag: the highlight/shadow follows the finger and can be dragged far outside the form sheet — well beyond the card's edges and the presentation area. Configuration: iOS 26.x simulator/device Xcode 26.x // LiquidGlassSwitchDemo // // Minimal repro: UISwitch's Liquid Glass transition effect (iOS 26) is not // clipped by a UIModalPresentationFormSheet card, which clips everything else. // #import "AppDelegate.h" // Form sheet content: a table view full of UISwitch cells. @interface WMSwitchGlassCardViewController : UIViewController <UITableViewDataSource> @end @implementation WMSwitchGlassCardViewController - (void)viewDidLoad { [super viewDidLoad]; self.preferredContentSize = CGSizeMake(320, 400); UITableView *tableView = [[UITableView alloc] initWithFrame:self.view.bounds style:UITableViewStyleInsetGrouped]; tableView.dataSource = self; tableView.autoresizingMask = UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight; [self.view addSubview:tableView]; } - (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section { return 8; } - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath { UITableViewCell *cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:@"cell"]; cell.textLabel.text = [NSString stringWithFormat:@"Option %ld", (long)indexPath.row + 1]; UISwitch *toggle = [[UISwitch alloc] init]; toggle.on = YES; cell.accessoryView = toggle; // Actual: while toggling, the glass glow/shadow renders outside the form // sheet's rounded corners and floats over the dimmed background — the // card's clipsToBounds / rounded corners have no effect on the effect. return cell; } @end // Root screen: a single button that presents the card above as a form sheet. @interface WMRootViewController : UIViewController @end @implementation WMRootViewController - (void)viewDidLoad { [super viewDidLoad]; self.view.backgroundColor = UIColor.systemBackgroundColor; UIButton *button = [UIButton buttonWithType:UIButtonTypeSystem]; [button setTitle:@"Present Form Sheet" forState:UIControlStateNormal]; [button addTarget:self action:@selector(presentCard) forControlEvents:UIControlEventTouchUpInside]; button.translatesAutoresizingMaskIntoConstraints = NO; [self.view addSubview:button]; [NSLayoutConstraint activateConstraints:@[ [button.centerXAnchor constraintEqualToAnchor:self.view.centerXAnchor], [button.centerYAnchor constraintEqualToAnchor:self.view.centerYAnchor], ]]; } - (void)presentCard { UIViewController *card = [WMSwitchGlassCardViewController new]; card.modalPresentationStyle = UIModalPresentationFormSheet; [self presentViewController:card animated:YES completion:nil]; } @end @implementation AppDelegate - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { self.window = [[UIWindow alloc] initWithFrame:UIScreen.mainScreen.bounds]; self.window.rootViewController = [WMRootViewController new]; [self.window makeKeyAndVisible]; return YES; } @end```

Summary: On iOS 26, UISwitch has a Liquid Glass dynamic highlight/shadow effect that is not clipped by an ancestor view's bounds, even inside a UIModalPresentationFormSheet card. This is visible in two ways: (1) a plain tap on a switch positioned near the form sheet's edge already shows the highlight/shadow rendering outside the card's rounded border; (2) pressing and dragging the finger away from the switch drags this effect along with the touch, and it can end up rendered far outside the form sheet, well past the presentation area. Steps to Reproduce: Run the attached minimal project on an iOS 26 device/simulator. Tap "Present Form Sheet" to present a UIModalPresentationFormSheet containing a UITableView, with a UISwitch near the trailing edge of each row. Simply tap a switch near the sheet's edge — notice the dynamic highlight/shadow already overflows past the form sheet's rounded border. Now press and hold a switch, then quickly swipe/drag the finger downward (or in any direction) without lifting — notice the highlight/shadow follows the finger and gets dragged far outside the form sheet's bounds, over the dimmed presentation background. Expected Results: The Liquid Glass dynamic highlight/shadow effect should be clipped to the bounds of the form sheet card at all times, whether triggered by a plain tap or a drag gesture. Actual Results: On a plain tap near the edge: the highlight/shadow already overflows just past the form sheet's rounded border, unclipped. On press-and-drag: the highlight/shadow follows the finger and can be dragged far outside the form sheet — well beyond the card's edges and the presentation area. Configuration: iOS 26.x simulator/device Xcode 26.x // AppDelegate.m // LiquidGlassSwitchDemo // // Minimal repro: UISwitch's Liquid Glass transition effect (iOS 26) is not // clipped by a UIModalPresentationFormSheet card, which clips everything else. // #import "AppDelegate.h" // Form sheet content: a table view full of UISwitch cells. @interface WMSwitchGlassCardViewController : UIViewController <UITableViewDataSource> @end @implementation WMSwitchGlassCardViewController - (void)viewDidLoad { [super viewDidLoad]; self.preferredContentSize = CGSizeMake(320, 400); UITableView *tableView = [[UITableView alloc] initWithFrame:self.view.bounds style:UITableViewStyleInsetGrouped]; tableView.dataSource = self; tableView.autoresizingMask = UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight; [self.view addSubview:tableView]; } - (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section { return 8; } - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath { UITableViewCell *cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:@"cell"]; cell.textLabel.text = [NSString stringWithFormat:@"Option %ld", (long)indexPath.row + 1]; UISwitch *toggle = [[UISwitch alloc] init]; toggle.on = YES; cell.accessoryView = toggle; // Actual: while toggling, the glass glow/shadow renders outside the form // sheet's rounded corners and floats over the dimmed background — the // card's clipsToBounds / rounded corners have no effect on the effect. return cell; } @end // Root screen: a single button that presents the card above as a form sheet. @interface WMRootViewController : UIViewController @end @implementation WMRootViewController - (void)viewDidLoad { [super viewDidLoad]; self.view.backgroundColor = UIColor.systemBackgroundColor; UIButton *button = [UIButton buttonWithType:UIButtonTypeSystem]; [button setTitle:@"Present Form Sheet" forState:UIControlStateNormal]; [button addTarget:self action:@selector(presentCard) forControlEvents:UIControlEventTouchUpInside]; button.translatesAutoresizingMaskIntoConstraints = NO; [self.view addSubview:button]; [NSLayoutConstraint activateConstraints:@[ [button.centerXAnchor constraintEqualToAnchor:self.view.centerXAnchor], [button.centerYAnchor constraintEqualToAnchor:self.view.centerYAnchor], ]]; } - (void)presentCard { UIViewController *card = [WMSwitchGlassCardViewController new]; card.modalPresentationStyle = UIModalPresentationFormSheet; [self presentViewController:card animated:YES completion:nil]; } @end @implementation AppDelegate - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { self.window = [[UIWindow alloc] initWithFrame:UIScreen.mainScreen.bounds]; self.window.rootViewController = [WMRootViewController new]; [self.window makeKeyAndVisible]; return YES; } @end``` ![]("https://developer.apple.com/forums/content/attachment/3f8e87c4-d99f-4c03-adf8-b2c12a54aa8d" "title=20260928-151703@2x.png;width=666;height=644") ![]("https://developer.apple.com/forums/content/attachment/602ca9f8-c604-4168-9242-17d74c93b644" "title=20260928-151745@2x.png;width=544;height=396")

I have an iOS app that supports multiple scenes on the iPad, and which has an "Open in Another Window" feature which creates a new window scene. I would like to bring this feature to the iPhone Duo. On the iPhone Duo, of course, creating new windows is only supported when the device is open; when it is closed, creating new windows does not work. (If you try, an error is thrown.) Until now, the way I have checked whether my "Open in Another Window" feature should be available is to check to see if UIApplication.shared.supportsMultipleScenes is true. This has always returned false for previous iPhones and true for iPads. Unfortunately, however, this does not work as expected on the iPhone Duo. On the Duo, I would expect supportsMultipleScenes to return true when the device is open, but false when it is closed. This is not the case: it returns true for all poses. (Filed as #FB24948411 as this doesn't seem right to me.) So it does not help me decide whether the feature should be available. UIWindowScene.ActivationAction does work as expected when used in a menu, with the action auto-hiding when the Duo is in the closed pose. In my app, though, I need more than just an auto-hiding menu item; I need to check whether creating a new window is currently possible for certain UI availability decisions. What, then, is the correct way of checking this, if it's not with supportsMultipleScenes? Given that UIWindowScene.ActivationAction is able to hide itself, I assume there is some better way of checking that I have missed.

Sometime pre-iOS 26 it was possible to use a SplitViewController so that on iPhone you saw the master as a side menu (e.g. hamburger), and the detail full screen. While on iPad you would see the master displayed in a sidebar that could be closed, with the detail fullscreen. This has changed, using a SplitViewController on iPhone now forces you into having 2 fullscreen screens, with a push/pop layout and a back button. In situations where you want the detail screen to open first, this results in users opening the app to find a back button already presented, despite having not navigated anywhere. They must "return" to a screen they never saw. I really despise this layout and find it to be quite a UX issue. But given the new iPhone Duo, using the SplitViewController is now one of the easiest ways to maintain the necessary responsiveness needed, forcing us to accept this behaviour on regular iPhones. Can we PLEASE get the old functionality back, where we can explicitly state on iPhone that the master will always be displayed as a menu?

Environment App built with Xcode 26.3 (iOS 26 SDK) Deployment Target: iOS 16+ Issue occurs only on devices upgraded to iOS 27. Works perfectly on iOS 26.x. Problem description: After end‑user upgrades their iPhone to iOS 27, a persistent stale frosted‑glass / blur rendering effect appears at the top area of screens. This symptom occurs both on native UITableView and inside WKWebView. No blur‑related code (UIVisualEffectView / backdrop‑filter) is added by our application. Layout frames, insets and contentOffset are all correct. Reproduction hints: The issue can be triggered after presenting then dismissing a WKWebView which loads H5 with overlay popup. Rendering state seems to leak to the whole app process. The leftover blur remains until push/pop the view controller. Is this an iOS 27 system bug, or do we need special adaptation for existing apps built with older Xcode 26.3 SDK? What is the proper workaround for apps compiled with Xcode26.3, since liquidGlassEffectEnabled is only available in iOS27 SDK and cannot be accessed in our current build environment.

Tested on iPhone Duo with iOS 27.1 in Xcode 27.1 Beta Presented VC returns .disabled from preferredVerticalBarBehavior. With UISheetPresentationController, the sheet's trailing safe-area inset is removed at all detents (including default medium and large, plus custom detents at various fixed heights). The interesting part: the status bar remains in the vertical bar for detents below UISheetPresentationControllerDetentResolutionContext.maximumDetentValue, but at detents that are greater than or equal to that maximumDetentValue, the status bar moves to the top. With a custom UIPresentationController: Default shouldPresentInFullscreen == true: trailing inset remains, regardless of presented VC's preferredVerticalBarBehavior (possibly expected) With shouldPresentInFullscreen == false: trailing inset is removed, but the status bar moves to the top regardless of the presented view's height. Using automatic as preferredVerticalBarBehavior keeps the status bar on the right, but also keeps the safe-area insets increased. Is UISheetPresentationController applying detent-aware, presentation-scoped vertical bar behavior? Is there a public way for a custom UIPresentationController to remove the sheet's vertical-bar inset while keeping the status bar vertical [until the presentation reaches full height]?

Hi,I'm trying to implement undo and redo, in a Custom keyboard extension. However, calling undo() on the UndoManager from UIInputViewController, doesn't seems to work. Is there any other way of getting the UndoManager from the app the keyboard is connected to?Or do I need create my own logic to store what a user has written?

Group Labs are a unique opportunity for the community to submit questions directly to a panel of Apple engineers and designers. Here are the highlights from the iPhone Duo Group Labs: How should apps preserve navigation and UI state when switching between the inner and outer displays? Treat display transitions as size-class and trait changes, not a scene disconnect or app termination; your process stays alive. For more information, see Prepare your app for iPhone Duo. For state that must survive a scene disconnect/reconnect, implement stateRestorationActivity(for:) to save an NSUserActivity Restoring your app's state. Do multiple instances of the same app on iPhone Duo share UserDefaults/@AppStorage state? Multiple instances of your app's UI on iPhone Duo behave similarly to multi-window support on iPadOS. To learn more, see Leverage multiple displays and scenes on iPhone Duo. Both UserDefaults and AppStorage are app-wide, not per-window, stores. If a full-screen app on the inner display is closed, does it move to the outer display or get backgrounded? iPhone Duo honors UIRequiresFullScreen and apps adapt in place as the device opens and closes rather than backgrounding. To learn more, watch Prepare your app for iPhone Duo. How should apps preserve state — text input, scroll position, video playback, camera sessions — during hinge angle transitions? For example, when a LazyVGrid's column count changes because the device folds, does SwiftUI preserve scroll position automatically, or should you use scrollPosition(id:)? The system generally preserves text input and scroll position automatically since hinge angle changes are represented as size-class and trait updates, not a scene disconnect or app termination. This applies even to cases like a LazyVGrid column-count change triggered by opening or closing the device — apps typically don't need to manually manage scroll position with scrollPosition(id:anchor:) for this transition. For more info, see Prepare your app for iPhone Duo. How can apps preserve what someone is doing when switching displays or folding/unfolding? Treat this as a resize/trait-change event, not app teardown — your process keeps running as size classes change. See Prepare your app for iPhone Duo to learn more. For scenes that actually disconnect and reconnect, implement stateRestorationActivity(for:) to save an NSUserActivity Restoring your app's state. How does actively playing video behave through the hinge angle animation? The system generally preserves video playback and player position automatically since hinge angle changes are represented as size-class and trait updates, not a scene disconnect or app termination. AVKit will scale and resize the video automatically. If a user folds or unfolds the device mid-checkout, what does the system preserve automatically, and what should the app manage itself to avoid lost input or duplicate requests? When someone opens or closes an iPhone Duo, the system represents this as a size-class and trait collection change, not a scene disconnect or app teardown, so in-memory state like input fields typically persists automatically since the app’s process keeps running. For more info, see Prepare your app for iPhone Duo. How should apps handle the keyboard and text input when the device folds or unfolds while typing? As iPhone Duo folds or unfolds, the available screen geometry and framing change. Ensure your app adopts standard layout controls, containers, and size classes to handle resizability gracefully across all poses. When a text field becomes first responder, the system automatically shows the keyboard and binds its input to the text field. Because the appearance of the keyboard has the potential to obscure portions of your user interface, you should update your interface as needed to ensure that the text field being edited remains visible. Use keyboard notifications such as keyboardWillShowNotification, keyboardWillHideNotification, and keyboardWillChangeFrameNotification to detect the appearance and disappearance of the keyboard and to make necessary changes to your interface layout. To learn more, see UITextField. If someone is typing and closes iPhone Duo, does the keyboard/editing session survive the hinge transition, or does it get a new scene? When a user types and closes iPhone Duo, the active editing session and keyboard do not get a completely new scene. Instead, the app undergoes a dynamic resizing and transitions from the inner display to the compact outer display, maintaining the existing scene and application state. For more info, watch Prepare your app for iPhone Duo.

Hi everyone, We are validating our existing legacy UIKit application on iPhone Duo, built using Xcode26 and the iOS26 SDK. Our app follows the classic AppDelegate‑only pattern. We do not adopt UIApplicationSceneManifest or SceneDelegate, so it runs under the system’s legacy compatibility container window. The codebase still heavily uses UIScreen.main, and we have not yet adopted UIWindowScene. Full scene‑based migration is planned for Xcode27, but we need to ship builds with Xcode26 for now and expect reasonable compatibility on iPhone Duo hardware. Most of our application UI displays correctly inside this system‑provided compatibility window. However we noticed a critical positioning defect for system‑owned permission alerts. System‑rendered authorization dialogs (push notification permission, photo library access, location permission — these are drawn by the system process, not our app) are positioned relative to the full physical inner display of iPhone Duo. Instead of centering within our app’s compatibility‑mode container viewport, these permission pop‑ups appear offset and misaligned against our app’s visible window bounds. I have three key questions: Is this mis‑positioning of system permission alerts expected documented behavior for non‑Scene, AppDelegate‑only legacy apps running inside compatibility mode on iPhone Duo when built with Xcode26 SDK? While we remain on Xcode26 SDK, before completing full scene‑based lifecycle migration for Xcode27: are there any known workarounds to correct or mitigate this system permission alert offset issue? Or is this a hard limitation of the legacy compatibility mode in Xcode26, meaning we cannot fix it until we fully migrate to scene‑based app lifecycle? If this is intended limitation, could anyone point me to official Apple documentation that covers this exact behavior for legacy apps on iPhone Duo? Thanks for any insight.

Description: When wrapping a UIKit UIScrollView in SwiftUI via UIViewControllerRepresentable, applying topEdgeEffect.style = .hard, then using .toolbar() and .ignoresSafeArea(.container) on the SwiftUI view causes an incorrect/truncated initial height of Navigation Bar on first load. The height will refresh to the correct value after backgrounding the app or switching tabs. Steps to Reproduce: Wrap a UICollectionViewController in UIViewControllerRepresentable. Set collectionView.topEdgeEffect.style = .hard. Embed it in a SwiftUI NavigationStack and apply .toolbar() and .ignoresSafeArea() Happens on Xcode 26.x and iOS 26.x (untested on 27s).

[Submitted as FB21958289] A minimal SwiftUI app logs framework warnings when a bottom bar Menu is used with the system search toolbar item. The most severe issue is logged as a console Fault (full logs below): Adding 'UIKitToolbar' as a subview of UIHostingController.view is not supported and may result in a broken view hierarchy. Add your view above UIHostingController.view in a common superview or insert it into your SwiftUI content in a UIViewRepresentable instead. This appears to be a framework-level SwiftUI/UIKit integration issue, not custom UIKit embedding in app code. The UI may still render, but the warnings indicate an internal hierarchy/layout conflict. This occurs in simulator and physical device. REPRO STEPS Create a new project then replace ContentView with the code below. Run the app. The view uses NavigationStack + .searchable + .toolbar with: ToolbarItem(placement: .bottomBar) containing a Menu DefaultToolbarItem(kind: .search, placement: .bottomBar) EXPECTED RESULT No view hierarchy or Auto Layout warnings in the console. ACTUAL RESULT Console logs warnings such as: "Adding 'UIKitToolbar' as a subview of UIHostingController.view is not supported..." "Ignoring searchBarPlacementBarButtonItem because its vending navigation item does not match the view controller's..." "Unable to simultaneously satisfy constraints..." (ButtonWrapper/UIButtonBarButton width and trailing constraints) MINIMAL REPRO CODE import SwiftUI struct ContentView: View { @State private var searchText = "" @State private var isSearchPresented = false var body: some View { NavigationStack { List(0..<30, id: \.self) { index in Text("Row \(index)") } .navigationTitle("Toolbar Repro") .searchable(text: $searchText, isPresented: $isSearchPresented) .toolbar { ToolbarItem(placement: .bottomBar) { Menu { Button("Action 1") { } Button("Action 2") { } } label: { Label("Actions", systemImage: "ellipsis.circle") } } DefaultToolbarItem(kind: .search, placement: .bottomBar) } } } } CONSOLE LOG Adding 'UIKitToolbar' as a subview of UIHostingController.view is not supported and may result in a broken view hierarchy. Add your view above UIHostingController.view in a common superview or insert it into your SwiftUI content in a UIViewRepresentable instead. Ignoring searchBarPlacementBarButtonItem because its vending navigation item does not match the view controller's. view controller: <_TtGC7SwiftUI32NavigationStackHostingControllerVS_7AnyView_: 0x106014c00>; vc's navigationItem = <UINavigationItem: 0x105530320> title='Toolbar Repro' style=navigator searchController=0x106131200 SearchBarHidesWhenScrolling-default; vending navigation item <UINavigationItem: 0x106db4270> style=navigator searchController=0x106131200 SearchBarHidesWhenScrolling-explicit Unable to simultaneously satisfy constraints. Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. ( "<NSLayoutConstraint:0x600002171450 _TtC5UIKitP33_DDE14AA6B49FCAFC5A54255A118E1D8713ButtonWrapper:0x106a31fe0.width == _UIButtonBarButton:0x106dc4010.width (active)>", "<NSLayoutConstraint:0x6000021558b0 'IB_Leading_Leading' H:|-(8)-[_UIModernBarButton:0x106a38010] (active, names: '|':_UIButtonBarButton:0x106dc4010 )>", "<NSLayoutConstraint:0x600002170eb0 'IB_Trailing_Trailing' H:[_UIModernBarButton:0x106a38010]-(8)-| (active, names: '|':_UIButtonBarButton:0x106dc4010 )>", "<NSLayoutConstraint:0x60000210aa80 'UIView-Encapsulated-Layout-Width' _TtC5UIKitP33_DDE14AA6B49FCAFC5A54255A118E1D8713ButtonWrapper:0x106a31fe0.width == 0 (active)>" ) Will attempt to recover by breaking constraint <NSLayoutConstraint:0x600002170eb0 'IB_Trailing_Trailing' H:[_UIModernBarButton:0x106a38010]-(8)-| (active, names: '|':_UIButtonBarButton:0x106dc4010 )> Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger. The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKitCore/UIView.h> may also be helpful. Failed to send CA Event for app launch measurements for ca_event_type: 0 event_name: com.apple.app_launch_measurement.FirstFramePresentationMetric Failed to send CA Event for app launch measurements for ca_event_type: 1 event_name: com.apple.app_launch_measurement.ExtendedLaunchMetrics

Hi, We are testing our legacy UIKit app on iPhone Duo, built with Xcode26 / iOS26 SDK. Important background: Our app is pure AppDelegate‑only, we do NOT adopt UIApplicationSceneManifest / SceneDelegate, runs in legacy compatibility mode. Codebase heavily uses UIScreen.main everywhere, no UIWindowScene adoption yet. We are in progress to adopt full iPhone Duo compatibility with Xcode27. For now, we need to ship builds using Xcode26 SDK and expect reasonable compatibility on iPhone Duo hardware. The system already provides legacy compatibility container window for our app. Most of our app UI renders correctly inside the system compatibility window on iPhone Duo. Problems we observed under Xcode26 build on iPhone Duo: System‑rendered permission alerts (push‑notification permission, photo library, location authorization dialog, drawn by system process) are centered relative to the full physical inner display, NOT centered inside our app’s compatibility‑mode window. The alert position is mis‑aligned with our app viewport. The system UINavigationBar layout offset issue: When running inside legacy compatibility window, system‑provided UINavigationBar calculates its top position against full physical screen safe‑area instead of the app compatibility container’s safe‑area. As a result, navigation bar appears too close to the top edge, mis‑aligned with the actual status‑bar area inside our app window. My questions: Are above two issues (system permission alert mis‑position, UINavigationBar safe‑area offset) the expected defined behavior for legacy non‑Scene apps running in compatibility mode on iPhone Duo when built with Xcode26 SDK? When staying on Xcode26 SDK (before we complete Xcode27 & scene‑based lifecycle migration): Is there any workaround we can apply to mitigate these two issues? Or are these limitations unavoidable under Xcode26 / legacy compatibility mode and we can only accept current behavior until we fully migrate to scene‑based lifecycle? 3. If these are expected limitations: is there any official documentation that explicitly describes these behaviours for legacy apps on iPhone Duo? Thank you.

Thank you very much for your detailed response and valuable recommendations. At this stage, our application is still built using Xcode 26 and the iOS 26 SDK. Our primary priority right now is to validate runtime behavior for our existing binary running on iPhone Duo. We fully understand that full‑featured support for iPhone Duo requires Xcode 27 plus Scene lifecycle adoption, and we plan to implement those adaptations incrementally in future releases. What we want to clarify specifically: aside from the expected black bars introduced by system compatibility mode, do our existing patterns raise functional bugs or layout risks on iPhone Duo when built with Xcode 26? The legacy patterns we are concerned about are: Window creation via init(frame:), where frame is derived from UIScreen.main.bounds, without adopting SceneDelegate lifecycle. Manual non‑AutoLayout layouts that read UIScreen.main.bounds directly to obtain view width. Whether viewWillTransitionToSize:withTransitionCoordinator: will still fire on fold/unfold state changes under this Xcode‑26‑built compatibility mode. We would like to distinguish which of these usages must be fixed even for our Xcode‑26‑built release, versus which ones are safely handled by system compatibility and can remain unchanged for the time being. We are trying to decide whether urgent compatibility patches are required for our current Xcode 26 build. Thank you again for your support.

iOS Version: iOS 27 Beta Xcode: Xcode27 Beta 2 I have a custom UITabBar subclass. The tab bar items are visible and selectable, and the selected state works, but the title color in the normal state is always rendered as white, even though I set a different normal title color. Simplified code let normalColor = UIColor.gray let selectedColor = UIColor.orange let bgColor = UIColor.black let font = UIFont.systemFont(ofSize: 10, weight: .semibold) let appearance = UITabBarAppearance() appearance.configureWithOpaqueBackground() appearance.backgroundEffect = nil appearance.backgroundColor = bgColor appearance.shadowColor = .clear let itemAppearance = appearance.stackedLayoutAppearance itemAppearance.normal.titleTextAttributes = [ .font: font, .foregroundColor: normalColor ] itemAppearance.selected.titleTextAttributes = [ .font: font, .foregroundColor: selectedColor ] itemAppearance.normal.iconColor = normalColor itemAppearance.selected.iconColor = selectedColor appearance.stackedLayoutAppearance = itemAppearance appearance.inlineLayoutAppearance = itemAppearance appearance.compactInlineLayoutAppearance = itemAppearance tabBar.standardAppearance = appearance if #available(iOS 15.0, *) { tabBar.scrollEdgeAppearance = appearance } tabBar.backgroundColor = bgColor tabBar.isTranslucent = false The problem: The selected title/icon color works. The normal title color is ignored and stays white. This happens after moving to the newer tab bar appearance behavior / Liquid Glass environment. Question: Is there any additional configuration required for UITabBarAppearance so that the normal UITabBarItem title color is respected? Could unselectedItemTintColor, tintColor, scrollEdgeAppearance, or Liquid Glass behavior override normal.titleTextAttributes?