We ship a mature document viewer (PDF) written mostly in Objective-C with UIKit. It runs on iPhone and iPad and supports multiple scenes. We're planning support for iPhone Duo and would like advice on the right architectural approach before we start. Current structure (simplified) One root viewer view controller (a UIViewController subclass, large and long-lived) owns the document view, search, bookmarks, text-to-speech, presentation mode and similar features. Most of these live in categories and helper modules. Chrome is swapped by size class. A factory picks one of two "toolbars controller" classes based on the trait collection: one for compact, one for regular. The regular one also hosts a tab strip and a sidebar built on the system sidebar UI. When the class it would pick changes, traitCollectionDidChange: tears down the current chrome controller, builds the other one, re-parents the document view into the new container, and then restores tool and presentation state. We skip this while the app isn't active, because UIKit sends trait changes during backgrounding. Geometry changes go through viewWillTransitionToSize:withTransitionCoordinator:, which forwards to the chrome controller, the document view and a zoomed handwriting helper. When the transition completes we recompute content insets and re-render the output for an external display. The document view is a custom scroll-based view (not PDFKit). It has display modes for continuous, single page, two-page spread and two-page spread with a cover page. It calculates its own insets from safe areas and whatever chrome is visible. We still use traitCollectionDidChange: and haven't moved to registerForTraitChanges:. Questions Posture changes and size-class flips. When the device folds or unfolds, should we expect a normal viewWillTransitionToSize: plus a trait change (compact ↔ regular) that our existing swap handles? Or is there a posture/display-configuration signal we should observe instead? Swapping the whole chrome hierarchy in the middle of a fold animation seems costly. Is there a recommended way to defer or coordinate that with the transition coordinator? Hinge or seam area. Is the fold region exposed through safe-area insets, layout guides or a new API? A custom scroll view that lays out two-page spreads needs to keep content out of that region, or line the spread up with it. What's the recommended way to get this geometry from Objective-C? Two-page spread tied to posture. Showing a two-page spread automatically when the device is unfolded (like an open book) seems natural. Does Apple recommend deciding this from traits/posture or from bounds, and is there a trait we can override per view controller? Trait registration. For this form factor, is it effectively required to move from traitCollectionDidChange: to registerForTraitChanges: (for example to get notified about new traits), or will the legacy callback still fire reliably? Scenes and external displays. Does iPhone Duo change anything about scene activation, window geometry or UIScreen handling that a multi-scene app with external-display output should plan for? Incremental adoption. Can we adopt this step by step in Objective-C, or do some of the APIs only exist in Swift and push us toward Swift wrappers? Any pointers to WWDC sessions, sample code or documentation for adapting existing UIKit apps would be very helpful. Thanks!

Hi apple team, we have a requirement where on certain pages, tabbar should not be displayed. it worked on non iphone-duo phones by utilizing tabbar.isHidden = true yet on iphone duo, it didnt work. is it a bug or are there a missing api that i didnt impl? thanks

Since iPadOS 26 we have been seeing a crash inside the system keyboard. It happens while the system keyboard renders key images. Our code is not on the crashing stack. Crash The app is terminated by an uncaught NSInvalidArgumentException. The NSXPC encoder fails to allocate a very large buffer while a keyboard image cache item is being encoded: NSInvalidArgumentException: *** NSAllocateMemoryPages(60003072) failedRequested sizes seen across reports: 60,003,072 / 60,558,656 / 78,724,160 / 240,001,920 / 933,149,952 bytes. Xcode Organizer groups these reports under the signature TextInput: -[TIImageCacheItem encodeWithCoder:] + 276. Relevant frames (main thread, simplified): objc_exception_throw NSAllocateMemoryPages NSXPCEncoder (encoding) -[TIImageCacheItem encodeWithCoder:] + 276 (TextInput) TIDispatchSync TIImageCacheClient UIKeyboardCache -[UIKBKeyView displayLayer:] ... UIApplicationMainScope (about 3 months of data) 327 crashes from 43 users. iPad only. iPadOS 26.1 – 26.7.1. No crashes on iPhone and none on iPadOS 18 or earlier. No single iPadOS 26 minor version stands out. The first occurrence did not line up with any release of our app. Our keyboard-related code did not change at that time. Free memory at crash time ranges from 33 MB to 4.8 GB. Some crashes happen within 40 seconds of launch. This looks like an abnormally large encode request, not memory pressure or a leak in the app. All affected users use the zh_CN locale. Context The screen has a plain UITextField, the standard system keyboard, and no custom inputView. It also has a UIIndirectScribbleInteraction for Apple Pencil handwriting. The crash happens shortly after the keyboard appears. Breadcrumbs show UICompatibilityInputViewController, UISystemInputAssistantViewController and UIPredictionViewController being set up just before the crash. Many crashes happen when the app window is not full screen (Split View / Stage Manager). For example, a 629.5 pt wide app window on a 1180 pt screen, or 936×954 on 1373×954. Some devices were rotating frequently. In a few cases there was a rapid burst of multi-tap gestures about 20 ms apart just before the crash (Pencil/Scribble-like input). What we tried We could not reproduce it on our own iPads running iPadOS 26. Memory stays flat and there is no crash. Questions Is this a known issue in the iPadOS 26 keyboard image cache (TIImageCacheItem)? Is there a recommended workaround on the app side, for example avoiding certain input view reloads or trait changes while the keyboard is visible?

