I am using the Table view in my app. On iPhone it only shows the first column, on iPad and Mac it shows all the columns. Since the Table view does not have an API to determine if the columns are shown, I am using self.horizontalSizeClass == .compact to find out if I need to show all content in the one column. Since the iPhone Duo is still an iPhone, even if it's unfolded, it only shows the one column, but the horizontalSizeClass is not compact. If we ignore that this all doesn't make any sense (why doesn't the Table just show the columns?!) my question is: how can I handle this case? Currently it just shows the first columns content.

I've looked at the UIKit docs for UIView reservedRegions(kind:options:). I've watched the video "Strike a pose with adaptive layouts on iPhone Duo". So I know how to get the current reserved regions. But I can't find the APIs to know when the reserved regions change. This means I can setup my custom view controller with the reserved regions that exist when the view controller is first displayed. But if the user changes the Duo, say from fully open to partially open, what API is triggered that lets me know that I need to call reservedRegions(kind:options:) and update the layout as needed? I played around with UIHingeInteraction but that isn't the right approach. In most cases I tried calling reservedRegions(kind:options:) on each call to the interaction handler but I almost always got the wrong results (maybe a simulator issue?). And of course that interactiion handler will be called a lot just to report the new fold angle. I also tried various UIViewController methods for size changes and registered for size class changes. None of these were appropriate. I just need a single notification that the Duo went from fully open to partially open, partially open to fully open, and partially open between landscape/portrait so that I can call reservedRegions(kind:options:) and get the correct, current divider info. What am I missing? My use case is for a custom fullscreen view controller that needs to layout a few items based on whether the Duo is fully open or partially open and whether the fold is horizontal or vertical. Unless I'm mistaken this precludes the use of UIArrangementViewController since I only have one view controller with one set of content to display. Showing the view controller as a form sheet, page sheet, or popover won't work since I need this to be fullscreen. I just need the fullscreen content to adjust for any fold (reserved region).

Summary A TabView with .tabViewStyle(.page) builds its tabs with ForEach; each tab presents a fullScreenCover(item:) from inside. Once the TabView is on screen, either of these breaks every later presentation: a tab is added or removed, or a tab's root view changes identity (Group { switch state } going from .loading to .loaded, with no tab added or removed). From then on each cover is dismissed by SwiftUI itself 15–70 ms after the present. With the standard transition it opens and closes once. With .navigationTransition(.zoom) the dismissal reaches UIKit while the cover is still animating in, and the app crashes: NSInternalInconsistencyException: Cannot morph from a view that is not in the hierarchy. Reproduces on iOS 26.0, 26.5 and 27.1 simulators and on devices on iOS 27.0.x. In our shipping app it is the top crash, ~2,000 events/day. How we got here The crash appeared when we adopted .navigationTransition(.zoom) for this cover. Every report is SheetBridge.dismiss/present → dismissViewControllerAnimated: → -[UIView(UIMorphableInternal) _morphPreviewFromCurrentState:…]. A second tap while the cover was still zooming in reproduced it; we guarded against that. Crashes continued. Disassembling UIKit showed that a dismissal during a zoom presentation preempts it and morphs from the presented view; if that view is not in the hierarchy, UIKit asserts instead of falling back. Any premature dismissal is enough. Our crash breadcrumbs showed every user navigating between tabs of a page-style TabView shortly before the crash, so we went looking for what dismisses a cover that was just presented. A lab with our topology (~1,700 automated presents) found the two triggers above. Both reproduce on iOS 26.0, 26.5 and 27.1, so the SwiftUI side is not new; the zoom transition is what makes it fatal. Steps to reproduce Run the PagedTabViewCoverRepro scheme (https://github.com/matheusmdutra03/PagedTabViewCoverRepro). The bottom tab bar selects the scenario; each screen explains the cause and shows the steps. "Page list changes": tap Add a tab, then tap any photo. "Page content changes": tap Reload tab content, then tap any photo. Expected The photo opens and stays until Close. Actual Zoom on: the app crashes with "Cannot morph from a view that is not in the hierarchy." Zoom off: the photo closes by itself about 1 s later. The on-screen counter shows "Dismissed by system". Why we think it happens The page-style TabView tracks the presentations made from its tabs, keyed by each tab's identity in the ForEach. Scenario 1 changes that identity directly: the tab list is diffed. Scenario 2 changes it indirectly. Group adds no view of its own, so the tab is whichever switch branch is active. When state flips, the branch changes type and SwiftUI sees a different view in that slot. For the TabView that is the same as removing the tab and inserting a new one. Either way the tracking is rebuilt and the tab's fullScreenCover loses the presentation it owns. Every present after that is treated as orphaned: SwiftUI dismisses it, presents a second copy, and dismisses that too (captured with method hooks on present/dismiss in the sample). With .zoom the final dismissal lands while the cover is still animating in and its view is not in the window yet; UIKit's zoom-out has no fallback for that and asserts. The broken state lives in the TabView subtree: recreating only the TabView clears it, and a cover attached outside the TabView is never affected. What fixed it in the sample Scenario 1: .id(tabs.map(\.title)) on the TabView, so a list change recreates the TabView instead of diffing it. 20/20 clean. Does not help scenario 2. Scenario 2: ZStack { switch state { … } } instead of Group { … } as the tab's root. ZStack is a real view, so the tab keeps its identity and the switch only changes its content. 20/20 clean. Does not help scenario 1. Both are app-side workarounds, one per trigger. A standard TabView, a paging ScrollView, or a cover attached outside the TabView never reproduce. Suggested fix Keep each tab's presentation bookkeeping bound to its ForEach identity across list diffs and root-identity changes, so a tab's fullScreenCover/sheet never loses the presentation it owns. If SwiftUI still has to dismiss a presentation it no longer tracks, do it without animation while the presented view is not in the window, so the UIKit zoom transition cannot assert. Results (iOS 27.1, 20 presents each) Scenario 1: 0 clean · 9 dismissed by system · 11 crashes. With .id(tabs): 20 clean. Scenario 2: 0 clean · 0 dismissed · 20 crashes. With ZStack: 20 clean. Attachments Evidence/ has crash logs (iOS 27.1 and 26.5), a screen recording, and the raw trial logs. The ZoomDismissCrashRepro scheme in the same project reproduces the UIKit assertion with five public-API calls and no SwiftUI.

When using ArrangementView with the overlay style, the Duo simulator does not appear to return a distinct z-index environment value, though it correctly displays z-index 0 and 1 on other iPhone simulators. I would like to use this value to determine whether the overlay is active. Currently, this does not seem possible. Is this behavior intended, or is it a bug? If intended, what is the recommended approach to determine if the Duo is displaying the arranged view over another arranged view? import SwiftUI struct ContentView: View { var body: some View { ArrangementView { Controls() } secondary: { Player() } .arrangementViewStyle(.overlay) } } struct Controls: View { @Environment(\.overlayArrangementZIndex) var zIndex var body: some View { Text("Controls Z:\(zIndex)") .frame(maxWidth: .infinity, alignment: .leading) } } struct Player: View { @Environment(\.overlayArrangementZIndex) var zIndex var body: some View { Text("Player Z:\(zIndex)") .frame(maxWidth: .infinity, alignment: .trailing) } } #Preview { ContentView() }

Hello Apple Developer Community, We are adapting our UIKit-based iOS application for iPhone Duo and have encountered an unexpected layout issue when switching the app language to Arabic. We would appreciate any guidance from Apple engineers or developers who have experience with RTL layout behavior on this device form factor. ### Environment - Device: iPhone Duo Simulator - OS: iOS 27.1 (official release, non-beta) - Xcode: 27.1 (official release, non-beta) - Framework: UIKit - Layout system: Auto Layout - Device system language: English (LTR) - App language: Arabic (RTL) ### Problem Description Our application supports changing the app language independently of the device's system language. When the system language is English and the app language is Arabic, we configure the semantic content attributes of several UIKit classes globally: ```swift let cAttribute: UISemanticContentAttribute = language.isRTL ? .forceRightToLeft : .forceLeftToRight UIView.appearance().semanticContentAttribute = cAttribute UIButton.appearance().semanticContentAttribute = cAttribute UICollectionView.appearance().semanticContentAttribute = cAttribute UITableView.appearance().semanticContentAttribute = cAttribute UITableViewHeaderFooterView.appearance().semanticContentAttribute = cAttribute ``` After applying these settings, we observe a large, unexpected blank area along the left side of the interface on the iPhone Duo simulator. Multiple screens are affected, and views positioned using Auto Layout appear to leave additional space on the left, resembling an unexpected safe-area inset or margin. When the app language is English, the layout behaves as expected. The issue occurs when the app language is Arabic while the device system language remains English. We have not yet determined whether this is related to semantic content attributes, trait propagation, Auto Layout, safe-area behavior, or a device-specific layout consideration. ### Questions 1. Is using `UIAppearance` to set `semanticContentAttribute` globally a recommended approach for app-level RTL language switching in UIKit? 2. Could this configuration affect safe-area insets, layout margins, or Auto Layout behavior on iPhone Duo? 3. Would `traitOverrides.layoutDirection` be a better approach for controlling the layout direction when the app language differs from the system language? 4. If `traitOverrides.layoutDirection` is appropriate, where should it be applied—for example, on the root view controller or a container view controller—to ensure that the intended layout direction propagates correctly to descendant views? 5. Are there any iPhone Duo-specific layout behaviors or known issues that developers should consider when implementing RTL support? 6. What implementation strategy does Apple recommend for supporting in-app language switching between LTR and RTL languages in an existing UIKit application? Our goal is to support Arabic and other RTL languages reliably without introducing unintended spacing or layout changes, while keeping the device's system language unchanged. Any suggestions, documentation references, sample code, or insights into the underlying behavior would be greatly appreciated. Thank you for your time and help! Best regards, iOS Development Team

Hello Apple SwiftUI / Swift Charts Engineering Team, I am writing to report a layout regression regarding Swift Charts in iOS 27. The anchor property on AxisValueLabel has stopped honoring the .topLeading layout coordinate, whereas it functions perfectly in iOS 26. Bug Description: To prevent the first label on a bottom X-axis from clipping past the left screen edge, a .topLeading anchor is applied. In iOS 27, this specific anchor alignment is completely ignored. The chart falls back to a standard top-center alignment, causing the initial boundary label to clip off-screen. Core Code Snippet to Reproduce: struct XAxisAnchorBugView: View { let dates = [ Calendar.current.date(from: DateComponents(year: 2026, month: 10, day: 1))!, Calendar.current.date(from: DateComponents(year: 2026, month: 10, day: 2))! ] var body: some View { Chart(dates, id: .self) { date in LineMark(x: .value("Date", date), y: .value("Value", 100)) } .frame(height: 300) .padding() .chartXAxis { AxisMarks(preset: .aligned, position: .bottom, values: .stride(by: .day, count: 1)) { value in AxisTick() let currentAnchor: UnitPoint = { guard let currentDate = value.as(Date.self) else { return .top } // BUG: .topLeading layout anchor parameter is completely ignored on iOS 27 return (currentDate == dates.first) ? .topLeading : .top }() AxisValueLabel(format: .dateTime.month(.abbreviated).day(), anchor: currentAnchor) } } } } Steps to Reproduce: Render an X-axis with a .bottom position. Assign anchor: .topLeading strictly to the first axis element's label. Run on an iOS 26 simulator (the first label anchors its top-left corner correctly, preventing edge clipping). Run on an iOS 27 simulator (the .topLeading anchor is ignored, reverting to standard top-center alignment). Expected Behavior: AxisValueLabel should position its layout bounding box using the .topLeading anchor point when specified. Actual Behavior: The layout engine ignores the .topLeading parameter on iOS 27, causing the boundary text to shift left and clip. Attachments: I have attached Xcode Simulator screenshots demonstrating this regression: Best regards, Soumyajit Das

Hello Apple SwiftUI / Swift Charts Engineering Team, I am writing to report a layout regression regarding Swift Charts in iOS 27. The multiLabelAlignment property on AxisValueLabel has stopped working as expected, whereas it functions perfectly in iOS 26. Bug Description: When configuring custom string values within AxisMarks using AxisValueLabel with multiLabelAlignment: .trailing, the alignment configuration is completely ignored on iOS 27. Labels fail to align text properly to the trailing edge, causing rendering layout issues for multi-line or custom text labels on the Y-axis. This exact same implementation compiles and aligns correctly on iOS 26. Code Snippet to Reproduce: swift struct YAxisAlignmentBugView: View { // data points to render the chart frame let data = [(date: Date(), revenue: 3000.0), (date: Date().addingTimeInterval(10000), revenue: 4000.0)] var body: some View { Chart(data, id: .date) { item in LineMark(x: .value("Date", item.date), y: .value("Revenue", item.revenue)) } .frame(height: 300) .padding() .chartYAxis { AxisMarks(preset: .aligned, position: .trailing, values: [12.0, 600.0, 3000.0, 6000.0]) { value in if let revenue = value.as(Double.self) { // BUG: multiLabelAlignment: .trailing is completely ignored on iOS 27 AxisValueLabel("y-(Int(revenue))", anchor: .leading, multiLabelAlignment: .trailing) } } } } } Steps to Reproduce: Render a Swift Chart containing a .chartYAxis configuration with position: .trailing. Pass a string directly using AxisValueLabel(customText, anchor: .leading, multiLabelAlignment: .trailing). Run the application on an iOS 26 simulator (text aligns properly to the trailing edge). Run the identical application code on an iOS 27 simulator. Expected Behavior: The text inside the AxisValueLabel should honor the multiLabelAlignment: .trailing parameter and align the text strings flush right. Actual Behavior: The multiLabelAlignment layout modifier is ignored on iOS 27, resulting in unexpected default left-alignment of the text strings. Attachments: I have attached screenshots from the Xcode Simulator demonstrating the regression: Please let me know if you need any further diagnostic details. Best regards, Soumyajit Das

It compiles for iOS but seems to be a no-op. Is this coming in a future beta? Or is there a way to hide the default back button when using the presentation + zoom navigationTransition APIs? I have a view that needs to show a confirmation on dismissal. I was previously doing this manually using a custom toolbar button + confirmationDialog modifier. But in iOS 27 I don't seem to be able to hide the navigation back button since I added the zoom navigationTransition API. This allows the user to tap the back button and lose changes. Not a great UX.

On macOS 27 Beta 2, a simple NavigationSplitView example exhibits bizarre behaviour when the window is resized. The sidebar seemingly expands and collapses at random as the window is resized. The symptoms can be exacerbated with toolbar items. The sidebar appears to behave correctly when an inspector view is not present. Copy paste the code below into a new Xcode 27 project and run on macOS 27 and then resize the window: File -> New -> Project... -> App import SwiftUI @main struct MyApp: App { var body: some Scene { WindowGroup { ContentView() } } } struct ContentView: View { var body: some View { NavigationSplitView { Text("Sidebar") } detail: { Text("Content") } .inspector(isPresented: .constant(true)) { Text("Inspector") } } } Adding .frame or .inspectorColumnWidth to any of the Text views does not appear to fix the issues. macOS: 27.0 Beta (26A5368g) Xcode: 27.0 beta 2 (27A5209h)

我正在适配iPhone Duo设备，我想简单适配，即当屏幕展开时，只简单的拉伸我的控件。屏幕折叠状态下，控件压缩。 Orientation我支持Portrait方向。 这样适配是否可以通过苹果AppStore的审核？

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？