Before I file a bug report I wanted to verify that I'm not missing something. If I setup a view controller in a navigation controller and I add a view with a constraint that lines it up with the view controller's view's layoutMarginsGuide (leadingAnchor or trailingAnchor), in several cases the view will not line up with buttons added in the navigation bar. Under iOS 18 everything lines up as expected. To demonstrate, create a new iOS project based on Swift/Storyboard. Setup the storyboard to show a UINavigationController with one UIViewController. Then in ViewController.swift (the one embedded in the navigation controller), use the following code: import UIKit class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .yellow title = "Layout Margins" let leftCancel = UIBarButtonItem(systemItem: .cancel) navigationItem.leftBarButtonItem = leftCancel let rightCancel = UIBarButtonItem(systemItem: .cancel) navigationItem.rightBarButtonItem = rightCancel let leftView = UIView() leftView.backgroundColor = .blue leftView.translatesAutoresizingMaskIntoConstraints = false self.view.addSubview(leftView) let rightView = UIView() rightView.backgroundColor = .red rightView.translatesAutoresizingMaskIntoConstraints = false self.view.addSubview(rightView) NSLayoutConstraint.activate([ leftView.widthAnchor.constraint(equalToConstant: 80), leftView.heightAnchor.constraint(equalToConstant: 80), leftView.leadingAnchor.constraint(equalTo: self.view.layoutMarginsGuide.leadingAnchor), leftView.topAnchor.constraint(equalTo: self.view.layoutMarginsGuide.topAnchor), rightView.widthAnchor.constraint(equalToConstant: 80), rightView.heightAnchor.constraint(equalToConstant: 80), rightView.trailingAnchor.constraint(equalTo: self.view.layoutMarginsGuide.trailingAnchor), rightView.topAnchor.constraint(equalTo: self.view.layoutMarginsGuide.topAnchor), ]) } } This adds a "Cancel" button to both ends of the navigation bar and it adds two little square views lined up with the leading and trailing layout margins. Here's the results: iPad running iPadOS 26 beta 3 (note the misalignment). This is really jarring when trying to align another glass button below the cancel button: iPad running iPadOS 18.5 (aligned just fine): iPhone in portrait running iOS 26 beta (aligned just fine): iPhone in landscape running iOS 26 beta (no alignment at all): iPhone in portrait running iOS 18.5 (aligned just fine): iPhone in landscape running iOS 18.5 (aligned just fine): Under iOS 26 on an iPhone (simulator at least) in portrait, the cancel buttons line up with the colored squares. That's good. In landscape, the colored squares have much larger margins as expected (due to the larger safe areas caused by the notch), but the cancel buttons in the navigation bar are not using the same margins. This one is debatable. Under iOS 18 the cancel buttons use larger margins to match the larger safe area. But I can see why under iOS 26 they changed this since the navigation bar doesn't interfere with the notch. But it's inconsistent. Under iOS 26 on an iPad (simulator at least), it's wrong in any orientation. Despite the lack of any notch or need for a larger safe area, the colored squares are indented just a bit more than the buttons in the navigation bar. I see no reason for this. Under iOS 18 everything lines up as expected. My real question at this point: Is the mismatched margins on an iPad under iOS 26 between the buttons in the navigation bar and other views added to the view controller a likely bug or am I missing something?

Hello, I have a SwiftUI View sitting in the UIHosting view controller. On rotation to landscape, the system would add padding to the toolbar. I presume it's the nav bar. Anyone experienced this? What would be this space? padding? content margin?

