Hi, Problem I have a widget which displays a bright red. When I display the same view inside the app, the red is bright. However when I use the same view on the widget, the color looks a bit dull. Note: Widget Style: Default (Always) It is the same dull red when in focus and when not in focus This happens on iOS (device and simulator) and macOS Questions How can I fix it on the widget? Does widget support Display P3 colors? Any help on this would be much appreciated.

I think the title says it all.

"Build a great camera experience for iPhone Duo" covers the device open and the device closed, including reconfiguring the session from AVCaptureDeviceDirectionCoordinator's change handler when the forward-facing camera changes. It does not cover the partially open pose, which "Leverage multiple displays and scenes on iPhone Duo" treats as a first-class hinge state with a continuous angle. Consider a camera app that keeps a live preview on screen and adopts AVCaptureDevice.RotationCoordinator — the documented remedy for cases like the square front sensor on iPhone 17, where a hard-coded 90° leaves the preview tilted — applying videoRotationAngleForHorizonLevelPreview to both the preview and the capture connection. In the partially open pose the two halves are at different physical attitudes: one stands up, the other lies flat. Which camera does AVCaptureDeviceDirectionCoordinator report as forward-facing while the hinge status is partially open? Does the hinge angle affect that decision? RotationCoordinator derives its angle from device attitude. With the two halves at different attitudes, which one does videoRotationAngleForHorizonLevelPreview reflect — the half carrying the active camera, the half hosting the preview layer, or a single device-level reference? If an app deliberately keeps the rear camera on the scene while its preview is drawn on the half facing the user, is that a supported configuration, or is the coordinator expected to override that choice? Is any of this modelled in the iPhone Duo simulator, or does the partially open pose require real hardware to test? Question 4 matters for planning: building against a rotation value that only appears on device would be worth knowing about before the hardware ships.

We're designing a two-person layout for iPhone Duo. The device lies fully open and flat on a table between two people facing each other. The inner display is in portrait orientation and split with ArrangementView using the default .split style, which stacks the regions in a tall window. Each person gets the half nearest them, and the far region uses .rotationEffect(.degrees(180)) so it faces the second person. The hinge isn't used for layout. While iPhone Duo lies fully open and face-up, does the interface orientation stay stable if the device is nudged or turned on the table? Is there a recommended way to hold it steady for one screen without restricting orientation app-wide? Is rotating one arrangement region 180° a supported pattern? Specifically, do the reserved regions from GeometryProxy.reservedRegions(kind:options:) need to be converted into the rotated region's coordinate space by hand? And do VoiceOver hit-testing and the focus ring follow the rotation? In an immersive full-screen view in this posture, can the status bar be hidden? If not, what's the recommended handling of its occlusion region, which would appear upside down to the second person?

When iPhone Duo is folded or unfolded while our app is running, what is the supported way to be notified, so the layout can re-evaluate? Our app currently computes its board size once when the game screen appears and never recalculates, so a fold or unfold mid-game leaves it sized for the previous display. What should we observe, and at what point in the transition is the new size reliable to read?

Our SwiftUI word game shows a "screen too small" warning on small iPhones, and the same size check gates one feature. We originally read UIScreen.main.bounds. On iPhone Duo the app runs on the inner display (669 x 871 pt), but UIScreen.main returned the cover display's size, so the warning fired on the largest iPhone screen there is. We now read the size from the active window scene's screen instead, which fixes it. Two questions: Is the active window scene's screen the supported way to get the size of the display the app is actually on, or is there a better API (e.g. reading the size from the SwiftUI view hierarchy instead)? For roughly the first second after launch, the Duo reports the scene's screen bounds transposed (871 x 669 instead of 669 x 871). Re-reads a second later are correct. Is that expected, and what is the right moment or signal to read a trustworthy size at launch?