I’m currently running into issues where nextEventMatchingMask is taking at least 0,02 seconds and even in some cases 0,07 seconds just to return a nil event. This is causing me to not be able to hit my target frame rate of 60fps. Is this expected behaviour? It happens but with distantPast and nil untilDates.

The following has been reported as FB25281446 I've come across a serious user interface issue on the iPhone Duo when you show a popover with the permitted arrow direction set to only left or right. Here's a screenshot from a test app of a correct popover shown from a form sheet on a fully open iPhone Duo: Here's the same UI after switching the Duo from fully open to partially open: Note how the popover is now partially offscreen. Oddly the toolbar is still kept onscreen. You are unable to scroll to the last rows of the table view. You can replicate this problem by taking the following steps: 1) Create a new Storyboard/Swift app with Xcode 27.2 RC 2) Edit the Main storyboard by removing the default view controller 3) Add a navigation controller (and its default root view controller) 4) Set the navigation controller as the initial view controller 5) Replace the contents of the default ViewController.swift file with the following code: ```swift import UIKit class ViewController: UITableViewController { override func viewDidLoad() { super.viewDidLoad() let showPopover = UIBarButtonItem() // Show the view controller as a popover let action = UIAction(title: "Popover", handler: { _ in let vc = ViewController() let nc = UINavigationController(rootViewController: vc) nc.modalPresentationStyle = .popover nc.popoverPresentationController?.sourceItem = showPopover nc.popoverPresentationController?.permittedArrowDirections = .any self.present(nc, animated: true) }) showPopover.primaryAction = action self.navigationItem.rightBarButtonItem = showPopover // Show the view controller in a form sheet let showFormSheet = UIBarButtonItem() let action2 = UIAction(title: "FormSheet", handler: { _ in let vc = ViewController() // Applying a preferred content size affects the results in one // case - the popover works correctly when the Duo is fully open // in portrait and you show a popover from a form sheet. //vc.preferredContentSize = .init(width: 540, height: 620) let nc = UINavigationController(rootViewController: vc) nc.modalPresentationStyle = .formSheet self.present(nc, animated: true) }) showFormSheet.primaryAction = action2 self.navigationItem.leftBarButtonItem = showFormSheet // Show some dummy toolbar items to help demonstrate the issue self.navigationController?.isToolbarHidden = false self.toolbarItems = [ UIBarButtonItem(systemItem: .add), UIBarButtonItem.flexibleSpace(), UIBarButtonItem(systemItem: .action), ] } } extension ViewController { override func numberOfSections(in tableView: UITableView) -> Int { return 1 } override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int { return 20 } override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { let cell = tableView.dequeueReusableCell(withIdentifier: "cell") ?? UITableViewCell(style: .subtitle, reuseIdentifier: "cell") cell.textLabel?.text = "Row \(indexPath.row)" cell.detailTextLabel?.text = "Tap me to show popover" return cell } // Show a popover from a selected cell. The popover will appear partially // offscreen under the following conditions: // - When the Duo is fully open and landscape: // - A row near the bottom of the root view controller is selected. // - When the Duo is fully open and portrait: // - A row near the bottom of the root view controller is selected. // - A row near the bottom of a form sheet is selected (unless the form // sheet has a preferredContentSize set). // - When the Duo is partially open and landscape or portrait: // - A row near the bottom of the root view controller is selected. // - A row near the bottom of a form sheet is selected. // - If you then fully open the Duo, the partially offscreen popover // moves into the correct, fully visible position. // Note that the toolbar of the partially offscreen popover stays on screen. // // There are no issues when the Duo is closed. override func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) { if let cell = tableView.cellForRow(at: indexPath) { let vc = ViewController() let nc = UINavigationController(rootViewController: vc) nc.modalPresentationStyle = .popover nc.popoverPresentationController?.sourceItem = cell // The problem only happens if the arrow is limited to left or right nc.popoverPresentationController?.permittedArrowDirections = [ .left, .right ] self.present(nc, animated: true) } } } ``` 6) In the Main storyboard, change the root view controller's class to ViewController 7) Build and run the app against an iPhone Duo running iOS 27.2 RC You can now replicate the two screenshots by fully opening the Duo and putting it in landscape. Then do the following: 1) Tap the FormSheet button 2) In the form sheet table, select a row near the bottom of the form sheet 3) Note the popover appears correctly with an arrow on the right side pointing to the selected row 4) Now put the iPhone Duo in the partially open mode (still landscape) 5) Note the problem. The popover moves partially offscreen. You can’t even scroll to the last row. The popover show remain fully onscreen and of reasonable height just like it was when the Duo was fully open. As noted in the ViewController.swift file, the issue appears under the following conditions: - When the Duo is fully open and landscape: - A row near the bottom of the root view controller is selected. - When the Duo is fully open and portrait: - A row near the bottom of the root view controller is selected. - A row near the bottom of a presented form sheet is selected (unless the form sheet has a preferredContentSize set). - When the Duo is partially open and landscape or portrait: - A row near the bottom of the root view controller is selected. - A row near the bottom of a presented form sheet is selected. - If you then fully open the Duo, the partially offscreen popover moves into the correct, fully visible position.