Hello, Summary: Navigation apps that support the CarPlay Dashboard and Instrument Cluster set UIApplicationSupportsMultipleScenes = true, which allows users to open a second app window on iPhone Duo. However, the app cannot close that window, because requestSceneSessionDestruction returns "This functionality is not supported for this device idiom." We would greatly appreciate your advice on the recommended approach. Our navigation app supports CarPlay, including the Dashboard and Instrument Cluster scenes. Following the example in the CarPlay Developer Guide, our scene manifest sets UIApplicationSupportsMultipleScenes to true. On the inner display of iPhone Duo, this setting also allows users to open a second window of our app (for example, via "Open in Split View"). Since our app is designed around a single main window, we would like to allow only one UIWindowSceneSessionRoleApplication scene while keeping all CarPlay scenes working. Here is what we have found so far (tested on the iPhone Duo simulator running iOS 27.1; we have not yet tested on a physical device): In a test app with UIApplicationSupportsMultipleScenes = false, a second window cannot be opened, as expected. With true, we detect the additional window scene in scene(_:willConnectTo:options:) and display a notice instead of the app UI. However, requestSceneSessionDestruction(_:options:errorHandler:) fails with the error "This functionality is not supported for this device idiom." As a result, we are unable to close the additional window programmatically. We would be grateful if you could help us with the following questions: Is UIApplicationSupportsMultipleScenes = true required for the CarPlay Dashboard and Instrument Cluster scenes, or can these scenes connect when it is set to false? If it is required, is there a supported way to keep the CarPlay scenes while limiting the app to a single phone window? If there is no such way, could you please advise on the recommended way to handle an unwanted second window scene on iPhone Duo, given that apps cannot destroy scene sessions there? Thank you very much for your time and help.

For some reason, Carplay 18.x works fine, however in under certain situations in our app, Carplay 26.x breaks. The expected grid layout should be : However, this is what we see in some cases when we update our templates. I have not been able to isolate the cause of this issue. Has anyone ever seen this happen on their CarPlay apps and discovered the cause? The data sets fed into the templates are identical, the difference is in some of the timing and update order...

SwiftUI Button hit area extends ~16pt beyond its visual frame — expected OS behavior? Hi everyone, I’m working on a custom SwiftUI segmented control and noticed some unexpected hit-testing behavior with Button. I have a button structured roughly like this: Button { selectItem(at: index) } label: { ZStack { if selectedIndex == index { selectedBackground } SegmentCellView( tab: tab, isSelected: selectedIndex == index ) } .frame(maxWidth: .infinity) .contentShape(Rectangle()) } .accessibilityLabel(Text(tab.labelText)) The visual frame of the button has a certain height, but when testing on a real device, I can tap approximately 16pt outside the button's visible frame and the button still receives the tap. This seems to happen even though I explicitly use: .contentShape(Rectangle()) to define the tappable shape. My questions are: Is this ~16pt expansion of the interactive area expected SwiftUI/OS behavior? Is this related to Apple's minimum hit-target/accessibility guidelines being automatically applied to controls such as Button? If so, is there an official API/documentation describing this behavior? Is there a recommended way to make the Button's hit-testing area exactly match the bounds defined by .contentShape(Rectangle()), if that is actually possible? I'm particularly interested in understanding whether this is intentional system behavior or something caused by the ButtonStyle / layout hierarchy. Thanks!