Our SwiftUI game's board screen is one vertical stack: header, board, two tile racks, action buttons, message bar. Built with the iOS 27 SDK it renders correctly upright on iPhone Duo's inner display, but the content needs ~948 pt in an 837 pt canvas, so the racks clip and the buttons fall off the bottom. The canvas is unusually wide and short (669 x 871) compared with any iPhone. What is the recommended way to adapt a portrait phone layout to the inner display — is the expectation that apps restructure into a side-by-side arrangement at this size class, and is there guidance on what to key that off? Size class alone reports .regular width on both displays.

Group Labs are a unique opportunity for the community to submit questions directly to a panel of Apple engineers and designers. Here are the highlights from the iPhone Duo Group Labs: How should apps preserve navigation and UI state when switching between the inner and outer displays? Treat display transitions as size-class and trait changes, not a scene disconnect or app termination; your process stays alive. For more information, see Prepare your app for iPhone Duo. For state that must survive a scene disconnect/reconnect, implement stateRestorationActivity(for:) to save an NSUserActivity Restoring your app's state. Do multiple instances of the same app on iPhone Duo share UserDefaults/@AppStorage state? Multiple instances of your app's UI on iPhone Duo behave similarly to multi-window support on iPadOS. To learn more, see Leverage multiple displays and scenes on iPhone Duo. Both UserDefaults and AppStorage are app-wide, not per-window, stores. If a full-screen app on the inner display is closed, does it move to the outer display or get backgrounded? iPhone Duo honors UIRequiresFullScreen and apps adapt in place as the device opens and closes rather than backgrounding. To learn more, watch Prepare your app for iPhone Duo. How should apps preserve state — text input, scroll position, video playback, camera sessions — during hinge angle transitions? For example, when a LazyVGrid's column count changes because the device folds, does SwiftUI preserve scroll position automatically, or should you use scrollPosition(id:)? The system generally preserves text input and scroll position automatically since hinge angle changes are represented as size-class and trait updates, not a scene disconnect or app termination. This applies even to cases like a LazyVGrid column-count change triggered by opening or closing the device — apps typically don't need to manually manage scroll position with scrollPosition(id:anchor:) for this transition. For more info, see Prepare your app for iPhone Duo. How can apps preserve what someone is doing when switching displays or folding/unfolding? Treat this as a resize/trait-change event, not app teardown — your process keeps running as size classes change. See Prepare your app for iPhone Duo to learn more. For scenes that actually disconnect and reconnect, implement stateRestorationActivity(for:) to save an NSUserActivity Restoring your app's state. How does actively playing video behave through the hinge angle animation? The system generally preserves video playback and player position automatically since hinge angle changes are represented as size-class and trait updates, not a scene disconnect or app termination. AVKit will scale and resize the video automatically. If a user folds or unfolds the device mid-checkout, what does the system preserve automatically, and what should the app manage itself to avoid lost input or duplicate requests? When someone opens or closes an iPhone Duo, the system represents this as a size-class and trait collection change, not a scene disconnect or app teardown, so in-memory state like input fields typically persists automatically since the app’s process keeps running. For more info, see Prepare your app for iPhone Duo. How should apps handle the keyboard and text input when the device folds or unfolds while typing? As iPhone Duo folds or unfolds, the available screen geometry and framing change. Ensure your app adopts standard layout controls, containers, and size classes to handle resizability gracefully across all poses. When a text field becomes first responder, the system automatically shows the keyboard and binds its input to the text field. Because the appearance of the keyboard has the potential to obscure portions of your user interface, you should update your interface as needed to ensure that the text field being edited remains visible. Use keyboard notifications such as keyboardWillShowNotification, keyboardWillHideNotification, and keyboardWillChangeFrameNotification to detect the appearance and disappearance of the keyboard and to make necessary changes to your interface layout. To learn more, see UITextField. If someone is typing and closes iPhone Duo, does the keyboard/editing session survive the hinge transition, or does it get a new scene? When a user types and closes iPhone Duo, the active editing session and keyboard do not get a completely new scene. Instead, the app undergoes a dynamic resizing and transitions from the inner display to the compact outer display, maintaining the existing scene and application state. For more info, watch Prepare your app for iPhone Duo.

