On macOS 27.0 (26A428), Apple silicon, a physical four-finger App Exposé swipe does not expose my active AppKit accessory application's windows, including its Settings window. Control–Down does. Filed as FB24919003. I narrowed the behavior down with a two-window AppKit probe and a main menu. In an automated comparison using the same synthetic system gesture sequence each time, .accessory selected the previously active regular application's windows, .regular selected the probe's windows, and switching back to .accessory restored the mismatch. A separately generated Control–Down selected the accessory probe correctly. I activated the other regular app and then reactivated the probe before each comparison. The probe comparison did not test physical finger recognition. The macOS release that introduced this behavior is unconfirmed. The sample below uses only public AppKit APIs and is simplified from the tested probe; it compiles but has not yet been live-tested. It has no gesture recognizers, event taps, global shortcuts, custom window subclasses, or AltTab implementation. Steps for a physical-trackpad comparison: Enable the four-finger downward App Exposé gesture and Control–Down for Application windows in System Settings. Launch the sample in accessory mode and leave both windows open. Click another regular app's window, then click the sample's first window. Swipe down. Record which app's windows appear, then press Escape. Repeat the other-app → sample activation sequence, press Control–Down, record the result, then press Escape. Choose Use regular mode, repeat the activation sequence, and test again. Choose Use accessory mode, repeat the activation sequence, and test again. Start each invocation with App Exposé closed. Reactivation after each mode change matters for the comparison. Apple's window-management guide presents the swipe and Control–Down as ways to show the current app's windows. Is there a supported configuration that makes an accessory app participate in the gesture path while preserving .accessory and avoiding a Dock icon? Has anyone compared this on macOS 26 and 27? The Feedback report contains the exact tested probe as well as this simplified source. Here is the complete simplified sample, using only public AppKit APIs. Save it as AccessoryExposeSample.swift: import Cocoa final class AppDelegate: NSObject, NSApplicationDelegate { private var windows = [NSWindow]() private let modeLabel = NSTextField(labelWithString: "Activation policy: accessory") func applicationDidFinishLaunching(_ notification: Notification) { installMenu() for index in 0..<2 { addWindow(index) } windows[0].makeKeyAndOrderFront(nil) NSApp.activate(ignoringOtherApps: true) } private func installMenu() { let menu = NSMenu() let item = NSMenuItem() let submenu = NSMenu(title: "AccessoryExposeSample") submenu.addItem(withTitle: "Quit AccessoryExposeSample", action: #selector(NSApplication.terminate(_:)), keyEquivalent: "q") item.submenu = submenu menu.addItem(item) NSApp.mainMenu = menu } private func addWindow(_ index: Int) { let window = NSWindow(contentRect: NSRect(x: 100 + index * 480, y: 240, width: 460, height: 280), styleMask: [.titled, .closable, .miniaturizable], backing: .buffered, defer: false) window.title = "Accessory Exposé Sample \(index + 1)" window.isReleasedWhenClosed = false let stack = NSStackView() stack.orientation = .vertical stack.spacing = 16 stack.frame = NSRect(x: 20, y: 20, width: 420, height: 240) if index == 0 { stack.addArrangedSubview(modeLabel) stack.addArrangedSubview(NSButton(title: "Use accessory mode", target: self, action: #selector(useAccessoryMode))) stack.addArrangedSubview(NSButton(title: "Use regular mode", target: self, action: #selector(useRegularMode))) } else { stack.addArrangedSubview(NSTextField(labelWithString: "Second ordinary titled window")) } let reminder = NSTextField(wrappingLabelWithString: "Before each test, click another regular app, then click this window. After changing modes, repeat that activation sequence. Compare a downward App Exposé swipe with Control–Down.") reminder.preferredMaxLayoutWidth = 400 stack.addArrangedSubview(reminder) window.contentView?.addSubview(stack) windows.append(window) window.orderFront(nil) } @objc private func useAccessoryMode() { setPolicy(.accessory) } @objc private func useRegularMode() { setPolicy(.regular) } private func setPolicy(_ policy: NSApplication.ActivationPolicy) { guard NSApp.setActivationPolicy(policy) else { modeLabel.stringValue = "Activation policy change failed" return } modeLabel.stringValue = policy == .accessory ? "Activation policy: accessory" : "Activation policy: regular" windows[0].makeKeyAndOrderFront(nil) NSApp.activate(ignoringOtherApps: true) } } let application = NSApplication.shared application.setActivationPolicy(.accessory) let delegate = AppDelegate() application.delegate = delegate application.run() To build a standalone app bundle with a matching Swift compiler and macOS SDK selected: mkdir -p AccessoryExposeSample.app/Contents/MacOS "$(xcrun --find swiftc)" -swift-version 5 -sdk "$(xcrun --sdk macosx --show-sdk-path)" AccessoryExposeSample.swift -o AccessoryExposeSample.app/Contents/MacOS/AccessoryExposeSample cat > AccessoryExposeSample.app/Contents/Info.plist <<'PLIST' <?xml version="1.0" encoding="UTF-8"?> <plist version="1.0"><dict> <key>CFBundleIdentifier</key><string>local.apple-feedback.accessory-expose-sample</string> <key>CFBundleExecutable</key><string>AccessoryExposeSample</string> <key>CFBundleName</key><string>AccessoryExposeSample</string> <key>CFBundlePackageType</key><string>APPL</string> <key>LSUIElement</key><true/> </dict></plist> PLIST open AccessoryExposeSample.app

This method on UIEvent gets you more touch positions, and I think it's useful for a drawing app, to respond with greater precision to the position of the Pencil stylus. Is there a similar thing in macOS, for mouse or tablet events? I found this property mouseCoalescingEnabled, but the docs there don't describe how to get the extra events.

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.

I think the title says it all.

is there any particular function (same as viewDidLayoutSubviews) which call when I'm opening duo on when my open app doing the task?

A NSCollectionLayoutSection can have background decorations, set through the decorationItems property. Currently these decorations will never overlap the horizontal safe area on iPhone Duo, causing my backgrounds to stop while the horizontal scrolling items keep going. iOS 27.1 build 24A94401 SDK version 24A94403

We have a UITableView where each row is a custom UITableViewCell embedding its own horizontally-paging UICollectionView (a "card" carousel — think 3 cards visible per row, one page at a time). Sizing is done the standard way via UICollectionViewDelegateFlowLayout: func collectionView(_ collectionView: UICollectionView, layout: UICollectionViewLayout, sizeForItemAt indexPath: IndexPath) -> CGSize { return CGSize(width: collectionView.frame.width, height: 213) } Symptom: On the iPhone Duo simulator, when the device is closed (cover screen, compact width), the row correctly shows the card sized to the screen. When we unfold it (inner display, regular width), the table row itself resizes to the new, much wider screen — but the card inside the embedded collection view stays stuck at its old (closed-state) width, leaving a large empty gap in the row. Folding back closed shows the same problem in reverse: the card stays sized for the wide screen and now overflows/clips. This does not happen on a normal iPhone/iPad rotation — UICollectionViewFlowLayout picks up the new width fine there. It only reproduces across the fold/unfold transition specificall

For GNU Taler, we defined a custom URL scheme: "taler://". We want to have a SwiftUI PasteButton in our app which is only active/enabled when the user copied a talerURI, but not for other URIs (such as https:// or mailto://). Currently we use PasteButton(supportedContentTypes: [.url]) { providers in which works, but is also enabled when the copied text is some other URI, not only for "taler://". Can we define a UTType ".taler" for PasteButton to check whether the pasteBoard has indeed a talerURI? How?

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]?

With the default mode of .automatic, the inner display shows a sidebar instead of a bottom tab bar. The sidebar draws UIKit’s dimming view over the selected view controller, which hides our map. We force mode = .tabBar on iOS 18. Is a bottom tab bar on the Duo inner display supported, or is the sidebar the intended phone-unfolded layout?

UITabBar measures titles on the first layout pass. After unfolding, the bar is much wider but labels stay truncated with an ellipsis until the user switches tabs. Reapplying standardAppearance does not rebuild the buttons. Is there a public API to invalidate tab-item title measurement when the bar’s width changes?

On unfolding, our app's horizontalSizeClass becomes .regular, and UITabBarController automatically promotes to the iPadOS-style sidebar. We suppress this with mode = .tabBar (iOS 18+) and sidebar.preferredPlacement = .tabBar / sidebar.preferredLayout = .tile (iOS 27+) to keep a bottom tab bar. Is this the correct/recommended approach for a foldable iPhone's inner display, or is there a foldable-specific tab bar mode we should be using instead?

Our app declares TARGETED_DEVICE_FAMILY = 1 (iPhone only), yet the unfolded inner display presents a .regular horizontal size class identical to iPad's, and our project also carries a leftover INFOPLIST_KEY_UISupportedInterfaceOrientations_iPad override. Does Apple recommend/require declaring iPad as a supported family for apps that want to support this device properly, or is "iPhone-only + regular size class" the intended long-term model?

Hi, I have an app based almost entirely on standard system components and UICollectionViewController that I'd like to adapt for the iPhone Duo I'd like to describe my viewController setup and ask a few questions, please correct me if any of the statements are incorrect. In the time between the annoucement of the Duo and the release of Xcode 27.1 I also tried to adapt the app to the iPad. It's a simple set up so I think it should be make a good example for questions. My rootViewController is a UITabBarController so on the iPad I get the sidebar (but not the iPhone Duo) Up until now, on the iPhone (horizontal compact) I normally pass a UINavigationController to the UITab's viewController provider closure. This works well because on the iPad when the sidebar is hidden the tab bar at the top of the screen floats above the visible tab's navigation bar For the iPhone Duo and iPad I need a container view controller to load two viewControllers into the rootViewController to make use of the extra horizontal space. Presumably I sholud setup and keep the same view hierarchy (for all devices) and adapt it based on changes to the traitCollection.horizontalSizeClass Using a split view controller's supplementary/second column seems to work well, the UITabBarController manages the sidebar on iPad, views can be resized by the user.Tthe supplementary column is hidden automatically in horizontalSizeClass compact. The navigation bar of the supplementary/second column stays below the floating tab bar -which is understandable because of the split. If I hide the navigationBar on the supplementary/second columns, Is it possible to instal bar items in a navigation bar at the top of the screen/below the floating tab bar? Also if i hide the supplementary column when the iPhone Duo is unfolded, the empty navigation bar becomes visible at the top of the screen, I think this might be a bug. I also tried UIArrangementView. I'm sure if it's suited for this use case as primary (leading) placement needs to switch to the secondary (trailing) placement when the iPhone Duo is unfolded. Is there something that I didn't understand correctly?

When iPhone Duo is partially folded, you need to move some UI to the left or right (or top or bottom depending) half of the screen to avoid the division region, but how do you determine which side is appropriate? Sheets move to the left automatically but why? Is there anything that should move to the right? Can you share any examples? Is there API to get the system recommendation for a specific type of UI or something?

I know iPhone without a home button do not support portrait upside down display, but it seems that this would be very useful on the Duo. Especially if it's upside down when the user closes it. The simulators in 27.1 bets do not seem to support this. Is there a plan to support upside down portrait on the iPhone Duo? Left handed people may appreciate it.

I’m simulating an iPhone Duo using Xcode 27.1 beta, and I’m having trouble tapping buttons placed near the top of the screen. It seems that the top ~20 pixels of the screen are not responding to taps. In my ViewController, preferredScreenEdgesDeferringSystemGestures returns .all, so system gestures should require two swipes to be triggered. However, a simple tap in this area does not seem to be recognized. This appears to happen only on iPhone Duo; taps work normally on other iPhone models. Does anyone know whether this behavior is expected to occur on the actual iPhone Duo hardware as well, or is it specific to the simulator? For reference, the buttons are positioned according to LayoutMarginsGuide with Safe Area. FB24914903 I wonder if anyone knows how to get the top margin size programmatically.

I noticed the hinge keep out has an isActive status on it. does that mean the hinge area is only un-tappable when it is active? As in, when the device is open 100%, the hinge area can receive taps? Same for the camera cutout on the inside screen, I assume it's only active when the camera is being used?

When adapting a UIKit app for iPhone Duo, is there a supported API for observing the hinge/fold angle continuously during an unfolding transition? For example, if the device is partially unfolded at approximately 23°, can an app detect or respond to that specific angle (or ranges of angles) and update/freeze its UI accordingly, or does UIKit expose only discrete pose/state transitions? Additionally, can an app distinguish between unfolding while the device is oriented in portrait versus landscape and provide different adaptive layouts or transition behavior for each? I’m specifically interested in what device posture/hinge information is exposed to UIKit during the interactive unfolding transition, and whether developers should design around continuous hinge-angle changes or only the system-provided size, orientation, trait, and pose/state changes.

For a banking app displaying sensitive information, are there any new privacy or security considerations we should be aware of on iPhone Duo, especially around app snapshots, transitions, multitasking, or content visibility?