We are seeing a production crash that only affects devices reporting iOS 27.0.0. Devices on 27.0.1 and later, and on iOS 26, are unaffected. The app is built with Xcode 27.0 (the same binary shape appears with the Xcode 27.1 RC toolchain), deployment target iOS 26.0. The crashing code is a plain availability-gated call: extension View { @ViewBuilder func disableNavigationBarMinimization() -> some View { if #available(iOS 27.0, *) { toolbarMinimizationBehavior(.never, for: .navigationBar) } else { self } } } Crash report excerpt (addresses and app symbols removed): crash_info_entry_0: Failed to look up symbolic reference at <addr> - offset <n> - symbol <nearest stripped symbol> in <app binary> - pointer at <addr> is likely a reference to a missing weak symbol Crashed: com.apple.main-thread 0 libsystem_kernel.dylib __pthread_kill 2 libsystem_c.dylib abort 3 libswiftCore.dylib <redacted> 9 libswiftCore.dylib swift_getTypeByMangledName + 908 10 libswiftCore.dylib swift_getTypeByMangledNameInContext2 + 248 11 <app> __swift_instantiateConcreteTypeFromMangledNameV2 12 <app> specialized closure #1 in View.disableNavigationBarMinimization() 13 <app> closure #1 in SomeView.body.getter What we established: Because the deployment target is 26.0 and the API is @available(iOS 27.0, *), the app weak-imports both the function and its opaque result type descriptor. dyld_info -imports on the binary shows: _$s7SwiftUI4ViewPAAE27toolbarMinimizationBehavior_3forQrAA07ToolbareF0V_AA0H9PlacementVdtF [weak-import] (from SwiftUI) _$s7SwiftUI4ViewPAAE27toolbarMinimizationBehavior_3forQrAA07ToolbareF0V_AA0H9PlacementVdtFQOMQ [weak-import] (from SwiftUI) The call site has to instantiate the opaque return type's metadata before calling the function. That is the frame that aborts. So when dyld binds the descriptor to null, #available(iOS 27.0, *) passes and the process still dies. The symbol is present and exported on the iOS 27.0 build we can inspect locally (24A437, via Xcode's DeviceSupport symbols), and the same code runs fine on the iOS 27.0 simulator runtime (24A434). We cannot reproduce the crash on any device we own. The SwiftUI binary in 24A437 exports both toolbarMinimizeBehavior(_:for:) / ToolbarMinimizeBehavior and toolbarMinimizationBehavior(_:for:) / ToolbarMinimizationBehavior. The iOS 27.1 SDK only declares the latter, still annotated @available(iOS 27.0, *). This looks like a rename late in the 27.0 cycle. Our working theory is that some iOS 27.0.0 builds in the field (earlier 27.0 builds, possibly the ones preinstalled on new devices) predate the rename and only contain toolbarMinimizeBehavior, so the renamed symbol is absent and the weak import resolves to null. Questions: Is the @available(iOS 27.0, *) annotation on toolbarMinimizationBehavior(_:for:) accurate for every shipped 27.0.0 build? Should it be 27.0.1 or 27.1? Is there a supported way to guard against a missing opaque type descriptor at runtime, short of raising the availability check? Feedback filed as FB25095054.

I’ve decided that to prepare my app for Duo I need to take iPhone landscape mode more seriously and use viewThatFits to cover landscape versus portrait. That works, even in the Beta Duo simulator, but the tabbar on non-Duo devices does not flip to vertical mode. Any idea how to achieve this (especially on iOS26) so that I’m prepared for the imminent Duo release?

QLPreviewController renders plain text as hyperlink in document downloaded from my ios app. xcode version 27.0, ipadOS - 26.5, ipad Air 11inch(M4). Expected behaviour - plain text should be shown as plain text only. Current Behaviour - When i download a document(excel file) with multiple tables(tabs), it shows some plain text as hyperlink, clicking on those links doesnt work. This works fine in case of single table(tab) document. When it happens The problem shows up only when all three are true: The user downloads the whole report as Excel ("Table Data"), which gives one file with many sheets. 2.The file is opened in the built-in iOS Quick Look / Files viewer. 3.At least one sheet has a real link in its header, footer or cells. It does not happen: 1.In the single table export (one sheet). Tapping the Google link shows the "Leave Files and open this link?" popup and opens the link. 2.In Microsoft Excel (Windows, Mac, iOS, web), even with the same multi-sheet file.

In Xcode 27.1 RC 1 there is a regression bug displaying incorrect accent color across the app. It worked correctly in Xcode 27.1 Beta 1. It affects borderPromintent top bar buttons and tab bars: https://x.com/kulik_wojciech/status/2107252543709692166?s=20 I already reported it as a bug: FB25074768

There's an easily reproducible SwiftUI bug on macOS where an app's UI state no longer updates/re-renders for "Designed for iPad" apps (i.e. ProcessInfo.processInfo.isiOSAppOnMac == true). The bug occurs in Xcode and also if the app is running independent of Xcode. The bug occurs when: the user Hides the app (i.e. it goes into the background) the user puts the Mac to sleep (e.g. Apple menu > Sleep) a total of ~60 seconds transpires (i.e. macOS puts the app into the "suspended state") when the app is brought back into the foreground the UI no longer updates properly The only way I have found to fix this is to manually open a new actual full app window via File > New, in which case the app works fine again in the new window. The following extremely simple code in a default Xcode project illustrates the issue: import SwiftUI @main struct staleApp: App { @State private var isBright = true var body: some Scene { WindowGroup() { ZStack { (isBright ? Color.white : Color.black).ignoresSafeArea() Button("TOGGLE") { isBright.toggle(); print("TAPPED") } } .onAppear { print("\(isBright ? "light" : "dark") view appeared") } } } } For the code above, after Hiding the app and putting the computer to sleep for 60 seconds or more, the button no longer swaps views, although the print statements still appear in the console upon tapping the button. Also, while in this buggy state, i can get the view to update to the current state (i.e. the view triggered by the last tap) by manually dragging the corner of the app window to resize the window. But after resizing, the view again does not update upon button tapping until I resize the window again. so it appears the diff engine is mucked or that the Scene or WindowGroup are no longer correctly running on the main thread I have tried rebuilding the entire view hierarchy by updating .id() on views but this approach does NOT work. I have tried many other options/hacks but have not been able to reset the 'view engine' other than opening a new window manually or by using: @Environment(.openWindow) private var openWindow openWindow could be a viable solution except there's no way to programmatically close the old window for isiOSAppOnMac (@Environment(.dismissWindow) private var dismissWindow doesn't work for iOS)

Hello, I’m reaching out after several days of investigation, as I’ve exhausted all standard troubleshooting steps and would truly appreciate guidance from Apple engineers or experienced developers. I am experiencing a persistent issue where StoreKit does not return any subscription products on any device, despite all subscriptions being fully approved and correctly configured in App Store Connect. What is happening • Auto-renewable subscriptions exist and are approved in App Store Connect • The app is installed from the production App Store (not TestFlight, not sandbox) • initConnection / StoreKit initialization succeeds • Requests for products/subscriptions return an empty result (no errors, no IDs) • In the UI, prices are shown as “Unavailable” • This behavior is 100% reproducible on every device, every Apple ID, every network Important detail This issue is not device-specific, account-specific, or environment-specific: • Tested on multiple iPhones • Tested with different Apple IDs • Tested on different networks • Same result every time — no subscriptions returned Why I believe this is not a code issue The exact same symptoms previously occurred on Google Play, where the root cause turned out to be a store-side configuration flag blocking billing visibility, not an application bug. Because: • StoreKit initializes correctly • No runtime errors occur • The issue is global across devices and users …I strongly suspect there may be an App Store Connect / StoreKit configuration, availability, storefront, agreement, or propagation-related factor that is preventing StoreKit from returning the products at runtime. Is there any known App Store Connect or StoreKit condition where: • subscriptions are approved and visible in App Store Connect • but StoreKit returns an empty result set in production? If so, I would be extremely grateful for guidance on where exactly to verify or correct this. Thank you very much for your time and support — any insight would be hugely appreciated. Kind regards, Mateusz

I’m adapting a UIKit app for iPhone Duo and noticed that UITableViewController separators extend underneath the navigation and tab bar controls when those controls move to the side. The cell content appears to respect the safe area, but the separators continue to the screen edge. When using a UITableView inside a regular UIViewController, constraining its horizontal edges to the parent’s safeAreaLayoutGuide prevents this. With UITableViewController, however, the table view is the controller’s root view. The attached screenshots show the difference: Screenshot 1: Separators extend underneath the side controls. Screenshot 2: Separators stop at the safe area boundary. Should UITableViewController respect these safe area boundaries out of the box, including for separators, when system controls move to the side? Or is drawing separators underneath those controls the intended behavior? If automatic adaptation is expected, could this be a UIKit issue?

I have a SwiftUI view embedded in a UIHostingController. It contains a numeric text field at the top and a .borderedProminent button at the bottom. The text field is automatically focused when the view appears. The bottom button pushes another instance of the same hosting controller. On the initial appearance, SwiftUI correctly positions the button above the keyboard. However, after navigating back from VC2 to VC1, the text field is focused and the keyboard is visible, but the button remains behind the keyboard. This occurs regardless of whether VC2 is closed using the navigation bar back button or the interactive back gesture. This appears to be an iOS 27 regression involving SwiftUI keyboard avoidance inside a UIHostingController. The issue is especially problematic with a numeric keyboard because it has no Return or Done key. If the covered button is the primary way to continue or dismiss the keyboard, the user can no longer access it. Interestingly, the button is repositioned correctly as soon as I begin moving the app into the background. This suggests that SwiftUI still knows about the keyboard safe area but does not update the layout correctly when the hosting controller reappears after being popped to. Minimal reproducible example import SwiftUI import UIKit final class NumericInputHostingController: UIHostingController<NumericInputView> { init() { super.init( rootView: NumericInputView(onContinue: {}) ) rootView = NumericInputView { [weak self] in self?.navigationController?.pushViewController( NumericInputHostingController(), animated: true ) } } @available(*, unavailable) @MainActor required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } } struct NumericInputView: View { @State private var value = "" @FocusState private var isTextFieldFocused: Bool let onContinue: () -> Void var body: some View { VStack(spacing: 24) { TextField("Enter a number", text: $value) .keyboardType(.numberPad) .focused($isTextFieldFocused) .padding(.horizontal, 16) .frame(height: 52) .background { RoundedRectangle(cornerRadius: 10) .stroke( Color.accentColor, lineWidth: 1.5 ) } Spacer() Button("Open Another", action: onContinue) .buttonStyle(.borderedProminent) .controlSize(.large) .frame(maxWidth: .infinity) } .padding(20) .background(Color(.systemBackground)) .onAppear { DispatchQueue.main.async { isTextFieldFocused = true } } .onDisappear { isTextFieldFocused = false } } } The initial controller is embedded in a navigation controller: let controller = NumericInputHostingController() let navigationController = UINavigationController( rootViewController: controller ) Steps to reproduce Present VC1. VC1 automatically focuses the numeric text field. Confirm that the bottom button is above the keyboard. Tap the button to push VC2. Navigate back to VC1. VC1 focuses its text field and displays the numeric keyboard. Observe that the bottom button is now behind the keyboard. Begin putting the app into the background. Observe that the button suddenly moves to the correct position above the keyboard. UIKit’s keyboardLayoutGuide handles the equivalent UIKit layout correctly. Is this a known issue with keyboard safe-area updates when a UIHostingController reappears after navigation? Is there a supported SwiftUI solution that does not require observing keyboard notifications manually?

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