Feedback ID: FB23086400 On iOS 27 beta 1, .scrollEdgeEffectStyle(.soft, for: .top) on a List underneath a custom .safeAreaBar(edge: .top) no longer renders the progressive fade-blur. The top edge is fully transparent — scrolled rows pass under the bar with no visual treatment at all, as if scrollEdgeEffectDisabled() had been applied. What I've verified so far: .hard renders correctly in the exact same hierarchy; only .soft is affected. The same binary works correctly on iOS 26.x Xcode preview. I'm building with Xcode 26.3 (iOS 26 SDK). Minimal reproduction: import SwiftUI struct EdgeEffectRepro: View { enum Style: String, CaseIterable, Identifiable { case automatic, soft, hard var id: Self { self } var value: ScrollEdgeEffectStyle { switch self { case .automatic: .automatic case .soft: .soft case .hard: .hard } } } @State private var style: Style = .soft @State private var useSystemBarOnly = false var body: some View { NavigationStack { List(0..<60, id: \.self) { i in Text("Row \(i)") .frame(maxWidth: .infinity, alignment: .leading) .listRowBackground( i.isMultiple(of: 2) ? Color.orange.opacity(0.45) : Color.teal.opacity(0.45) ) } .scrollIndicators(.hidden) .scrollEdgeEffectStyle(style.value, for: .top) .safeAreaBar(edge: .top) { if !useSystemBarOnly { VStack(spacing: 8) { HStack { Text("Custom Top Bar") .font(.system(size: 28, weight: .bold)) Spacer() } HStack { Text("Second row (e.g. date range picker)") .font(.caption) .foregroundStyle(.secondary) Spacer() } } .padding(.horizontal) } } .safeAreaInset(edge: .bottom) { VStack(spacing: 8) { Picker("Edge effect style", selection: $style) { ForEach(Style.allCases) { Text($0.rawValue).tag($0) } } .pickerStyle(.segmented) Toggle("System bar only (control group)", isOn: $useSystemBarOnly) .font(.caption) } .padding() .background(.regularMaterial) } .navigationTitle("EdgeEffect Repro") .navigationBarTitleDisplayMode(.inline) } } } Steps: run on iOS 27 beta 1, set the picker to soft, scroll rows under the bar. Expected: fade-blur as on iOS 26. Actual: fully transparent. Switch to hard: renders fine.

Hi, I was testing my app on iPhone Duo simulator and couldn't understand why even though I am using native navigation stack and toolbars, the toolbar items are not placed on the vertical space. With some debugging I found that it's due to the Group {} I am using Group - because I have a switch inside it where I switch between different types of views, and I insert an environment object only once in the Group {}.environment... I recreated the issue in a clean project, here is full source code: SourceCode.swift And the result when nesting the NavigationStack inside a Group {}. If I remove the Group, toolbar items are pushed to the vertical space as needed

I’m seeing a visual glitch with toolbar buttons when building with Xcode 26 for iOS 26. During transitions (both pushing in a NavigationStack and presenting a .sheet with its own NavigationStack), the toolbar button briefly flashes the wrong background colour (black in dark mode, white in light mode) before animating to the correct Liquid Glass appearance. This happens even in a minimal example and only seems to affect system toolbar buttons. A custom view with .glassEffect() doesn’t have the issue. I’ve tried: .tint(...), UINavigationBarAppearance/UIToolbarAppearance, and setting backgrounds on hosting/nav/window but none of those made any difference. Here’s a minimal reproducible example: import SwiftUI struct ContentView: View { @State private var showingSheet = false var body: some View { NavigationStack { List { NavigationLink("Push (same stack — morphs)") { DetailView() } Button("Sheet (separate stack — flashes)") { showingSheet = true } } .navigationTitle("Root") .scrollContentBackground(.hidden) .background(.gray) .toolbar { ToolbarItem(placement: .topBarTrailing) { Button("Action") {} } } .sheet(isPresented: $showingSheet) { SheetView() } } } } struct DetailView: View { var body: some View { Text("Detail (same stack)") .frame(maxWidth: .infinity, maxHeight: .infinity) .background(.gray) .navigationTitle("Detail") .toolbar { ToolbarItem(placement: .topBarTrailing) { Button("Action") {} } } } } struct SheetView: View { var body: some View { NavigationStack { Text("Sheet (separate stack)") .frame(maxWidth: .infinity, maxHeight: .infinity) .background(.gray) .navigationTitle("Sheet") .toolbar { ToolbarItem(placement: .topBarTrailing) { Button("Action") {} } } } } } Has anyone else seen this or found a workaround outside of disabling this background completely with .sharedBackgroundVisibility(.hidden)? I have filed a bug report under FB22141183

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?

