Provide views, controls, and layout structures for declaring your app's user interface using SwiftUI.

Posts under SwiftUI tag

200 Posts

Post

Replies

Boosts

Views

Activity

iOS 27 beta 1: .scrollEdgeEffectStyle(.soft) renders fully transparent above safeAreaBar
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.
19
13
3.8k
17h
SwiftUI safe area stays offset after keyboard dismissal with “Reduce Motion” + “Prefer Cross-Fade” enabled (iOS 26)
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.
7
2
2.1k
22h
iOS Dynamically loaded custom fonts in WidgetKit not working on real device (simulator is fine). Sandbox chronod deny file-read-data for font file.
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.
8
1
3.4k
1d
HistoryObserver eventCounter updating 9-16 times per app launch because of CloudKit syncing?
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.
0
0
241
1d
iOS 27 regression: Objects whose properties are bound to items displayed in a Menu are not correctly deallocated
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.
4
0
1.5k
1d
SwiftUI alert dismisses immediately when presented from a nested sheet
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.
6
0
211
1d
safeaAreaBar
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
1
0
315
1d
iOS 26: navigation bar leading item's glass platter renders offset after the container view's origin changes
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?
0
0
3k
2d
SwiftUI Button has different internal padding depending on label text length
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!
0
0
218
3d
How can I prevent Siri Remote Back button from dismissing a fullScreenCover on tvOS?
I'm developing a tvOS application using SwiftUI, and I have a custom video player presented using fullScreenCover. .fullScreenCover(isPresented: $isPlayerPresented) { PlayerView() } I would like to implement the same kind of behavior commonly seen in video players: The player is presented full screen. When the playback controls are visible, pressing the Siri Remote Back button should hide the controls. The player should remain presented. Only when the controls are already hidden should pressing Back dismiss the player. However, I am unable to intercept the Back button before the fullScreenCover is dismissed. I have tried several approaches, including: .onExitCommand { // Handle Back } and handling UIPress / .menu events through UIKit. The problem is that when the Siri Remote Back button is pressed while the view is presented using fullScreenCover, the fullScreenCover is dismissed directly. My custom view does not appear to be able to prevent the dismissal. I also tried placing a custom UIView / UITapGestureRecognizer inside the fullScreenCover to intercept the remote button event, but the presentation is still dismissed. According to the SwiftUI documentation, onExitCommand responds to the tvOS exit command generated by the Menu button, but it does not appear to provide a way to prevent the system from dismissing a fullScreenCover in response to the Siri Remote Back button. I also noticed that interactiveDismissDisabled(_:) does not appear to provide a solution for this particular tvOS behavior. My questions Is the Siri Remote Back button expected to automatically dismiss a SwiftUI fullScreenCover on tvOS? Is there a supported API to intercept the Back button before the fullScreenCover is dismissed? Is there a way to tell SwiftUI that a fullScreenCover should not be dismissed by the Siri Remote Back button? If fullScreenCover is not intended for this use case, what is the recommended way to implement a custom full-screen video player that needs to control Back-button behavior? The desired behavior is essentially: Back button ↓ Are playback controls visible? ├── Yes → hide controls, keep player presented └── No → dismiss player I would appreciate any guidance on the intended tvOS API or recommended architecture for implementing this behavior. Thanks!
1
0
647
6d
Xcode 14 try to build all SPM when building swiftUI preview
HI, I have an issue displaying SwiftUI previews with Xcode 14. My project has iOS and an watchOS Target. It also includes a lot of SPM, most of them only used by the PhoneApp. The project build successfully for both iOS and watchOS. I can see that when building the watch target, only SPM that are included in this target are build for for watchOS The issue is when I try to build a swiftUI preview of the watch target. In this case I can see on the build for Preview log that Xcode try to build ALL spm defined in the Xcode project, including the one that are not used by the watch Target, As a lot if spm are for iOS only, and doesn't build for watchOS, the build for preview fails, and I'm unable to preview my swiftUI views on the AppeWatch. Note that my project is working fine on Xcode 13. This issue is easy to reproduce in any Xcode projects containing a iOS and watchOS target by adding a SPM that is only for iOS. Any workaround to fix this issue ?
18
7
7.3k
1w
SwiftUI iOS 26: Root ScrollView jumps during interactive pop when the Tab Bar is hidden
I encountered a SwiftUI navigation issue on iOS 26.3.1 with this structure: TabView NavigationStack(path:) custom root ScrollView The navigation stack hides the system Tab Bar while a destination is presented. When the root ScrollView is near its bottom, an interactive pop briefly exposes the root list at a lower vertical position, then snaps it back when the transition completes. Measured geometry on an iPhone 17 Pro Max simulator: Before navigation: offset 754.67, container height 733, bottom inset 107 During pop: offset 705.67, container height 782, bottom inset 58 After pop: offset 754.67, container height 733, bottom inset 107 The effective Tab Bar occupancy on this device was 49 points. During the transition, the container became 49 points taller and its bottom inset became 49 points smaller, causing SwiftUI to clamp the content offset near the bottom. The following approaches did not prevent the visible intermediate state: Adding more bottom spacing Disabling scroll content offset adjustment in the navigation path transaction Saving and restoring ScrollPosition after the pop .defaultScrollAnchor(.top, for: .sizeChanges) Moving Tab Bar visibility ownership to each destination view; this also produced a noticeable delay before the Tab Bar returned The workaround that has been reliable is: Keep Tab Bar visibility synchronized with whether the tab-owned NavigationStack path is empty. This preserves the normal system animation timing. Measure the Tab Bar's effective occupancy from public geometry: root ScrollView bottom inset window bottom safe-area inset the app's normal trailing scroll margin While navigation depth is greater than zero, preserve that measured amount with a clear safeAreaInset on the root ScrollView. When onScrollGeometryChange reports that the root page's system bottom inset has returned, release the reserved inset in a transaction with animations disabled. With this approach, the offset remained 754.67 throughout push and pop. The Tab Bar also returned at its original system-controlled time. The implementation uses public APIs only. It does not hard-code 49 points, traverse the UITabBar view hierarchy, poll system UI state, or restore an offset after the transition. Has anyone found an Apple-recommended alternative, or observed the same behavior on other iOS 26 versions?
1
0
581
1w
macOS 27 beta: ProMotion refresh cadence is unstable, causing constant scroll judder
FB24091347 On macOS 27.0 beta (26A5388g), MacBook Pro M4 Pro, the built-in ProMotion display never settles on a stable refresh cadence. Scrolling in SwiftUI judders constantly. The same app binary was smooth on macOS 26, and is smooth on a 120 Hz ProMotion iPad. I captured two 60-second Instruments traces — same app, same scene, same scrolling, no external display — changing only the display's refresh-rate setting. On ProMotion the vsync interval standard deviation is 4.093 ms across six different cadences, mostly flip-flopping between 120 Hz and 60 Hz. Forced to a fixed 60 Hz it drops to 0.391 ms with a single cadence. The app presented an identical 59 fps median in both runs — frame production is perfectly steady, the display just holds each frame for an unpredictable length of time. That's what makes this nasty: it's invisible to every frame-rate metric, so it looks like the app got slow when nothing about the app changed. I spent most of a day profiling my own code before realising the app was never the problem. Workaround: force the built-in display to 60 Hz. Worth noting, because it complicates the picture: attaching a 60 Hz Studio Display makes the built-in smooth, but the Studio itself then judders — despite its own vsync cadence measuring perfectly stable. So refresh rate alone isn't the whole story, and there may be a second mechanism. The clean, reproducible, single-variable result is the ProMotion vs forced-60 Hz comparison on the built-in panel. If you can reproduce this on an M-series MacBook Pro on 27 beta, please file a duplicate referencing FB24091347.
5
0
1.4k
1w
Grateful Moments Swift tutorial missing NavigationStack
hello. I was going through the Swift tutorial and am seeing that the code for MomentsViews.swift is showing as .sheet(isPresented: $showCreateMoment) { MomentEntryView() } but this makes the navigation title and toolbar not render. ChatGPT recommended this instead: .sheet(isPresented: $showCreateMoment) { NavigationStack { MomentEntryView() } } will the tutorial need to be updated or am I missing something elsewhere?
1
0
268
1w
PresentationComponent loses gaze targeting or dismisses in a volumetric window
On visionOS 26.6 and 27 latest beta: PresentationComponent in a volumetric WindowGroup, when looking at the volume from a specific lower/back region create two bugs: buttons inside the presentation have their gaze obstructed by hand presence, no button shows any hover highlight hand movement in that specific area auto dismisses the presentation The focused public repro uses a thin ModelEntity with InputTargetComponent and ordinary SwiftUI buttons. Its README includes two clearer videos: https://github.com/mesqueeb/PresentationAutoCloseInBackOfVolume 1. Gaze obstructed on buttons when hand is at specific location (see "Test Action" has no hover highlight, even though i look at it) 2. Hover state restored on buttons when hand is gone (see "Test Action" has hover highlight) 3. Presentation auto closed when hand comes back The weirdest part: This only happens at a specific location, when walking to the back of the volume, then turning around and interacting with the volume from the lower right back side. Any workaround or fix guidance would be appreciated. Feedback Assistant: FB24569418.
2
0
1.2k
1w
Double appearance of a button in .bottomBar ToolbarItem
I'm trying to understand why would a single button appear twice in the toolbar, like so: Do you see the eclipsed button peeking from underneath the top button? It's the same button, somehow doubled or cloned, or replicated. To reproduce it, I only needed to create a fresh iOS project in Xcode and apply this code change: diff --git a/BugRepro20260409/ContentView.swift b/BugRepro20260409/ContentView.swift index 426b298..d22433f 100644 --- a/BugRepro20260409/ContentView.swift +++ b/BugRepro20260409/ContentView.swift @@ -28,7 +28,7 @@ struct ContentView: View { ToolbarItem(placement: .navigationBarTrailing) { EditButton() } - ToolbarItem { + ToolbarItem(placement: .bottomBar) { Button(action: addItem) { Label("Add Item", systemImage: "plus") } This is all I needed to do for the double-vision button. Why would this button appear twice when moved to .bottomBar? By the way, when moved to the side and displayed on a smaller device like iPhone SE, the duplication is quite jarring: Interestingly, both buttons are active, and both trigger the same code path. Any ideas what's going on? ContentView.swift
2
0
1.1k
1w
Optimizing MapKit performance for high-frequency dynamic annotations / large datasets in Swift
Hi everyone, I am currently working on a SwiftUI / Swift client project that visualizes live, distributed infrastructure nodes across a dynamic map interface using MapKit. As the dataset scales and coordinates update dynamically, I want to ensure rendering performance stays smooth and memory overhead remains low. I would appreciate some guidance from the community on best practices for this scenario: Clustering vs. Custom Overlays: For frequently updating data points, is native annotation clustering (MKClusterAnnotation / clusteringIdentifier) the standard recommendation, or does heavy clustering introduce recalculation overhead during rapid state changes? Visible Region Filtering: What is the recommended pattern in modern MapKit (SwiftUI Map vs. MKMapViewRepresentable) for culling off-screen data points vs. letting MapKit handle view recycling? High-Frequency Updates: When coordinates or statuses update frequently (e.g., via polling or streaming data), what are the best practices to avoid unnecessary view rebuilds and maintain 60/120 FPS panning and zooming? Any architectural tips, performance benchmarks, or WWDC sessions you recommend reviewing for large-scale dynamic rendering would be greatly appreciated! Thanks in advance.
0
0
120
1w
iOS 26: .inlineLarge collapsed bar loses its title and bar material after scroll collapse when a custom .largeTitle ToolbarItem is present (FB24528594)
On iOS 26.5, combining the .inlineLarge navigation bar mode with a custom ToolbarItem(placement: .largeTitle) breaks the collapsed bar: after any scroll collapse, the compact bar renders with no title, no bar material or scroll edge treatment, and content draws through the status bar. It recovers on re-expansion. Details from my minimal repro (filed as FB24528594, single-file project attached to the report): The .title item is not required to trigger it. .inlineLarge plus only a custom ToolbarItem(placement: .largeTitle) reproduces it on every collapse. A .largeSubtitle item alone does not trigger it. Adding one alongside the .largeTitle item breaks the same way, with the subtitle content vanishing too. Reproduces 100% on the iOS 26.5 simulator (Xcode 26.6), light and dark. Workarounds tried without success: setting navigationItem.titleView does not hold, because SwiftUI re-renders the compact title after toolbar churn. Two questions for the engineering team: is this a known bug, and is there any supported way to keep a custom large-title toolbar arrangement while preserving the compact bar's title and material through collapse? I have a design that places an avatar in the large-title row and this is currently the blocker. Happy to provide anything beyond what's in FB24528594.
0
0
106
1w
Swipe to go back still broken with Zoom navigation transition.
When you use .navigationTransition(.zoom(sourceID: "placeholder", in: placehoder)) for navigation animation, going back using the swipe gesture is still very buggy on IOS26. I know it has been mentioned in other places like here: https://developer.apple.com/forums/thread/796805?answerId=856846022#856846022 but nothing seems to have been done to fix this issue. Here is a video showing the bug comparing when the back button is used vs swipe to go back: https://imgur.com/a/JgEusRH I wish there was a way to at least disable the swipe back gesture until this bug is fixed.
11
4
2.5k
2w
iOS 27 beta 1: .scrollEdgeEffectStyle(.soft) renders fully transparent above safeAreaBar
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.
Replies
19
Boosts
13
Views
3.8k
Activity
17h
SwiftUI safe area stays offset after keyboard dismissal with “Reduce Motion” + “Prefer Cross-Fade” enabled (iOS 26)
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.
Replies
7
Boosts
2
Views
2.1k
Activity
22h
iOS Dynamically loaded custom fonts in WidgetKit not working on real device (simulator is fine). Sandbox chronod deny file-read-data for font file.
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.
Replies
8
Boosts
1
Views
3.4k
Activity
1d
HistoryObserver eventCounter updating 9-16 times per app launch because of CloudKit syncing?
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.
Replies
0
Boosts
0
Views
241
Activity
1d
iOS 27 regression: Objects whose properties are bound to items displayed in a Menu are not correctly deallocated
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.
Replies
4
Boosts
0
Views
1.5k
Activity
1d
SwiftUI alert dismisses immediately when presented from a nested sheet
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.
Replies
6
Boosts
0
Views
211
Activity
1d
safeaAreaBar
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
Replies
1
Boosts
0
Views
315
Activity
1d
iOS 26: navigation bar leading item's glass platter renders offset after the container view's origin changes
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?
Replies
0
Boosts
0
Views
3k
Activity
2d
SwiftUI Button has different internal padding depending on label text length
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!
Replies
0
Boosts
0
Views
218
Activity
3d
How can I prevent Siri Remote Back button from dismissing a fullScreenCover on tvOS?
I'm developing a tvOS application using SwiftUI, and I have a custom video player presented using fullScreenCover. .fullScreenCover(isPresented: $isPlayerPresented) { PlayerView() } I would like to implement the same kind of behavior commonly seen in video players: The player is presented full screen. When the playback controls are visible, pressing the Siri Remote Back button should hide the controls. The player should remain presented. Only when the controls are already hidden should pressing Back dismiss the player. However, I am unable to intercept the Back button before the fullScreenCover is dismissed. I have tried several approaches, including: .onExitCommand { // Handle Back } and handling UIPress / .menu events through UIKit. The problem is that when the Siri Remote Back button is pressed while the view is presented using fullScreenCover, the fullScreenCover is dismissed directly. My custom view does not appear to be able to prevent the dismissal. I also tried placing a custom UIView / UITapGestureRecognizer inside the fullScreenCover to intercept the remote button event, but the presentation is still dismissed. According to the SwiftUI documentation, onExitCommand responds to the tvOS exit command generated by the Menu button, but it does not appear to provide a way to prevent the system from dismissing a fullScreenCover in response to the Siri Remote Back button. I also noticed that interactiveDismissDisabled(_:) does not appear to provide a solution for this particular tvOS behavior. My questions Is the Siri Remote Back button expected to automatically dismiss a SwiftUI fullScreenCover on tvOS? Is there a supported API to intercept the Back button before the fullScreenCover is dismissed? Is there a way to tell SwiftUI that a fullScreenCover should not be dismissed by the Siri Remote Back button? If fullScreenCover is not intended for this use case, what is the recommended way to implement a custom full-screen video player that needs to control Back-button behavior? The desired behavior is essentially: Back button ↓ Are playback controls visible? ├── Yes → hide controls, keep player presented └── No → dismiss player I would appreciate any guidance on the intended tvOS API or recommended architecture for implementing this behavior. Thanks!
Replies
1
Boosts
0
Views
647
Activity
6d
Xcode 14 try to build all SPM when building swiftUI preview
HI, I have an issue displaying SwiftUI previews with Xcode 14. My project has iOS and an watchOS Target. It also includes a lot of SPM, most of them only used by the PhoneApp. The project build successfully for both iOS and watchOS. I can see that when building the watch target, only SPM that are included in this target are build for for watchOS The issue is when I try to build a swiftUI preview of the watch target. In this case I can see on the build for Preview log that Xcode try to build ALL spm defined in the Xcode project, including the one that are not used by the watch Target, As a lot if spm are for iOS only, and doesn't build for watchOS, the build for preview fails, and I'm unable to preview my swiftUI views on the AppeWatch. Note that my project is working fine on Xcode 13. This issue is easy to reproduce in any Xcode projects containing a iOS and watchOS target by adding a SPM that is only for iOS. Any workaround to fix this issue ?
Replies
18
Boosts
7
Views
7.3k
Activity
1w
SwiftUI iOS 26: Root ScrollView jumps during interactive pop when the Tab Bar is hidden
I encountered a SwiftUI navigation issue on iOS 26.3.1 with this structure: TabView NavigationStack(path:) custom root ScrollView The navigation stack hides the system Tab Bar while a destination is presented. When the root ScrollView is near its bottom, an interactive pop briefly exposes the root list at a lower vertical position, then snaps it back when the transition completes. Measured geometry on an iPhone 17 Pro Max simulator: Before navigation: offset 754.67, container height 733, bottom inset 107 During pop: offset 705.67, container height 782, bottom inset 58 After pop: offset 754.67, container height 733, bottom inset 107 The effective Tab Bar occupancy on this device was 49 points. During the transition, the container became 49 points taller and its bottom inset became 49 points smaller, causing SwiftUI to clamp the content offset near the bottom. The following approaches did not prevent the visible intermediate state: Adding more bottom spacing Disabling scroll content offset adjustment in the navigation path transaction Saving and restoring ScrollPosition after the pop .defaultScrollAnchor(.top, for: .sizeChanges) Moving Tab Bar visibility ownership to each destination view; this also produced a noticeable delay before the Tab Bar returned The workaround that has been reliable is: Keep Tab Bar visibility synchronized with whether the tab-owned NavigationStack path is empty. This preserves the normal system animation timing. Measure the Tab Bar's effective occupancy from public geometry: root ScrollView bottom inset window bottom safe-area inset the app's normal trailing scroll margin While navigation depth is greater than zero, preserve that measured amount with a clear safeAreaInset on the root ScrollView. When onScrollGeometryChange reports that the root page's system bottom inset has returned, release the reserved inset in a transaction with animations disabled. With this approach, the offset remained 754.67 throughout push and pop. The Tab Bar also returned at its original system-controlled time. The implementation uses public APIs only. It does not hard-code 49 points, traverse the UITabBar view hierarchy, poll system UI state, or restore an offset after the transition. Has anyone found an Apple-recommended alternative, or observed the same behavior on other iOS 26 versions?
Replies
1
Boosts
0
Views
581
Activity
1w
macOS 27 beta: ProMotion refresh cadence is unstable, causing constant scroll judder
FB24091347 On macOS 27.0 beta (26A5388g), MacBook Pro M4 Pro, the built-in ProMotion display never settles on a stable refresh cadence. Scrolling in SwiftUI judders constantly. The same app binary was smooth on macOS 26, and is smooth on a 120 Hz ProMotion iPad. I captured two 60-second Instruments traces — same app, same scene, same scrolling, no external display — changing only the display's refresh-rate setting. On ProMotion the vsync interval standard deviation is 4.093 ms across six different cadences, mostly flip-flopping between 120 Hz and 60 Hz. Forced to a fixed 60 Hz it drops to 0.391 ms with a single cadence. The app presented an identical 59 fps median in both runs — frame production is perfectly steady, the display just holds each frame for an unpredictable length of time. That's what makes this nasty: it's invisible to every frame-rate metric, so it looks like the app got slow when nothing about the app changed. I spent most of a day profiling my own code before realising the app was never the problem. Workaround: force the built-in display to 60 Hz. Worth noting, because it complicates the picture: attaching a 60 Hz Studio Display makes the built-in smooth, but the Studio itself then judders — despite its own vsync cadence measuring perfectly stable. So refresh rate alone isn't the whole story, and there may be a second mechanism. The clean, reproducible, single-variable result is the ProMotion vs forced-60 Hz comparison on the built-in panel. If you can reproduce this on an M-series MacBook Pro on 27 beta, please file a duplicate referencing FB24091347.
Replies
5
Boosts
0
Views
1.4k
Activity
1w
Grateful Moments Swift tutorial missing NavigationStack
hello. I was going through the Swift tutorial and am seeing that the code for MomentsViews.swift is showing as .sheet(isPresented: $showCreateMoment) { MomentEntryView() } but this makes the navigation title and toolbar not render. ChatGPT recommended this instead: .sheet(isPresented: $showCreateMoment) { NavigationStack { MomentEntryView() } } will the tutorial need to be updated or am I missing something elsewhere?
Replies
1
Boosts
0
Views
268
Activity
1w
PresentationComponent loses gaze targeting or dismisses in a volumetric window
On visionOS 26.6 and 27 latest beta: PresentationComponent in a volumetric WindowGroup, when looking at the volume from a specific lower/back region create two bugs: buttons inside the presentation have their gaze obstructed by hand presence, no button shows any hover highlight hand movement in that specific area auto dismisses the presentation The focused public repro uses a thin ModelEntity with InputTargetComponent and ordinary SwiftUI buttons. Its README includes two clearer videos: https://github.com/mesqueeb/PresentationAutoCloseInBackOfVolume 1. Gaze obstructed on buttons when hand is at specific location (see "Test Action" has no hover highlight, even though i look at it) 2. Hover state restored on buttons when hand is gone (see "Test Action" has hover highlight) 3. Presentation auto closed when hand comes back The weirdest part: This only happens at a specific location, when walking to the back of the volume, then turning around and interacting with the volume from the lower right back side. Any workaround or fix guidance would be appreciated. Feedback Assistant: FB24569418.
Replies
2
Boosts
0
Views
1.2k
Activity
1w
Double appearance of a button in .bottomBar ToolbarItem
I'm trying to understand why would a single button appear twice in the toolbar, like so: Do you see the eclipsed button peeking from underneath the top button? It's the same button, somehow doubled or cloned, or replicated. To reproduce it, I only needed to create a fresh iOS project in Xcode and apply this code change: diff --git a/BugRepro20260409/ContentView.swift b/BugRepro20260409/ContentView.swift index 426b298..d22433f 100644 --- a/BugRepro20260409/ContentView.swift +++ b/BugRepro20260409/ContentView.swift @@ -28,7 +28,7 @@ struct ContentView: View { ToolbarItem(placement: .navigationBarTrailing) { EditButton() } - ToolbarItem { + ToolbarItem(placement: .bottomBar) { Button(action: addItem) { Label("Add Item", systemImage: "plus") } This is all I needed to do for the double-vision button. Why would this button appear twice when moved to .bottomBar? By the way, when moved to the side and displayed on a smaller device like iPhone SE, the duplication is quite jarring: Interestingly, both buttons are active, and both trigger the same code path. Any ideas what's going on? ContentView.swift
Replies
2
Boosts
0
Views
1.1k
Activity
1w
Optimizing MapKit performance for high-frequency dynamic annotations / large datasets in Swift
Hi everyone, I am currently working on a SwiftUI / Swift client project that visualizes live, distributed infrastructure nodes across a dynamic map interface using MapKit. As the dataset scales and coordinates update dynamically, I want to ensure rendering performance stays smooth and memory overhead remains low. I would appreciate some guidance from the community on best practices for this scenario: Clustering vs. Custom Overlays: For frequently updating data points, is native annotation clustering (MKClusterAnnotation / clusteringIdentifier) the standard recommendation, or does heavy clustering introduce recalculation overhead during rapid state changes? Visible Region Filtering: What is the recommended pattern in modern MapKit (SwiftUI Map vs. MKMapViewRepresentable) for culling off-screen data points vs. letting MapKit handle view recycling? High-Frequency Updates: When coordinates or statuses update frequently (e.g., via polling or streaming data), what are the best practices to avoid unnecessary view rebuilds and maintain 60/120 FPS panning and zooming? Any architectural tips, performance benchmarks, or WWDC sessions you recommend reviewing for large-scale dynamic rendering would be greatly appreciated! Thanks in advance.
Replies
0
Boosts
0
Views
120
Activity
1w
iOS 26: .inlineLarge collapsed bar loses its title and bar material after scroll collapse when a custom .largeTitle ToolbarItem is present (FB24528594)
On iOS 26.5, combining the .inlineLarge navigation bar mode with a custom ToolbarItem(placement: .largeTitle) breaks the collapsed bar: after any scroll collapse, the compact bar renders with no title, no bar material or scroll edge treatment, and content draws through the status bar. It recovers on re-expansion. Details from my minimal repro (filed as FB24528594, single-file project attached to the report): The .title item is not required to trigger it. .inlineLarge plus only a custom ToolbarItem(placement: .largeTitle) reproduces it on every collapse. A .largeSubtitle item alone does not trigger it. Adding one alongside the .largeTitle item breaks the same way, with the subtitle content vanishing too. Reproduces 100% on the iOS 26.5 simulator (Xcode 26.6), light and dark. Workarounds tried without success: setting navigationItem.titleView does not hold, because SwiftUI re-renders the compact title after toolbar churn. Two questions for the engineering team: is this a known bug, and is there any supported way to keep a custom large-title toolbar arrangement while preserving the compact bar's title and material through collapse? I have a design that places an avatar in the large-title row and this is currently the blocker. Happy to provide anything beyond what's in FB24528594.
Replies
0
Boosts
0
Views
106
Activity
1w
Disable Ask Siri
How do I disable the "Ask Siri" button in the SwiftUl context menu in macOS?
Replies
1
Boosts
1
Views
364
Activity
1w
Swipe to go back still broken with Zoom navigation transition.
When you use .navigationTransition(.zoom(sourceID: "placeholder", in: placehoder)) for navigation animation, going back using the swipe gesture is still very buggy on IOS26. I know it has been mentioned in other places like here: https://developer.apple.com/forums/thread/796805?answerId=856846022#856846022 but nothing seems to have been done to fix this issue. Here is a video showing the bug comparing when the back button is used vs swipe to go back: https://imgur.com/a/JgEusRH I wish there was a way to at least disable the swipe back gesture until this bug is fixed.
Replies
11
Boosts
4
Views
2.5k
Activity
2w