Hi, I have a working program with categories, lists and detail views. All connected via NavigationLink inside a NavigationStack. It looks a bit strange on an iPad, so I replaced the NavigationStack with a NavigationSplitView. The categories went into the sidebar and the lists into the content section. The detail section of the NavigationSplitView is empty and it still works. Is that the correct behavior? I don't mind it, because it works. example code: var body: some View { NavigationSplitView { List(selection: $listSelection) { Section("Section 1") { NavigationLink(value: EnumValue.V1) { CardView("Card 1") } NavigationLink(value: EnumValue.V2) { CardView("Card 2") } NavigationLink(value: EnumValue.V3) { CardView("Card 3") } } Section("Section 2") { NavigationLink(value: EnumValue.V4) { CardView("Card 4") } NavigationLink(value: EnumValue.V5) { CardView("Card 5") } } } .scrollIndicators(.hidden) .navigationTitle("Detail Empty") } content: { if let mt = listSelection { switch mt { case .V1: ListView1() case .V2: ListView2() case .V3: ListView3() case .V4: ListView4() case .V5: ListView5() } } } detail: { // empty } } In each ListView, I assign the ID to the EditorView so that the EditorView is updated. .navigationDestination(for: ViewListTransfer.self) { vl in switch vl { case .trend(bp: let bp): EditorView(value: bp) .id(bp.Id) case .trendNew: EditorView(val: nil) } } It seems to work because everything is linked via NavigationLinks, but it does look strange that the detail section is empty. The details section is mandatory; therefore, it cannot be omitted. Is this behavior something for a bug report? Christian

