Construct and manage graphical, event-driven user interfaces for iOS or tvOS apps using UIKit.

UIKit Documentation

Posts under UIKit subtopic

Post

Replies

Boosts

Views

Activity

UITableView row reordering no longer works under macOS 27 with Mac Catalyst
Under macOS 27 using Mac Catalyst for a UIKit-based app, If you present a view controller with a table view as a form sheet or page sheet, row reordering fails to function. You can drag a row as expected but the blue movement bar never appears and if you drop the row it simply returns to its original location. The exact same view controller presented as a popover works just fine. The exact same view controller not presented as a modal (such as the app's root controller) works just fine. This is a serious bug affecting existing applications and being reported by paying customers. This has been reported as FB25038883 which includes a simple sample app demonstrating the issue.
2
0
413
1d
State Restoration no longer works in a Mac Catalyst based app when run on macOS 27.x
As reported in FB25363417: A UIKit based app running on macOS 27.2 (or macOS 27.0.1) via Mac Catalyst no longer has functioning state restoration. Upon app restart, there is no NSUserActivity being provided to the scene in the UISceneDelegate method scene(_:willConnectTo:options:). This can be tested with Apple’s own sample app “Restoring your app’s state”. Just update the sample project with support for a Mac Catalyst build. Using Xcode 27.2 on a Mac with macOS 27.0 or 27.2, build and run the Mac Catalyst version of the app. The main screen appears with a list of products. Select any product so you see details of the product. Quit the app. Run the app again. Note that you are not returned to the previously selected product detail screen. Instead, you just see the main list of products. If you run the same app and perform the same steps on a Mac running macOS 26.x, then when the app is restarted, you correctly get returned to the previously selected product detail screen. The problem is being caused by no NSUserActivity being passed into the scene delegate on app startup. While running the app on a Mac with macOS 27.x, put a breakpoint on the initial guard statement in scene(_:willConnectTo:options:) and you will see there is no activity on app restart. This is impacting paid customers of my existing app since upgrading to macOS 27. They no longer get returned to the app’s previous state when restarting the app. It is expected that state restoration should work on macOS 27 just as well as it does under macOS 26 in an app built with Mac Catalyst.
0
0
75
1d
UIKIt, iOS 27, UIDocumentPickerViewController(forExporting: [fileURL])
My App saves files using the UIDocumentPickerViewController. This works from iOS 17 to 26. Usually, you have a file with a given name in your sandbox, which you can then export via the pickerVC. In the pickerVC you change the name. In iOS 27 the file name is greyed-out and you can't change it here. The file can be exported only with the pre-given name. Is this a new behaviour or bug in iOS 27?
Topic: UI Frameworks SubTopic: UIKit
0
0
83
1d
UITextContentType.cellularIMEI works on iOS 27+ only
During testing, we found that IMEI AutoFill behaves differently by iOS version, independent of the entitlement, and would like to confirm the expected behavior. 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 for your support.
1
0
86
2d
UIKit snapshot views render empty into UIImage on physical devices, but work in Simulator
Is there a supported way to convert the cached contents of a UIKit snapshot view into a UIImage on physical iOS/iPadOS devices? A view returned by snapshotView(afterScreenUpdates:) displays correctly on hardware, but drawing that view into a UIGraphicsImageRenderer produces no cached-content pixels. drawHierarchy(in:afterScreenUpdates:) still returns true. The same base experiment succeeds in Simulator. Feedback Assistant report: FB25336445. A standalone reproducer and measurements are attached there; use the corrected replica-readback-ios-27.0.1-fixed-project.zip attachment. Tested environments Physical iPhone 15 Pro Max: iOS 27.0.1 (24A446). Physical iPad mini (6th generation): iPadOS 26.6.1 (23G83). Two independent app launches produced identical measurements. Simulator: iPhone 18 Pro / iOS 27.0 and iPhone 15 Pro Max / iOS 26.1. The app is a standalone UIKit Release build, launched without a debugger or XCTest. It uses an ordinary red UIView and a white UILabel: no WebKit, Liquid Glass, video, secure text fields, third-party libraries, or private API calls. I have not tested a physical iPhone on the 26 series or iOS 27.0.2. The Simulator and device OS patch versions differ, so this is not a controlled OS-only comparison. Reproduction Display a red 240 x 160 UIView containing a white UILabel; allow it to render. Draw the original view into an image as a positive control. Call source.snapshotView(afterScreenUpdates: false), attach the replica to the window at the source frame, wait 500 ms, hide the original, then wait another 500 ms. Draw the attached replica into transparent and cyan-prefilled image contexts. Add an ordinary red 30 x 30 child UIView to the replica, wait 500 ms, and capture again. Repeat with replicas from UIWindow.snapshotView and UIScreen.snapshotView. This is the capture operation, called on the main actor after those waits: func rasterize(_ target: UIView, cyanBackground: Bool) -> UIImage { let format = UIGraphicsImageRendererFormat() format.scale = 1 format.opaque = false return UIGraphicsImageRenderer(size: target.bounds.size, format: format) .image { context in if cyanBackground { UIColor.cyan.setFill() context.fill(target.bounds) } let success = target.drawHierarchy( in: target.bounds, afterScreenUpdates: true ) print("drawHierarchy:", success) } }Results On both physical devices: The original 240 x 160 UIView renders normally: all 38,400 pixels are nontransparent. The replica on a transparent target produces zero nontransparent pixels. The replica on a cyan target leaves all 38,400 pixels cyan. Adding an ordinary child view produces approximately 900 red pixels, but the replica's cached contents are still missing. UIView, UIWindow and UIScreen replicas all exhibit the omission, while drawHierarchy returns true. In both tested Simulators, the base experiment renders the replica contents and overwrites the cyan background. The child-marker addition was tested on physical devices only. These counts are measured from the CGImage before PNG encoding. Thus “black output” with an opaque context appears to be missing content, not pixels painted black: transparent and cyan targets retain their original contents. Questions Is bitmap readback of these snapshot views supported on physical devices, or are they only intended for on-screen composition? If unsupported, is the Simulator behavior expected, and why does drawHierarchy return success despite omitting the visible cached contents? Is there a supported API to materialize those cached contents as an image, without starting a screen-recording session? Capturing the original view directly is a useful control, but does not answer how to read back an already-created snapshot. I found this older AVSampleBufferDisplayLayer discussion, which also describes a correctly displayed snapshot view becoming black when converted to an image. My reproducer uses only ordinary UIKit views; I do not know whether the underlying cause is related.
Topic: UI Frameworks SubTopic: UIKit
5
0
338
2d
Where can we find the official WWDC session / sample code for adopting the foldable iPhone (this generation's Duo hardware)?
We've been reverse-engineering behavior from the Simulator device profile alone. Is there a WWDC session, updated UIKit/SwiftUI documentation, or sample project specifically covering foldable iPhone adoption (window/scene handling, size-class behavior, collection/table view sizing, and the fold-posture API surface) that we should be building against instead of inferring behavior empirically?
Topic: UI Frameworks SubTopic: UIKit
1
0
88
2d
Is UIScreen.main.bounds valid on iPhone Duo?
During a fold, UIScreen.main.bounds stays at the outer-display size while window.windowScene?.screen.bounds updates. Layout that still reads UIScreen.main (sheet heights, map padding, title widths) is wrong on the inner display. Should apps stop using UIScreen.main entirely and always read the window scene’s screen?
Topic: UI Frameworks SubTopic: UIKit
2
0
277
2d
iPhone Duo supports multiple windows but `requestSceneSessionDestruction` fails due to unsupported device idiom
Problem: iPhone Duo supports multiple windows using Split Views. However, we cannot programmatically close windows using requestSceneSessionDestruction because we get the following error: "This functionality is not supported for this device idiom." This seems like a miss in Apple's requestSceneSessionDestruction implementation. If the Duo is going to let users open multiple windows (where supportsMultipleScenes is true for the Duo), then developers should be able to close them via requestSceneSessionDestruction, too. 🤔 Is this a bug? I have filed a ticket here in case it is: FB25353479 Additional implementation details: Our app supports multiple windows on iPad devices. The Duo is the first phone to support multiple windows as well. For user convenience, our app has an option to combine information from all windows and then collapse everything down to one single window. We use requestSceneSessionDestruction to close the extraneous windows afterward. This works great on iPad, but we get the unsupported device idiom error on the Duo only. We have no way of closing windows programmatically as far as I can tell.
Topic: UI Frameworks SubTopic: UIKit Tags:
2
0
75
2d
iPad: How to prevent the new floating decimalPad when using a keyboard toolbar (iPadOS 26)
On iPad running iOS 26, UIKeyboardType.decimalPad sometimes appears as a floating keypad (compact panel) instead of the docked, full-width keyboard. Our app attaches a custom toolbar via inputAccessoryView, so the floating keypad hides the toolbar and breaks the flow. We’d like to opt out of the floating keypad or force the keyboard to remain docked when a toolbar is present. Environment Device: iPad (multiple models) OS: iPadOS 26.0 App type: UIKit Field: UITextField with keyboardType = .decimalPad We present a custom toolbar via inputAccessoryView Expected Docked (full-width) keyboard so the inputAccessoryView toolbar is visible and sized correctly. Actual A floating decimal keypad appears and covers content; our accessory toolbar isn’t visible/attached to it. Why this matters Our toolbar contains required domain actions (Done/Next, Previous). When the keypad floats, the user loses these controls. Questions Is there a supported way to opt out of the floating numeric keypad on iPad when using decimalPad? Is there an API/trait to prefer docked keyboard (e.g., when an inputAccessoryView is present)?
Topic: UI Frameworks SubTopic: UIKit Tags:
4
0
925
2d
Setting UITextContentType.cellularIMEI works differently on iOS 27 and others
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.
0
0
38
2d
iOS 27.2 regression: WKWebView loses left/right safe-area margins and status bar affects layout on physical devices
# 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`
Topic: UI Frameworks SubTopic: UIKit
0
3
154
3d
Bottom accessory has incorrect width and position after changing orientation on iPhone Duo
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!
Topic: UI Frameworks SubTopic: UIKit Tags:
1
0
422
3d
iPhone Duo: vanishing vertical toolbars; odd nav bar behavior.
Two things I've seen using the iPhone Duo simulator. I'm updating a venerable Objective-C app that dates back to iOS 4, but has been updated to be perfectly functional and appearance-appropriate on iOS 26. I'm building using the 21.1 beta SDK in Xcode 27.1 beta. TL;DR version: (1) my toolbar items vanish in vertical mode except while being tapped or dragged; and (2) the nav bar has an opaque, fixed background even as its title scrolls with underlying content. Has anyone else seen these oddities, and any ideas as to how I can fix 'em? First, with the Duo opened and taller than wide, the nav and tab bars in my app appear horizontally, as I would expect them to. But in any other pose or orientation, the bars adopt a vertical display, and aside from the left edge, their items are invisible: When I tap or drag on them, they become visible: When I stop tapping or dragging, they vanish again. Why do the vertical items go invisible, and how can I keep 'em always visible? Second, my scrolling view lies under the nav bar (in z-order) but extends to the top of the screen. If I scroll the view, it moves up onscreen, behind the opaque nav bar, although the nav bar's title scrolls up, too: If I go "far enough", the title scrolls off completely and the view's contents are visible full-height, but with the nav bar's background remaining. If I don't scroll that far, the title reappears when I stop, and the area above the nav bar goes opaque white, too, covering the content: Is it possible to disable the scrolling behavior on the nav bar title? (I'll just position my scrolling view to start below it spatially.) Alternatively, how can I turn off the background opacity? I've tried setting the background to clearColor and opacity to false... nav.navigationBar.backgroundColor = [UIColor clearColor]; nav.navigationBar.opaque = false; ...but these had no effect. Help me Obi-Wan Kenobi, you're my only hope...
Topic: UI Frameworks SubTopic: UIKit
7
0
1.6k
3d
Vertical tab bar doesn't appear when tab bar controller is added to view controller while iPhone Duo is unfolded
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.
Topic: UI Frameworks SubTopic: UIKit Tags:
5
0
792
3d
Best Practice to adopt iPhone Duo
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.
3
0
462
4d
UISheetPresentationController issues on iPhone Duo
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?
5
1
799
4d
Custom Navigation Item
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?
Topic: UI Frameworks SubTopic: UIKit
2
0
368
4d
iPhone Duo vertical bar: system back button ignores custom back indicator image (UINavigationBarAppearance.setBackIndicatorImage)
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.
Topic: UI Frameworks SubTopic: UIKit Tags:
1
1
367
4d
Hinge listeners don't work in Keyboard Extension on iPhone Duo (iOS 27.1)
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
4
1
892
5d
Back button with custom title goes blank and unresponsive when collapsed multiple times on iOS 27
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?
Topic: UI Frameworks SubTopic: UIKit Tags:
1
2
216
5d
UITableView row reordering no longer works under macOS 27 with Mac Catalyst
Under macOS 27 using Mac Catalyst for a UIKit-based app, If you present a view controller with a table view as a form sheet or page sheet, row reordering fails to function. You can drag a row as expected but the blue movement bar never appears and if you drop the row it simply returns to its original location. The exact same view controller presented as a popover works just fine. The exact same view controller not presented as a modal (such as the app's root controller) works just fine. This is a serious bug affecting existing applications and being reported by paying customers. This has been reported as FB25038883 which includes a simple sample app demonstrating the issue.
Replies
2
Boosts
0
Views
413
Activity
1d
State Restoration no longer works in a Mac Catalyst based app when run on macOS 27.x
As reported in FB25363417: A UIKit based app running on macOS 27.2 (or macOS 27.0.1) via Mac Catalyst no longer has functioning state restoration. Upon app restart, there is no NSUserActivity being provided to the scene in the UISceneDelegate method scene(_:willConnectTo:options:). This can be tested with Apple’s own sample app “Restoring your app’s state”. Just update the sample project with support for a Mac Catalyst build. Using Xcode 27.2 on a Mac with macOS 27.0 or 27.2, build and run the Mac Catalyst version of the app. The main screen appears with a list of products. Select any product so you see details of the product. Quit the app. Run the app again. Note that you are not returned to the previously selected product detail screen. Instead, you just see the main list of products. If you run the same app and perform the same steps on a Mac running macOS 26.x, then when the app is restarted, you correctly get returned to the previously selected product detail screen. The problem is being caused by no NSUserActivity being passed into the scene delegate on app startup. While running the app on a Mac with macOS 27.x, put a breakpoint on the initial guard statement in scene(_:willConnectTo:options:) and you will see there is no activity on app restart. This is impacting paid customers of my existing app since upgrading to macOS 27. They no longer get returned to the app’s previous state when restarting the app. It is expected that state restoration should work on macOS 27 just as well as it does under macOS 26 in an app built with Mac Catalyst.
Replies
0
Boosts
0
Views
75
Activity
1d
UIKIt, iOS 27, UIDocumentPickerViewController(forExporting: [fileURL])
My App saves files using the UIDocumentPickerViewController. This works from iOS 17 to 26. Usually, you have a file with a given name in your sandbox, which you can then export via the pickerVC. In the pickerVC you change the name. In iOS 27 the file name is greyed-out and you can't change it here. The file can be exported only with the pre-given name. Is this a new behaviour or bug in iOS 27?
Topic: UI Frameworks SubTopic: UIKit
Replies
0
Boosts
0
Views
83
Activity
1d
UITextContentType.cellularIMEI works on iOS 27+ only
During testing, we found that IMEI AutoFill behaves differently by iOS version, independent of the entitlement, and would like to confirm the expected behavior. 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 for your support.
Replies
1
Boosts
0
Views
86
Activity
2d
UIKit snapshot views render empty into UIImage on physical devices, but work in Simulator
Is there a supported way to convert the cached contents of a UIKit snapshot view into a UIImage on physical iOS/iPadOS devices? A view returned by snapshotView(afterScreenUpdates:) displays correctly on hardware, but drawing that view into a UIGraphicsImageRenderer produces no cached-content pixels. drawHierarchy(in:afterScreenUpdates:) still returns true. The same base experiment succeeds in Simulator. Feedback Assistant report: FB25336445. A standalone reproducer and measurements are attached there; use the corrected replica-readback-ios-27.0.1-fixed-project.zip attachment. Tested environments Physical iPhone 15 Pro Max: iOS 27.0.1 (24A446). Physical iPad mini (6th generation): iPadOS 26.6.1 (23G83). Two independent app launches produced identical measurements. Simulator: iPhone 18 Pro / iOS 27.0 and iPhone 15 Pro Max / iOS 26.1. The app is a standalone UIKit Release build, launched without a debugger or XCTest. It uses an ordinary red UIView and a white UILabel: no WebKit, Liquid Glass, video, secure text fields, third-party libraries, or private API calls. I have not tested a physical iPhone on the 26 series or iOS 27.0.2. The Simulator and device OS patch versions differ, so this is not a controlled OS-only comparison. Reproduction Display a red 240 x 160 UIView containing a white UILabel; allow it to render. Draw the original view into an image as a positive control. Call source.snapshotView(afterScreenUpdates: false), attach the replica to the window at the source frame, wait 500 ms, hide the original, then wait another 500 ms. Draw the attached replica into transparent and cyan-prefilled image contexts. Add an ordinary red 30 x 30 child UIView to the replica, wait 500 ms, and capture again. Repeat with replicas from UIWindow.snapshotView and UIScreen.snapshotView. This is the capture operation, called on the main actor after those waits: func rasterize(_ target: UIView, cyanBackground: Bool) -> UIImage { let format = UIGraphicsImageRendererFormat() format.scale = 1 format.opaque = false return UIGraphicsImageRenderer(size: target.bounds.size, format: format) .image { context in if cyanBackground { UIColor.cyan.setFill() context.fill(target.bounds) } let success = target.drawHierarchy( in: target.bounds, afterScreenUpdates: true ) print("drawHierarchy:", success) } }Results On both physical devices: The original 240 x 160 UIView renders normally: all 38,400 pixels are nontransparent. The replica on a transparent target produces zero nontransparent pixels. The replica on a cyan target leaves all 38,400 pixels cyan. Adding an ordinary child view produces approximately 900 red pixels, but the replica's cached contents are still missing. UIView, UIWindow and UIScreen replicas all exhibit the omission, while drawHierarchy returns true. In both tested Simulators, the base experiment renders the replica contents and overwrites the cyan background. The child-marker addition was tested on physical devices only. These counts are measured from the CGImage before PNG encoding. Thus “black output” with an opaque context appears to be missing content, not pixels painted black: transparent and cyan targets retain their original contents. Questions Is bitmap readback of these snapshot views supported on physical devices, or are they only intended for on-screen composition? If unsupported, is the Simulator behavior expected, and why does drawHierarchy return success despite omitting the visible cached contents? Is there a supported API to materialize those cached contents as an image, without starting a screen-recording session? Capturing the original view directly is a useful control, but does not answer how to read back an already-created snapshot. I found this older AVSampleBufferDisplayLayer discussion, which also describes a correctly displayed snapshot view becoming black when converted to an image. My reproducer uses only ordinary UIKit views; I do not know whether the underlying cause is related.
Topic: UI Frameworks SubTopic: UIKit
Replies
5
Boosts
0
Views
338
Activity
2d
Where can we find the official WWDC session / sample code for adopting the foldable iPhone (this generation's Duo hardware)?
We've been reverse-engineering behavior from the Simulator device profile alone. Is there a WWDC session, updated UIKit/SwiftUI documentation, or sample project specifically covering foldable iPhone adoption (window/scene handling, size-class behavior, collection/table view sizing, and the fold-posture API surface) that we should be building against instead of inferring behavior empirically?
Topic: UI Frameworks SubTopic: UIKit
Replies
1
Boosts
0
Views
88
Activity
2d
Is UIScreen.main.bounds valid on iPhone Duo?
During a fold, UIScreen.main.bounds stays at the outer-display size while window.windowScene?.screen.bounds updates. Layout that still reads UIScreen.main (sheet heights, map padding, title widths) is wrong on the inner display. Should apps stop using UIScreen.main entirely and always read the window scene’s screen?
Topic: UI Frameworks SubTopic: UIKit
Replies
2
Boosts
0
Views
277
Activity
2d
iPhone Duo supports multiple windows but `requestSceneSessionDestruction` fails due to unsupported device idiom
Problem: iPhone Duo supports multiple windows using Split Views. However, we cannot programmatically close windows using requestSceneSessionDestruction because we get the following error: "This functionality is not supported for this device idiom." This seems like a miss in Apple's requestSceneSessionDestruction implementation. If the Duo is going to let users open multiple windows (where supportsMultipleScenes is true for the Duo), then developers should be able to close them via requestSceneSessionDestruction, too. 🤔 Is this a bug? I have filed a ticket here in case it is: FB25353479 Additional implementation details: Our app supports multiple windows on iPad devices. The Duo is the first phone to support multiple windows as well. For user convenience, our app has an option to combine information from all windows and then collapse everything down to one single window. We use requestSceneSessionDestruction to close the extraneous windows afterward. This works great on iPad, but we get the unsupported device idiom error on the Duo only. We have no way of closing windows programmatically as far as I can tell.
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
2
Boosts
0
Views
75
Activity
2d
iPad: How to prevent the new floating decimalPad when using a keyboard toolbar (iPadOS 26)
On iPad running iOS 26, UIKeyboardType.decimalPad sometimes appears as a floating keypad (compact panel) instead of the docked, full-width keyboard. Our app attaches a custom toolbar via inputAccessoryView, so the floating keypad hides the toolbar and breaks the flow. We’d like to opt out of the floating keypad or force the keyboard to remain docked when a toolbar is present. Environment Device: iPad (multiple models) OS: iPadOS 26.0 App type: UIKit Field: UITextField with keyboardType = .decimalPad We present a custom toolbar via inputAccessoryView Expected Docked (full-width) keyboard so the inputAccessoryView toolbar is visible and sized correctly. Actual A floating decimal keypad appears and covers content; our accessory toolbar isn’t visible/attached to it. Why this matters Our toolbar contains required domain actions (Done/Next, Previous). When the keypad floats, the user loses these controls. Questions Is there a supported way to opt out of the floating numeric keypad on iPad when using decimalPad? Is there an API/trait to prefer docked keyboard (e.g., when an inputAccessoryView is present)?
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
4
Boosts
0
Views
925
Activity
2d
Setting UITextContentType.cellularIMEI works differently on iOS 27 and others
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.
Replies
0
Boosts
0
Views
38
Activity
2d
iOS 27.2 regression: WKWebView loses left/right safe-area margins and status bar affects layout on physical devices
# 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`
Topic: UI Frameworks SubTopic: UIKit
Replies
0
Boosts
3
Views
154
Activity
3d
Bottom accessory has incorrect width and position after changing orientation on iPhone Duo
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!
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
1
Boosts
0
Views
422
Activity
3d
iPhone Duo: vanishing vertical toolbars; odd nav bar behavior.
Two things I've seen using the iPhone Duo simulator. I'm updating a venerable Objective-C app that dates back to iOS 4, but has been updated to be perfectly functional and appearance-appropriate on iOS 26. I'm building using the 21.1 beta SDK in Xcode 27.1 beta. TL;DR version: (1) my toolbar items vanish in vertical mode except while being tapped or dragged; and (2) the nav bar has an opaque, fixed background even as its title scrolls with underlying content. Has anyone else seen these oddities, and any ideas as to how I can fix 'em? First, with the Duo opened and taller than wide, the nav and tab bars in my app appear horizontally, as I would expect them to. But in any other pose or orientation, the bars adopt a vertical display, and aside from the left edge, their items are invisible: When I tap or drag on them, they become visible: When I stop tapping or dragging, they vanish again. Why do the vertical items go invisible, and how can I keep 'em always visible? Second, my scrolling view lies under the nav bar (in z-order) but extends to the top of the screen. If I scroll the view, it moves up onscreen, behind the opaque nav bar, although the nav bar's title scrolls up, too: If I go "far enough", the title scrolls off completely and the view's contents are visible full-height, but with the nav bar's background remaining. If I don't scroll that far, the title reappears when I stop, and the area above the nav bar goes opaque white, too, covering the content: Is it possible to disable the scrolling behavior on the nav bar title? (I'll just position my scrolling view to start below it spatially.) Alternatively, how can I turn off the background opacity? I've tried setting the background to clearColor and opacity to false... nav.navigationBar.backgroundColor = [UIColor clearColor]; nav.navigationBar.opaque = false; ...but these had no effect. Help me Obi-Wan Kenobi, you're my only hope...
Topic: UI Frameworks SubTopic: UIKit
Replies
7
Boosts
0
Views
1.6k
Activity
3d
Vertical tab bar doesn't appear when tab bar controller is added to view controller while iPhone Duo is unfolded
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.
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
5
Boosts
0
Views
792
Activity
3d
Best Practice to adopt iPhone Duo
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.
Replies
3
Boosts
0
Views
462
Activity
4d
UISheetPresentationController issues on iPhone Duo
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?
Replies
5
Boosts
1
Views
799
Activity
4d
Custom Navigation Item
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?
Topic: UI Frameworks SubTopic: UIKit
Replies
2
Boosts
0
Views
368
Activity
4d
iPhone Duo vertical bar: system back button ignores custom back indicator image (UINavigationBarAppearance.setBackIndicatorImage)
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.
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
1
Boosts
1
Views
367
Activity
4d
Hinge listeners don't work in Keyboard Extension on iPhone Duo (iOS 27.1)
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
Replies
4
Boosts
1
Views
892
Activity
5d
Back button with custom title goes blank and unresponsive when collapsed multiple times on iOS 27
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?
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
1
Boosts
2
Views
216
Activity
5d