Proposal: Add a System Readable Content Layout to SwiftUI SwiftUI currently does not provide a native equivalent of UIKit's UIView.readableContentGuide. For content-heavy applications such as articles, documentation, settings, email, and media descriptions, developers often need to prevent text from becoming excessively wide on iPad, Mac, and other large displays. UIKit already provides a system-level solution through: view.readableContentGuide However, there is currently no equivalent API in SwiftUI. Current Workarounds Developers currently have to choose between several approaches, none of which provides the same behavior as UIKit's readableContentGuide. 1. Hard-coded maximum width content .frame(maxWidth: 700) This is simple, but the value is arbitrary and does not adapt to the platform, window size, Dynamic Type, or system layout rules. 2. containerRelativeFrame A developer can approximate a readable width: content .containerRelativeFrame(.horizontal) { length, axis in length * 0.52 } However, this is only an approximation. Developers still have to determine the appropriate ratio themselves, and the result does not necessarily match the system's readable content width. 3. Bridging to UIKit Another workaround is to create a UIKit view/controller and obtain: view.readableContentGuide.layoutFrame The resulting width can then be passed back into SwiftUI. This works for iOS and iPadOS, but introduces UIKit-specific implementation details into an otherwise pure SwiftUI view and does not provide a natural cross-platform solution for macOS, tvOS, and other SwiftUI platforms. Proposed API I propose that SwiftUI provide a system-defined readable content layout. For example: .contentWidth(.readable) or a dedicated layout/container: ReadableContent { content } Another possibility would be a layout guide exposed through the SwiftUI environment: @Environment(\.readableContentGuide) private var readableContentGuide allowing: content .frame( maxWidth: readableContentGuide.width ) The exact API design is of course up to Apple, but the important part is that the readable width should be determined by the system rather than by application-specific constants. Expected Behavior The readable content width should be determined by the current platform and environment, taking into account factors such as: Available window/container size Platform-specific layout conventions Dynamic Type / accessibility text sizes Layout margins Safe areas Orientation Size classes where applicable Current window size on macOS Appropriate platform-specific readable widths For example, the same SwiftUI view could behave naturally across devices: iPhone ┌─────────────────────────┐ │ │ │ Readable content │ │ │ └─────────────────────────┘ iPad ┌─────────────────────────────────────────────┐ │ │ │ ┌───────────────────────┐ │ │ │ Readable content │ │ │ └───────────────────────┘ │ │ │ └─────────────────────────────────────────────┘ Mac ┌──────────────────────────────────────────────────────────────┐ │ │ │ ┌───────────────────────┐ │ │ │ Readable content │ │ │ └───────────────────────┘ │ │ │ └──────────────────────────────────────────────────────────────┘ The developer should not need to know the exact width used by the system. Why This Belongs in SwiftUI SwiftUI already provides many environment-driven layout behaviors that automatically adapt to the current platform and device. Readable content width is similarly a semantic layout concept, rather than a fixed visual dimension. For example, developers generally should not need to write: #if os(iOS) let maxWidth = 700 #elseif os(macOS) let maxWidth = 800 #elseif os(tvOS) let maxWidth = 1000 #endif A system-provided readable layout would allow the application to express its intent instead: ReadableContent { ArticleView() } This would also make SwiftUI applications more resilient to future platform changes because Apple could adjust the underlying readable-content rules without requiring developers to update hard-coded constants. Use Cases This would be particularly useful for: Article and reading applications Documentation viewers News applications Email clients Settings and preference screens Legal/privacy documents Markdown viewers AI/chat applications Book and EPUB readers Media descriptions and metadata Forms containing large amounts of text Relationship to UIKit UIKit already establishes a precedent with: UIView.readableContentGuide SwiftUI developers should have access to the same semantic concept without needing to bridge through UIKit. The SwiftUI API does not necessarily need to expose the UIKit implementation. It could instead provide a platform-independent abstraction whose implementation is appropriate for each SwiftUI platform. Summary I would like to request a native SwiftUI API for system-defined readable content width. The ideal solution would allow developers to express: ReadableContent { ArticleView() } or: ArticleView() .contentWidth(.readable) while SwiftUI automatically determines the appropriate readable width for the current platform, window, Dynamic Type settings, and layout environment. This would eliminate the need for hard-coded maximum widths and platform-specific UIKit/AppKit workarounds, while bringing SwiftUI closer to the adaptive layout behavior already available in UIKit through readableContentGuide.