When a NavigationStack is nested inside a TabView that's using the .sidebarAdaptable style, it completely overwrites the transition animations of the NavigationStack. In tvOS 26, the transition for push and pop instantly snaps in place. in tvOS 27, it uses its own transition animation, which has strange behaviors, such as slow crossfade, and items rearranging if the frame of the child view is different. Here is a sample code that shows what I'm talking about. struct ContentView: View { @State private var selectedTab = 0 var body: some View { TabView(selection: $selectedTab) { Tab("Home", systemImage: "house", value: 0) { NavigationStack { VStack(spacing: 30) { Text("Root Home View") .font(.title) NavigationLink("Push Detail View") { Text("Child View") .font(.largeTitle) } } } } } .tabViewStyle(.sidebarAdaptable) } } Note: Placing NavigationStack over a TabView will retain the NavigationStack's transition animations, but you lose navigation paths per tab, and child views a rendered over the tabview.

Hello, I have a question regarding the task(id:) modifier. It is possible, of course, that I am using the modifier for the wrong purpose. Consider a multi-field search scenario where any change to a field triggers a loading process via the task(id:) modifier. The problem is that every task(id:) modifier executes when the view is first loaded, causing the same data to be loaded multiple times—which makes no sense. I do not want to add a separate search button or implement debouncing; those would merely be workarounds to bypass the actual issue. The onChange modifier has an initial parameter that defaults to false, preventing the action from running when the view is first loaded. However, the task(id:) modifier does not have this parameter. How can I prevent all task(id:) modifiers from executing when the view loads? After all, the standard task modifier should handle the initial load. struct ContentView: View { @State private var field1: String = "" @State private var field2: String = "" @State private var field3: String = "" var body: some View { VStack { TextField("val1", text: $field1) TextField("val2", text: $field2) TextField("val3", text: $field3) } .padding() .task { print("task") } .task(id: field1) { print("task 1") } .task(id: field2) { print("task 2") } .task(id: field3) { print("task 3") } } } Christian

