Example of code: @State private var state1 = "hello" @State private var state2 = "world" @State private var state3 = 0 @State private var state4 = false Or using store @Observable class Store { var state1 = "hello" var state2 = "world" var state3 = 0 var state4 = false } // and @State var store = Store() Some things I found myself, is that using Store I can use didSet, willSet to update other vars when one changes. But if that is not needed - is there an advantage of one

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.

Has anyone else observed an app entering the background when the user simply opens Notification Center on iOS 27? In our app, fully pulling down Notification Center triggers both UIScene.didEnterBackgroundNotification and UIApplication.didEnterBackgroundNotification. The user has not pressed the side button, gone to the Home Screen, or switched to another app. In the iOS 26 environments we checked, opening Notification Center only made the app inactive. User-visible impact and recording Our app currently treats background entry during an active medication reminder as leaving that reminder session: it closes the reminder screen and schedules a follow-up. As a result, merely checking Notification Center now triggers that existing behavior. Screen recording: https://drive.google.com/file/d/1KmXEKwg1vJpCWqe56IrC_iHaEC2aH_fc/view?usp=sharing The recording shows Notification Center being opened from the reminder screen, including a return to the app's main screen instead of the reminder screen. It also includes opening and dismissing Control Center, as well as going to the Home Screen and returning to the app. These are separate interactions, not one continuous Notification Center interaction. The video illustrates the visible impact; the lifecycle evidence below comes from separate logging. Environment and observations Physical device with the issue: iPhone 14 Pro, iOS 27.0 release build 24A435. We also observed it on an iOS 27 developer beta. Devices without the issue: iPhone 11 Pro running iOS 26.5.2 and iPhone 16 Pro running iOS 26.6. Opening Notification Center did not trigger background entry on either device. These comparisons involve different devices; we have not isolated the OS version as the only variable. App lifecycle: SwiftUI App + WindowGroup + @UIApplicationDelegateAdaptor. Multiple-scene support is disabled. The app uses AlarmKit for medication reminders. Verified build environments (simulator reproduction) Reproduction build Xcode iOS SDK Our app 26.4.1 (17E202) 26.4 Minimal standalone lifecycle apps 26.4.1 (17E202) 26.4 Minimal standalone lifecycle apps 27.0 RC (27A266a) 27.0 All three groups reproduced background entry when fully opening Notification Center on the iOS 27.0 simulator (24A434). The same SDK 26.4-built minimal apps remained inactive, without entering the background, on the iOS 26.4.1 simulator (23E254a). The behavior therefore also reproduces with apps built against the older SDK, not only with the iOS 27 SDK. Steps to reproduce in our app Open the app and leave it in the foreground. Swipe down from the top-left edge to fully open Notification Center. Do not tap a notification, lock the device, or switch apps. Observe the lifecycle notifications, then dismiss Notification Center to return to the app. On the affected iOS 27 device, the behavior differs between these actions: Action Observed behavior Fully open Notification Center App becomes inactive, then enters the background Open Control Center App becomes inactive, without background entry Enter the app switcher without selecting another app or going Home App becomes inactive, without background entry Go to the Home Screen App enters the background, as expected Lifecycle evidence This is a representative trace from earlier instrumented runs, separate from the screen recording above. Times are relative to the first event: +0.000s scene.willDeactivate +0.002s app.willResignActive +0.778s scene.didEnterBackground +0.780s app.didEnterBackground In subsequent instrumented runs on the iOS 27 release build, we also observed UIScene.activationState == .background after opening Notification Center. Our application's background handler is connected to the UIKit notification, rather than an onChange handler for SwiftUI's scenePhase: .onReceive( NotificationCenter.default.publisher( for: UIApplication.didEnterBackgroundNotification ) ) { _ in delegate.handleBackgroundEntry() } Separately, a diagnostic observer uses NotificationCenter.default.addObserver to record the UIKit application and scene notifications. The background events are therefore not inferred solely from our own session state or from the reminder screen disappearing. Questions Has anyone reproduced this on iOS 27? Reports of either reproduction or non-reproduction, including device model and OS build, would be helpful. Is background entry when fully opening Notification Center expected on iOS 27, or could this be a regression or an interaction with our app configuration? Is there a supported API or documented lifecycle distinction between opening Notification Center and actually leaving the app for the Home Screen or another app? Our standalone simulator comparisons reproduced the behavior with both SwiftUI and UIKit scene-based app lifecycles, including direct sceneDidEnterBackground callbacks. For context, this earlier Apple staff response describes Notification Center as making an app foreground-inactive. I also found this iOS 27 AVPlayer report about playback stopping after Notification Center is fully opened, but I do not know whether it has the same underlying cause. Any clarification from Apple or observations from other developers would be appreciated.