Calling contactAccessPicker results in a blank sheet and a jetsam error, rather than the expected contact picker, using Apple’s sample code, only on device with iOS 26.2.1. This is happening on a iPhone 17 Pro Max running 26.2.1, and not on a simulator. I’m running Apple's sample project Accessing a person’s contact data using Contacts and ContactsUI Steps: Run the sample app on device running iOS 26.2.1. Use the flow to authorize .limited access with 1 contact: Tap request access, Continue, Select Contacts. Select a contact, Continue, Allow Selected Contact. This all works as expected. Tap the add contact button in the toolbar to add a second contact. Expected: This should show the Contact Access Picker UI. Actual: Sheet is shown with no contents. See screenshot of actual results on iOS device running 26.2.1. Reported as FB21812568 I see a similar (same?) error reported for 26.1. It seems strange that the feature is completely broken for multiple point releases. Is anyone else seeing this or are the two of us running into the same rare edge case? Expected Outcome, seen on simulator running 26.2 Actual outcome, seen on device running 26.2.1

Hello, SubscriptionStoreView() supports view modifiers such as .subscriptionStoreControlStyle(.automatic), which adapts naturally to the conditions This is awesome. However, when I built the paywall, something caught my eye. The .automatic selection does not display what the user gets for the price, which goes against the guidelines? I remember getting a rejection for this specific reason a few months ago. Here it is Guideline 3.1.2(c) | Business | Payments | Subscriptions Issue Description The app uses auto-renewable subscriptions, but it does not clearly describe what the user will receive for the price. Since this is a native component with native view modifiers, I assume the text placement, colors, and other styling choices are determined by Apple by default, which also suggests that it should comply with the guidelines? My question is, will Paywall 1 pass the app submission review? Paywall 2 seems to make it clear what the user gets for the price Thank you

I am trying to adjust the spacing between the primary and secondary views within a SwiftUI ArrangementView. I haven't been able to find a direct parameter or modifier (like spacing) that controls this distance on the container itself. Is there a standard way to achieve this, or should I be looking into a workaround using padding ?

Do custom bottom tab bars require special ReserveRegion insets or does the system handle tab shifting automatically?

I want use Auto Layout adapt iPhone Duo and Other Device，It is OK？

On the iPhone Duo, default toolbar items are 48 pt instead of 44 pt, even when the navigation bar is horizontal. There doesn't seem to be a public API to query this size, making it difficult to match custom toolbar items to system controls without device-specific checks. I've filed FB25271102 requesting an API to expose the default toolbar item dimensions, ideally through a SwiftUI environment value.

When you use .navigationTransition(.zoom(sourceID: "placeholder", in: placehoder)) for navigation animation, going back using the swipe gesture is still very buggy on IOS26. I know it has been mentioned in other places like here: https://developer.apple.com/forums/thread/796805?answerId=856846022#856846022 but nothing seems to have been done to fix this issue. Here is a video showing the bug comparing when the back button is used vs swipe to go back: https://imgur.com/a/JgEusRH I wish there was a way to at least disable the swipe back gesture until this bug is fixed.

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

