Hello Apple Developer Community, I am developing Keyboard Atelier, a Korean custom keyboard built with Swift, UIKit, and UIInputViewController. Is there a supported way to apply a user-selected background color or image across the entire keyboard presentation, including the surrounding system-owned areas? Problem On an iPhone, we observe a strip above our keyboard extension’s visible content and a separate bottom area containing the system globe and dictation controls. When we apply a custom background to our extension, these surrounding areas retain a different background. This makes our keyboard look like a rectangular panel placed inside a separate system frame. Our product lets users customize keycaps and keyboard backgrounds. We want their selected color or image to appear continuous across the entire keyboard presentation. What we have tested We compared an opaque white root-view background with a clear root-view background in an isolated simulator test. With the opaque background, the boundaries above and below the extension were visible. Removing our own top padding did not eliminate the upper strip. Setting the root view’s backgroundColor to UIColor.clear made the backgrounds appear visually continuous in both light and dark appearances. However, this only reveals the default system background. It does not Questions Is there a public API or supported configuration that lets a custom keyboard specify the background color of the surrounding system-owned areas? Can a custom keyboard supply a background image that extends into those areas, including beneath the system globe and dictation controls? If neither is supported, what is the documented boundary of background customization for a keyboard extension? Is Feedback Assistant the appropriate place to request this capability? iOS should retain control of the system buttons, including their behavior, accessibility, touch targets, and contrast adjustments. We are asking to customize the background behind them while preserving their functionality. The solution must be suitable for App Store distribution and work when the keyboard is used in other apps, without requiring changes to those host apps. Reproduction steps Enable the custom keyboard in Settings > General > Keyboard > Keyboards. Open a UITextView in the containing app. Switch to the custom keyboard. Set the keyboard extension’s root-view background to an opaque white color while using dark appearance. Observe the different backgrounds above and below the extension’s content. Compare this with a build using UIColor.clear for the root-view background. Implementation Swift and UIKit UIInputViewController keyboard extension Test host: a UIKit UITextView in the containing app Light and dark appearances tested RequestsOpenAccess = false Please point me to any relevant API or documentation, or clarify whether this would require a new API. Thank you.

In my CarPlaySceneDelegate.swift, I have two tabs: The first tab uses a CPListImageRowItem with a CPListImageRowItemRowElement. The scroll direction is inverted, and the side button does not function correctly. The second tab uses multiple CPListItem objects. There are no issues: scrolling works in the correct direction, and the side button behaves as expected. Steps To Reproduce Launch the app. Connect to CarPlay. In the first tab, scroll up and down, then use the side button to navigate. In the second tab, scroll up and down, then use the side button to navigate. As observed, the scrolling behavior is different between the two tabs. Code Example: import CarPlay import UIKit class CarPlaySceneDelegate: UIResponder, CPTemplateApplicationSceneDelegate { var interfaceController: CPInterfaceController? func templateApplicationScene( _ templateApplicationScene: CPTemplateApplicationScene, didConnect interfaceController: CPInterfaceController ) { self.interfaceController = interfaceController downloadImageAndSetupTemplates() } func templateApplicationScene( _ templateApplicationScene: CPTemplateApplicationScene, didDisconnectInterfaceController interfaceController: CPInterfaceController ) { self.interfaceController = nil } private func downloadImageAndSetupTemplates() { let urlString = "https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcRcYUjd1FYkF04-8Vb7PKI1mGoF2quLPHKjvnR7V4ReZR8UjW-0NJ_kC7q13eISZGoTCLHaDPVbOthhH9QNq-YA0uuSUjfAoB3PPs1aXQ&s=10" guard let url = URL(string: urlString) else { setupTemplates(with: UIImage(systemName: "photo")!) return } URLSession.shared.dataTask(with: url) { [weak self] data, _, _ in let image: UIImage if let data = data, let downloaded = UIImage(data: data) { image = downloaded } else { image = UIImage(systemName: "photo")! } DispatchQueue.main.async { self?.setupTemplates(with: image) } }.resume() } private func setupTemplates(with image: UIImage) { // Tab 1 : un seul CPListImageRowItem avec 12 CPListImageRowItemRowElement let elements: [CPListImageRowItemRowElement] = (1...12).map { index in CPListImageRowItemRowElement(image: image, title: "test \(index)", subtitle: nil) } let rowItem = CPListImageRowItem(text: "Images", elements: elements, allowsMultipleLines: true) rowItem.listImageRowHandler = { item, elementIndex, completion in print("tapped element \(elementIndex)") completion() } let tab1Section = CPListSection(items: [rowItem]) let tab1Template = CPListTemplate(title: "CPListImageRowItemRowElement", sections: [tab1Section]) // Tab 2 : 12 CPListItem simples let tab2Items: [CPListItem] = (1...12).map { index in let item = CPListItem(text: "Item \(index)", detailText: "Detail \(index)") item.handler = { _, completion in print("handler Tab 2") completion() } return item } let tab2Section = CPListSection(items: tab2Items) let tab2Template = CPListTemplate(title: "CPListItem", sections: [tab2Section]) // CPTabBarTemplate avec les deux tabs let tabBar = CPTabBarTemplate(templates: [tab1Template, tab2Template]) interfaceController?.setRootTemplate(tabBar, animated: true) } } Here is a quick video:

I'm building a wallpaper app for iPhone Duo. The outer display is portrait (1398×2034), and the unfolded inner display is landscape (2670×1878). My wallpapers are portrait images — for example, a person centered in the frame. When the user unfolds the device and the screen changes from portrait to landscape, how does iOS adapt the wallpaper? Specifically: Does it crop a landscape region from the portrait image (which could cut off the subject)? Does it preserve the focal point the user chose when setting the wallpaper, keeping the subject in frame? Or can separate images be assigned to the outer and inner displays? I need to understand this behavior to decide what compositions to offer in my app.

Hi I want to open a modal sheet so it's centered when the iPhone Duo is opened, but on the right side of the screen (trailing) when it's half-closed. But it seems like the "placement" property of the sheetPresentationController applies in all configurations. Is there a way to set a placement "order" (centered if possible, then trailing, then leading) ?

Is it necessary to replace GeometryReader and containerRelativeFrame in preparation for iPhone Duo support? If so, could you let me know the best way to do it.

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.

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.