Hi, in RealityKit, AudioPlaybackController exposes duration, gain, speed, play/pause/stop, and a completion handler, but I can't find a way to read the current playhead position while a resource is playing. I need this to trigger animations and other timed events in sync with the audio. Is there a supported way to read the current playback position on AudioPlaybackController? If not, is this planned any time soon? Also, is there a sample-accurate way to start/keep audio playback in sync across multiple entities in RealityKit? Appreciate any guidance, thanks.

On macOS 27.0 (26A428) with Xcode 27.0, Apple's unmodified sample Building a document-based app with SwiftUI stops responding permanently when another process replaces an open document's file through NSFileCoordinator. AppKit reverts the document on the main thread, which then blocks in a semaphore wait inside SwiftUI: -[NSDocument relinquishPresentedItemToWriter:]_block_invoke_8 (in AppKit) -[NSDocument _revertToVersion:preservingFirst:error:] (in AppKit) -[NSDocument revertToContentsOfURL:ofType:error:] (in AppKit) URLPlatformDocument.read(from:ofType:) (in SwiftUI) _dispatch_semaphore_wait_slow (in libdispatch.dylib) No other thread is reading the document. In another app using Document, its DocumentReader was never called, and a document with unsaved changes hung the same way in URLPlatformDocument.write(to:ofType:for:originalContentsURL:). Reproduction (the sample plus a short script): https://github.com/DePasqualeOrg/swiftui-document-revert-hang Feedback report: FB24792850

When I drag and drop a file with flag "shouldAttemptToOpenInPlace: true", I was able to access the original file name in macOS 15. After upgrading to macOS 26, I can't access the original file name anymore. Instead, I got some useless file name such as ".com.apple.Foundation.NSItemProvider.gKZ91u.tmp". The app no longer works with these tmp filenames because it needs the orignal file name to do the file transfer. (Btw, this is a WinSCP like app on Mac platform) Could you please check and fix this issue? Thank you. FileRepresentation(contentType: .item, shouldAttemptToOpenInPlace: true)

As a 3D artist specializing in spatial installations, I faced the constant risk of designs looking balanced on screen but failing in physical proportions on the production floor. Starting with no traditional coding background, I embraced AI-assisted development and the CORE learning framework to master Swift, ARKit, and RealityKit. Real ini was built out of real practitioner necessity: turning the iPhone and iPad into on-site spatial validation studios that bridge digital art into physical reality. Download my app for free : https://apps.apple.com/id/app/real-ini/id6805716872

I’d like Swift Charts to support pinch-to-zoom, with the data beneath the pinch staying in place and smooth integration with scrolling and selection. This is useful whenever someone wants to explore a chart: zoom into a heart-rate spike, inspect a price change, or investigate a burst of energy consumption without losing their place. Apple Health uses preset time ranges to change the level of detail. Those are useful shortcuts, but they don’t always match the interval someone wants to explore. Pinching would complement them by letting users zoom directly into whatever catches their attention—a familiar interaction from maps and photos that feels natural for charts too. I’ve implemented a workaround using MagnifyGesture, chartXVisibleDomain, and chartScrollPosition. It mostly works, but keeping the pinch anchored requires continuously adjusting the scroll position, which causes chart jumps and visual glitches—even with animations disabled. Native support should handle that coordination, let developers configure zoom limits, and work alongside existing chart gestures. Developers could then offer smooth, interactive charts without each having to solve the same gesture and anchoring problems. I’ve attached a sample project demonstrating the workaround and its limitations. Would native pinch-to-zoom help your app too? I’d be interested in your use cases and any limitations you’ve encountered. I’ve filed this as FB24785962; if you submit related feedback, please reference it and describe your own use case. Sample Project

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've encountered strange bug in iOS 26. The MultiDatePicker component exhibits unreliable behavior when attempting to deselect previously chosen dates. Users often need to tap a selected date multiple times (e.g., tap to deselect, tap to re-select, then tap again to deselect) for the UI to correctly register the deselection and update the displayed state. This issue does not occur on iOS 18 or Xcode 26 previews, where MultiDatePicker functions as expected, allowing single-tap deselection. The bug only occurs on physical device or simulator. I can't lie, I have multidatepicker as crucial component in my larger app and can't really find a solution to this. Has anyone encountered this problem before? Here is the code to replicate the issue: import SwiftUI struct ContentView: View {     @ State private var selectedDates: Set = []     var body: some View {         NavigationStack {             Form {                 Section {                     MultiDatePicker("Select Dates", selection: $selectedDates)                 } header: {                     Text("MultiDatePicker Bug Test")                 }                 Section {                     Text("Selected Dates Count: (selectedDates.count)")                     ForEach(Array(selectedDates).sorted(by: {                         Calendar.current.date(from: $0)! < Calendar.current.date(from: $1)!                     }), id: .self) { dateComponent in                         if let date = Calendar.current.date(from: dateComponent) {                             Text(date.formatted(date: .long, time: .omitted))                         }                     }                 } header: {                     Text("Current State of Selected Dates")                 }             }             .navigationTitle("Date Picker Bug")         }     } } #Preview {     ContentView() }