Is there a public iPadOS API (or entitlement) that lets a third-party app present a transparent, interactive drawing layer over another foreground app? What I want: App A (Safari, a video app, etc.) stays in the foreground and remains visible. My app draws Apple Pencil ink on a transparent layer above that content. Pencil strokes go to my layer. I do not need to read the pixels underneath. This must be possible with public APIs only, for an App Store app. What I already checked, and why it does not match: UIWindow / windowLevel: only orders windows inside my own scene, not above another app. Slide Over, Split View, Stage Manager: a separate window beside or over the other app, not a transparent ink layer on its pixels. Picture in Picture with a custom content source: a floating window, not a full-screen transparent canvas. ReplayKit / ScreenCaptureKit: capture or broadcast, not an interactive overlay. Screen Time shields / AssistiveTouch-style overlays: system UI, not available to third-party apps. I am not asking for a review of an app concept. I am asking whether any current public API can do this, and if not, which of the options above is the supported boundary. Environment: iPadOS 26, Xcode 26, PencilKit.

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

It appears that hidesBottomBarWhenPushed no longer works in iOS 26 Beta 1. Is it supposed to work, is it going away or is there a alternate behavior we should be using?

Hallo everyone, We are building our app with Xcode 27 and noticed that UIDesignRequiresCompatibility still appears to be honored on iOS 26 devices. Questions: Could you confirm whether this key is still supported on iOS 26 when built with Xcode 27? If our deployment target includes iOS 26, should we keep the key for backward compatibility, or is Apple's recommendation to remove it entirely? Additionally, are there any risks associated with removing it for iOS 26 users?

Feedback submitted: FB24460699 The sample projects are attached to the feedback report. Environment:iOS27 Beta6; iPhone 17Pro Problem:I have encountered a consistently reproducible third-party custom keyboard layout issue in iOS 27.0 beta 1 through beta 6. The custom keyboard initially appears correctly. If I switch apps while the text input remains focused and the keyboard remains visible, and then return to the host app, the system adds a 17-point area above the custom keyboard extension. Steps to reproduce Install and enable a third-party custom keyboard. Switch to the sample custom keyboard and open the host app so that the text editor in the center receives focus. Do not dismiss the keyboard or remove focus from the editor. Return to the Home Screen or switch to another app. Return to the host app. A new blank area now appears above the custom keyboard content. I tested both a system-determined extension view height and an extension view explicitly constrained to 180 points. Both configurations produce exactly the same change. After the foreground transition, the following extension-side values remain unchanged: view.bounds inputView.bounds extension.window.bounds view.safeAreaInsets, which remains {0, 0, 0, 0} The requested 180-point extension height Only the system keyboard frame received by the host app increases by 17 points. I also drew a rounded pink boundary inside the transparent extension root view. When the issue occurs, the new area appears outside that boundary. I tested several third-party keyboards and reproduced the issue with all of them. This suggests that the behavior is caused by iOS rather than by my app. Questions On iOS 27, is it expected behavior for a custom keyboard to gain a 17pt top area after its host app returns from the background? If this is a system issue, is there any workaround that can be used until it is fixed?

I’m developing a SwiftUI iPad app that runs on an Apple silicon Mac as an iPad app—not as a Mac Catalyst app. The app supports multiple windows, with each Live Screen window associated with a different virtual machine. In the macOS Window menu, all child windows appear as “VirtualProg” rather than showing their content or VM name. The Live Screen window is created from a data-driven  WindowGroup , roughly like this: WindowGroup(id: "vm-screen", for: String.self) { $vmName in VMScreenWindow(vmName: vmName) .navigationTitle(vmName.map { "Live ($0)" } ?? "Live Screen") } I’ve tried setting the title with  .navigationTitle  both on the  WindowGroup  content and inside the window’s  NavigationStack . I also tried setting  windowScene.title  on the specific scene obtained from  view.window?.windowScene  after the view controller appeared. Neither changed the Window-menu entries. Is there a supported way to set a per-window title for the macOS Window menu when running an iPad app on Mac? Does  UIScene.title  affect that menu, or only the window title bar and app switcher? Is this a limitation of the iPad-app-on-Mac runtime, or is there a recommended SwiftUI/UIKit lifecycle hook for this? I’m looking for a public API solution rather than private AppKit/window introspection.

If the NavigationSplitView on iPadOS 26 is combined with a .inspector column, the sidebarToggle is always hidden, when the sidebar is collapsed. If you remove the .inspector modifier, the sidebarToggle stays visible throughout the collapsed or expanded state. Has maybe someone a workaround for this issue? The problem does not exist in iOS 18. The bug is reported as FB20061260