In a macOS 27 app using DocumentGroup(editor:makeDocument:) with a type conforming to the new Document protocol, choosing File › Duplicate hangs the app permanently (0% CPU, spinning beach ball, must force quit). The main thread is blocked in URLPlatformDocument.read(from:ofType:) waiting on a dispatch semaphore. That synchronous NSDocument read path is reached from NSDocumentController.duplicateDocumentWithContentsOfURL(:copying:displayName:) → makeDocumentForURL(:withContentsOf:ofType:) → NSDocument.init(for:withContentsOf:ofType:). The work the semaphore waits for never runs: the app's makeDocument closure is never called. The SDK declares makeDocument and ReadableDocument.apply(snapshot:previous:) as @MainActor, so blocking the main thread while waiting for them can never complete. This reproduces with Apple's unmodified sample code project "Building a Document-Based App with SwiftUI" (no code or project changes; only a signing team set). Our own app, which uses a custom DocumentReader/DocumentWriter with Source/Destination == URL, hangs with the identical stack. Has anyone found any workaround? Filed Feedback FB24949862

I have a keyboard extension in my app and I'm seeing some inconsistent behavior with the system-provided Globe and Dictation buttons. For the system keyboards, these buttons are displayed to the side of the keyboard, insetting the bottom row of keys on the folded screen and insetting the entire keyboard on the unfolded screen. What is the expected behavior for custom keyboards on the folded screen? My test results: When the Duo simulator is folded, sometimes the Globe and Dictation buttons appear next to my keyboard and the entire custom keyboard is squeezed to be really narrow. Other times my UI gets the full width and the Globe and Dictate keys are on TOP of my UI. The latter seems preferable, assuming I can then use the reserved regions API to avoid the overlap. Is that the intent? PS: The reserved regions API doesn't seem to work in keyboard extensions in this beta, neither in SwiftUI or UIKit. Hopefully that's fixed in the next beta.

when I tried ToolbarItemGroup(placement: .title) { VStack { header() }.glassEffect() } the glass effect is only applied to the element itself. And the ToolbarItemGroup does seem to have the glass effect apis either. What I want is for the overall toolbar to have the glass effect, not just the individual elements in the toolbar.