It has been two years since I wrote my a SwiftUI app, and I wanted to start again in Xcode 26. I can no longer see the attributes inspector when I select an element in the canvas. This was an Xcode feature that was very helpful as I am still a novice. Has this feature been deprecated in Xcode 26? And if not, please help explain how I can find and use it.

I created a finance tracking app. I wanted to use HistoryObserver to determine when Transactions are created/updated/deleted on another device with the same appleId, so I can update some charts I have an @Observable model that has this (simplified) setup: private(set) var transactionObserver: HistoryObserver? func setupHistoryObserver(modelContainer: ModelContainer) throws { transactionObserver = try HistoryObserver( observedModels: [Transaction.self], modelContainer: modelContainer, ) } var transactionUpdateTrigger: Int { transactionObserver?.eventCounter ?? 0 } I have the view setup with: .task(id: viewModel.transactionUpdateTrigger) { print("updating chart data: \(viewModel.transactionUpdateTrigger)") await updateChartData() } When I launch my app on my iPhone, I see: updating chart data: 0 updating chart data: 1 updating chart data: 2 updating chart data: 3 updating chart data: 4 updating chart data: 5 updating chart data: 6 updating chart data: 7 updating chart data: 8 updating chart data: 9 updating chart data: 10 On simulator, it only fires once: updating chart data: 0 The docs state: "When relevant changes are detected, the observer updates its eventCounter property." The happens every single time I try deploying my app to my iPhone on iOS 27 beta 8, but with varying numbers of eventCounter increments. I only have the app installed on a single device with my Apple Account. Why is this happening? There should be no changes to my models, as is clear because there's no issues when running this in simulator.