Hi folks, I've used a NavigationSplitView within one of the tabs of my app since iOS 16, but with the new styling in iOS 18 the toolbar region looks odd. In other tabs using e.g. simple stacks, the toolbar buttons are horizontally in line with the new tab picker, but with NavigationSplitView, the toolbar leaves a lot of empty space at the top (see below). Is there anything I can do to adjust this, or alternatively, continue to use the old style? Thanks!

Hi there, I am working on bluetooth functionality of iOS and I have a feature that display all bluetooth paired devices on list view. Is there a way to get the list of paired device using swift programming. Many Thanks!

I'm trying to make an app that can send MIDI data over Bluetooth from my iPhone to my Mac. I'm using AudioKit as a framework for the MIDI aspect, and it's working great over a wired connection. I can't figure out how to implement MIDI over Bluetooth though.I found the CABTMIDILocalPeripheralViewController page here: https://developer.apple.com/documentation/coreaudiokit/cabtmidilocalperipheralviewcontroller, which looks promising, but I'm confused about how to use it.I'd really like to implement it using SwiftUI as opposed to UIKit, because the rest of the app is made with SwiftUI. Could someone please show me how I could use this in SwiftUI to make my iPhone discoverable as a Bluetooth MIDI device?I found some sample code written with UIKit, but I'd like to translate this to SwiftUI:import UIKit import CoreAudioKit import CoreMIDI class ViewController: UIViewController { var localPeripheralViewController:CABTMIDILocalPeripheralViewController? override func viewDidLoad() { super.viewDidLoad() localPeripheralViewController = CABTMIDILocalPeripheralViewController() } @IBAction func someAction(sender: AnyObject) { self.navigationController?.pushViewController(localPeripheralViewController!, animated: true) } }Thank you,Jack

I’m experiencing a UI flickering issue in a SwiftUI application related to navigation and the .searchable modifier. I have the following navigation flow: Case 1: Event Dashboard ↓ Attendee List ↓ Back to Event Dashboard The Event Dashboard contains an event image at the top. The Attendee List has a navigation bar with a .searchable search field. When I navigate back from the Attendee List to the Event Dashboard, the event image briefly becomes smaller and then returns to its original size after approximately one second. Case 2: Event Dashboard ↓ Attendee List ↓ Attendee Detail The Attendee List contains .searchable, while the Attendee Detail screen does not. When navigating from the Attendee List to the Attendee Detail screen, the attendee profile image similarly becomes slightly smaller and then enlarges back to its original size. The behavior appears to be related to the navigation bar/search bar layout changing between screens. For example, the Attendee List currently uses: .searchable( text: $model.searchQuery, placement: .navigationBarDrawer, prompt: "Search" ) If I completely remove .searchable from the Attendee List, the flickering does not occur. I would like to understand whether this is expected SwiftUI behavior or a known issue with .searchable and navigation transitions. I am considering testing the Attendee List with ScrollView + LazyVStack instead of List to determine whether List is contributing to the issue.