I’m seeing inconsistent right-to-left behavior when using the new SwiftUI swipeActionsContainer() API with a ScrollView. The swipe-action buttons are positioned correctly according to the layout direction, but the gesture direction itself is not mirrored. Minimal reproducible example: import SwiftUI struct ContentView: View { var body: some View { ScrollView { LazyVStack { Text("Hello, World!") .padding() .frame(maxWidth: .infinity) .background(.blue.quinary) .swipeActions { Button(role: .destructive) { // Delete action } label: { Label("Delete", systemImage: "trash") } } } .padding() } .swipeActionsContainer() } } Steps to reproduce: Run the example using a left-to-right language such as English. Swipe the row from right to left. The trailing swipe actions appear correctly. Change the app language to Arabic. Swipe the row from left to right, which should reveal the trailing actions in an RTL layout. Nothing happens. Swipe from right to left instead. The actions appear, but from the correct visually mirrored edge. Expected behavior: Because the default swipe-action edge is .trailing, both the action placement and the gesture direction should follow the current layout direction: English/LTR: swipe from right to left. Arabic/RTL: swipe from left to right. Actual behavior: The action buttons visually respect the RTL layout, but the gesture recognizer still requires the LTR swipe direction. Environment: Xcode: 27.0 RC iOS: 27.0 RC Device: iPhone 17 Swift language version: Swift 6

I’m seeing a layout issue in SwiftUI on iOS 26 that only reproduces with specific Accessibility Motion settings. Steps to reproduce 1. Open Settings → Accessibility → Motion. 2. Enable Reduce Motion and Prefer Cross-Fade Transitions. 3. Launch an app with a SwiftUI TextField. 4. Tap the field to show the keyboard. 5. Dismiss the keyboard (tap outside, swipe down, etc.). Expected: After the keyboard is dismissed, the view’s bottom safe area / layout should return to normal. Actual: The view continues to reserve space equal to the keyboard height — as if the keyboard were still visible. UI anchored to the safe area remains shifted upward until the view is reloaded.

Project structure is: App target + widget extension + widget intent extension All share a common appgroup group.com.x.y and all file handling is done using FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "group.com.x.y") so that only the shared container is used. Using the Main app target, a font "Chewy-Regular.ttf" is downloaded and saved to the shared AppGroup container. Font can now be loaded via CTFontManagerRegisterFontsForURL and displayed in a Main App Text view Text("Testing...").font(Font.custom("Chewy-Regular", size: 20)) Now add a Widgetkit widget instance that uses this font. In 'getTimeLine() and getSnapShot() of IntentTimelineProvider we load the font again via CTFontManagerRegisterFontsForURL (this needs to happen again probably because widget runs in a separate process from the main app?). On simulator, the widget will show the correct font. BUT On iPhone7 real device, the widget will show the 'redacted placeholder view'. It seems that something is crashing. I see in the device console : error 14:39:07.567120-0800 chronod No configuration found for configured widget identifier: D9BF75EE-4A04-441A-8C85-1507F7ECE379 fault 14:39:07.625600-0800 widgetxExtension -[EXSwiftUI_Subsystem beginUsing:withBundle:] unexpectedly called multiple times. error 14:39:07.672733-0800 chronod Encountered an error reading the view archive for &amp;lt;private&amp;gt;; error: &amp;lt;private&amp;gt; error 14:39:07.672799-0800 chronod [co.appevolve.onewidget.widgetx:widgetx:small:1536744920620481560@148.0/148.0/20.2] reload: could not decode view error 14:39:07.674984-0800 kernel Sandbox: chronod(2128) deny(1) file-read-metadata /private/var/mobile/Containers/Shared/AppGroup/9B524570-1765-4C24-9E0C-15BC3982F0DC/downloadedFonts/Chewy/Chewy-Regular.ttf error 14:39:07.675762-0800 kernel Sandbox: chronod(2128) deny(1) file-read-data /private/var/mobile/Containers/Shared/AppGroup/9B524570-1765-4C24-9E0C-15BC3982F0DC/downloadedFonts/Chewy/Chewy-Regular.ttf error 14:39:07.708914-0800 chronod [u 8D2C83B3-A6CB-432E-A9D4-9BC8F7056B10:m (null)] [&amp;lt;private&amp;gt;(&amp;lt;private&amp;gt;)] Connection to plugin invalidated while in use. fault 14:39:07.710284-0800 widgetxExtension -[EXSwiftUI_Subsystem beginUsing:withBundle:] unexpectedly called multiple times. error 14:39:07.803468-0800 chronod Encountered an error reading the view archive for &amp;lt;private&amp;gt;; error: &amp;lt;private&amp;gt; It seems that it's a permission issue, and the textview can't access the font file it needs when the widget is rendering. Notes: 1) Font is definitely registered because I can see them in for fontFamily in UIFont.familyNames {             for fontName in UIFont.fontNames(forFamilyName: fontFamily) {                 print(fontName) &amp;amp;#9;&amp;amp;#9;&amp;amp;#9;&amp;amp;#9;&amp;amp;#9;&amp;amp;#9;&amp;amp;#9;&amp;amp;#9;... in both the Main App target and the Widget Extension target 2) If I make make the font part of the app bundle and add to 'Fonts provided by application' , the are loaded absolutely fine in the Main App and the Widget on simulator and iPhone 7 real device. 3) I do see this error sometimes in the Widget extension target log, don't know if it's related. widgetxExtension[1385:254599] [User Defaults] Couldn't read values in CFPrefsPlistSource&amp;lt;0x28375b880&amp;gt; (Domain: group.co.appevolve.onewidget, User: kCFPreferencesAnyUser, ByHost: Yes, Container: (null), Contents Need Refresh: Yes): Using kCFPreferencesAnyUser with a container is only allowed for System Containers, detaching from cfprefsd 4) I suspected something to do with app groups, so I tried to copy the font into the Widget Extension container and load from there, but had the same result. Please help! Thank you.

A regression has been introduced with SwiftUI Menu in iOS 27 betas (still present in beta 6). This regression prevents objects whose properties are bound to contained Menu items from being correctly deallocated. In the example below, Player was immediately deallocated when the surrounding ModalView was dismissed on iOS 26 (or below): import Observation import SwiftUI @Observable final class Player { var playbackSpeed: Double = 1 } struct ModalView: View { @State private var player = Player() var body: some View { Menu { Picker(selection: $player.playbackSpeed) { ForEach([0.5, 1, 1.5, 2], id: \.self) { speed in Text("\(speed, specifier: "%g×")").tag(speed) } } label: { Text("Speed") } .pickerStyle(.inline) } label: { Text("Menu") } } } This is not the case anymore on iOS 27 beta. The Player instance is not deallocated anymore. A dedicated feedback (FB24486991) has been opened.

I found a SwiftUI presentation bug with multiple alerts and sheet presentations. I submitted a Feedback Assistant report too: Feedback ID: FB24621651 The issue is that a native SwiftUI alert dismisses immediately after appearing when it is presented from a view inside a nested sheet. Minimal hierarchy: TabView -> NavigationStack -> outer sheet -> NavigationStack -> detail view -> inner sheet -> alert The inner sheet contains a normal button: struct InnerSheetRoot: View { @State private var showAlert = false var body: some View { Button("Show Alert") { showAlert = true } .alert("Alert from inner sheet", isPresented: $showAlert) { Button("OK") {} } message: { Text("This alert should remain visible.") } } } Steps to reproduce Open the attached sample project. Select the Storage tab. Tap any storage row. In the outer sheet, tap Open Inner Sheet. In the inner sheet, tap Show Alert. Actual result The alert appears briefly and dismisses immediately. It may disappear before OK can be tapped. Expected result The alert should remain visible until the user taps OK. The issue disappears when I remove either the root TabView or the second NavigationStack. It also disappears when the inner sheet is removed. Environment: Xcode: Xcode 26.6 macOS: macOS 26.6.2 iOS: iOS 26.5 Device or simulator: iPhone Simulator Deployment target: iOS 26.0 Swift version: Swift 6 The example project and a screen recording are attached to the Feedback Assistant report, but they can also be found here. I would appreciate confirmation of whether this is a known SwiftUI presentation-host issue and whether there is a recommended way to present alerts from content inside nested sheets.

Having custom view inside safeAreaBar(edge: .top) breaking title. NavigationStack { VStack { List { CustomView() .listRowBackground(.customBackground) } .listStyle(.insetGrouped) .scrollContentBackground(.hidden) } .frame(maxWidth: .infinity, maxHeight: .infinity) .background(LinearGradient(...)) .toolbar { ToolbarItem(placement: .title) { Text("Test") } .safeAreaBar(edge: top) { Picker() .pickerStyle(.segmented) .padding([.horizontal, .bottom]) } .navigationTitle("Favorites") } } I have tried to replace .safeAreaBar with .safeAreaInset and then bug of large title is not anymore, but you are loosing blurry background when you scrolling. https://ibb.co/938zXbPV Its also affected in iOS 26, not just iOS 27

Environment iPadOS 26.0 / 26.1 (Simulator: iPad Air 11-inch (M3)) SwiftUI, NavigationView + .navigationViewStyle(.stack) (also reproduced conceptually with NavigationStack) iPad only Symptom I have a custom split-style layout built with a plain HStack: HStack(spacing: 0) { if showSidebar { Sidebar().frame(width: 80).transition(.move(edge: .leading)) } HStack(spacing: 0) { NavigationStack { MenuList() }.frame(width: 230) Divider() NavigationStack { DetailScreen() } // <- this bar is affected } } Toggling showSidebar inside withAnimation changes the x origin of the right-hand navigation container by 80pt. After that toggle, the Liquid Glass platter (capsule) behind the navigation bar's leading bar button item is drawn at its previous x position, while the button's glyph is laid out correctly. The capsule and the glyph are visually separated by roughly the amount the container moved. Hit testing follows the glyph, so it is purely a rendering/layout mismatch of the platter background. Inspecting the view hierarchy, _UINavigationBarPlatterView / _UINavigationBarPlatterGlassView report a frame that matches the pre-toggle geometry, i.e. the platter container is not re-laid-out when the hosting navigation bar's window-space origin changes without its size changing in a way that triggers a full bar layout pass. Condition It only happens on screens where the navigation bar has exactly one platter group — i.e. a leading item and no trailing items. As soon as the same screen also has a .topBarTrailing item (so UIKit builds two platters), the leading platter is positioned correctly after the toggle. What I tried .id(...) on the toolbar content to force a rebuild: no effect adding a zero-size / hidden trailing ToolbarItem: no effect calling setNeedsLayout() / layoutIfNeeded() on the UINavigationBar after the animation: no effect disabling the animation: no effect The only workaround I found is to opt the leading group out of the system platter entirely and draw my own: ToolbarItemGroup(placement: .topBarLeading) { button .frame(width: 44, height: 44) .glassEffect(.regular.interactive(), in: Circle()) } .sharedBackgroundVisibility(.hidden) This fixes the offset, but it has its own downside — see https://developer.apple.com/forums/thread/811012 — the manually drawn glass does not participate in the navigation push/pop morph the system platter does. Notes The reproduction appears to be sensitive to the exact geometry / device orientation: a reduced sample I built later did not reproduce it reliably, so I have not been able to attach a minimal project yet. If a DTS engineer wants one, I can keep reducing. Questions: Is a plain HStack-based sidebar (rather than NavigationSplitView) an unsupported configuration for the navigation bar platter, i.e. is the platter's position expected to be invalidated only on size changes? Is there a supported way to invalidate the platter layout manually? Is .sharedBackgroundVisibility(.hidden) + manual .glassEffect the recommended escape hatch here, or is it expected to break the push/pop transition?

Hi, I noticed some unexpected layout behavior with Button in SwiftUI: the apparent horizontal padding/inset of a Button seems to change depending on the length of its text label. Here is a minimal example: VStack { Button { } label: { Text("我是一段很长的文字") .lineLimit(nil) .frame(maxWidth: .infinity, alignment: .leading) .border(.red) } Button { } label: { Text("我是一段") .lineLimit(nil) .frame(maxWidth: .infinity, alignment: .leading) .border(.red) } } .frame(width: 100) .border(.red) In Preview, the outer VStack has a fixed width of 100pt, and both Button labels use: .frame(maxWidth: .infinity, alignment: .leading) The red border around each Text shows that the label itself is receiving the expected available width. However, the two Buttons appear to have different horizontal insets between the Button's edge and the Text's edge, even though both Buttons are inside the same VStack and have the same layout configuration. In other words, the Button's apparent internal padding seems to depend on the intrinsic width / length of the label: ┌────────────────────┐ │ ┌──────────────┐ │ │ │ Long text │ │ │ └──────────────┘ │ └────────────────────┘ ┌────────────────────┐ │ ┌────────────┐ │ │ │ Short text │ │ │ └────────────┘ │ └────────────────────┘ What I find particularly confusing is that the label itself has: .frame(maxWidth: .infinity) so I would expect both Button labels to occupy the same available width. I'm trying to understand whether this is expected behavior of the default Button style or a consequence of SwiftUI's layout proposal/intrinsic-size system. Specifically: Why does the Button's apparent horizontal padding change based on the label's text length? Does the default Button style intentionally use the label's intrinsic/ideal size when determining its content inset? Is there an official SwiftUI API to specify a fixed horizontal content inset/padding for a Button, independent of the label's intrinsic size? If I want both Buttons to have exactly the same internal horizontal padding, what is the recommended SwiftUI approach? Is there a way to make the Button give its label the full proposed width before applying its own default styling/insets? I'm aware that I can implement a custom ButtonStyle, but I'm specifically wondering whether there is an existing SwiftUI API or modifier intended for controlling this behavior while retaining the system Button style. I'm seeing this behavior in recent versions of SwiftUI and would appreciate any clarification on the intended layout behavior and the recommended solution. Thanks!