Description: When wrapping a UIKit UIScrollView in SwiftUI via UIViewControllerRepresentable, applying topEdgeEffect.style = .hard, then using .toolbar() and .ignoresSafeArea(.container) on the SwiftUI view causes an incorrect/truncated initial height of Navigation Bar on first load. The height will refresh to the correct value after backgrounding the app or switching tabs. Steps to Reproduce: Wrap a UICollectionViewController in UIViewControllerRepresentable. Set collectionView.topEdgeEffect.style = .hard. Embed it in a SwiftUI NavigationStack and apply .toolbar() and .ignoresSafeArea() Happens on Xcode 26.x and iOS 26.x (untested on 27s).

On iPhone Duo in the folded state, the outer screen displays a vertical bar on the right edge with view contents inset. I noticed Form displays an appropriate amount of leading padding but 0 padding on the trailing edge, since the vertical bar provides some padding already, so it looks nice. I have a view that looks kind of like a form, multiple stacked text fields, that should align the same way. I used scenePadding to achieve this and it looks correct on iPhone 18 Pro perfectly aligning with Form. Unfortunately on iPhone Duo there is extra trailing padding such that it doesn't align with the edit button that remains in the horizontal axis navigation bar (and it is not inset enough on the leading edge, off by a few pixels, interestingly). Note when you unfold it and add the app on the left side in Split View, the vertical bar is on the leading edge, in which case there's too much padding on the leading edge. How can I achieve the correct padding? My actual app: struct ContentView: View { var body: some View { TabView { NavigationStack { SystemFormView() .navigationTitle("System Form") } .tabItem { Label("System Form", systemImage: "list.bullet.rectangle") } NavigationStack { CustomFormView() .navigationTitle("Custom Form") } .tabItem { Label("Custom Form", systemImage: "rectangle.3.group") } } } } private struct SystemFormView: View { var body: some View { Form { Text("Row 1") Text("Row 2") Text("Row 3") } } } private struct CustomFormView: View { var body: some View { ScrollView { VStack(spacing: 0) { customRow("Row 1") Divider() .padding(.leading) customRow("Row 2") Divider() .padding(.leading) customRow("Row 3") } .background(.background) .scenePadding(.horizontal) } .background(Color(uiColor: .systemGroupedBackground)) } private func customRow(_ title: LocalizedStringKey) -> some View { Text(title) .frame(maxWidth: .infinity, minHeight: 44, alignment: .leading) .padding(.horizontal) } }

The following code works as expected to display two separate Liquid Glass toolbar buttons with space between them: struct ContentView: View { var body: some View { NavigationStack { Text("Hello, World") .toolbar { ToolbarItem { Button("Add", systemImage: "plus") { } } ToolbarSpacer(.fixed) ToolbarItem { Menu { Button("Settings", systemImage: "gearshape") { } } label: { Label("More", systemImage: "ellipsis") } } } } } } When optimizing for iPhone Duo (and in general) I understand the recommendation is to replace custom "more" menus with the system overflow menu, otherwise it's possible you can see two ... buttons in various scenarios. struct ContentView: View { var body: some View { NavigationStack { Text("Hello, World") .toolbar { ToolbarItem { Button("Add", systemImage: "plus") { } } ToolbarSpacer(.fixed) ToolbarOverflowMenu { Button("Settings", systemImage: "gearshape") { } } } } } } This unexpectedly places both + and ... inside the same shared Liquid Glass background. How do you separate / add space between them, or is this a bug, is there a workaround? Before / After