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

SwiftUI Documentation

Posts under SwiftUI subtopic

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.5k
4h
Paged ScrollView loses page alignment when resized on iOS 27
A paged ScrollView loses its page when the window is resized on iPadOS 27: ScrollView(.horizontal) { HStack(spacing: 0) { ForEach(pages) { page in PageView(page).containerRelativeFrame(.horizontal) } } .scrollTargetLayout() } .scrollTargetBehavior(.paging) .scrollPosition(id: $selection) Expected: the selected page stays edge-aligned after the resize (as TabView(.page) does). Actual: The content offset is preserved in points, not pages — the view rests between pages. scrollPosition(id:) writes nil during the resize, so the selection can't be recovered from the binding. Both .paging and .viewAligned are affected. Repro project (broken ScrollView, TabView control, and workaround side by side, with live instrumentation): https://github.com/katebrr/PagedScrollResizeLab Why not TabView(.page): it has no API for scroll position/progress observation (our analytics depend on it), inter-page spacing, partial-width peeking pages, or pausing the swipe mid-gesture. Workaround (Workaround/View+ScrollPositionResize.swift in the repo): restore the last non-nil selection via scrollTo one Task.yield() after the resize. Works, but lands a frame late and relies on undocumented behavior. Questions: Is this behavior intended, or a bug? Is there a supported way to keep a paged ScrollView anchored to its page across resizes? Is there a more robust formulation than scrollTo after Task.yield()? Filed as FB24688033.
Topic: UI Frameworks SubTopic: SwiftUI
4
1
244
10h
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
198
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
312
1d
Live Activity ending immediately after being created
I'm seeing a Live Activity that's ended almost immediately after I'm creating it. I'm not ending the activity in my code, so something is happening at the system level. iOS version is 18.3.1. Looking at the logs for liveactivitiesd, I see that it was successfully created: default 12:57:34.837266-0800 liveactivitiesd Created activity: 22713DF6-E853-4B34-85FA-CD08D8FCA91B default 12:57:34.837639-0800 liveactivitiesd Starting activity: identifier: 22713DF6-E853-4B34-85FA-CD08D8FCA91B; createdDate: 2025-02-17 20:57:34 +0000; state: active; deviceIdentifier: local; resolvedContentSources: [ActivityKit.ActivityContentSource.process(target: <snip>), ActivityKit.ActivityContentSource.sync]; lastUpdateDate: 2025-02-17 20:57:34 +0000; endingOptions: nil default 12:57:34.858701-0800 liveactivitiesd Activity did start 22713DF6-E853-4B34-85FA-CD08D8FCA91B But then moments later, it's immediately ended: default 12:57:34.933963-0800 liveactivitiesd Ending activity 22713DF6-E853-4B34-85FA-CD08D8FCA91B for XPC participant content source <private> default 12:57:34.933983-0800 liveactivitiesd Stopping activity: 22713DF6-E853-4B34-85FA-CD08D8FCA91B default 12:57:34.934019-0800 liveactivitiesd Activity: identifier: 22713DF6-E853-4B34-85FA-CD08D8FCA91B; createdDate: 2025-02-17 20:57:34 +0000; state: active; deviceIdentifier: local; resolvedContentSources: [ActivityKit.ActivityContentSource.process(target: <snip>), ActivityKit.ActivityContentSource.sync]; lastUpdateDate: 2025-02-17 20:57:34 +0000; endingOptions: nil should be discarded now default 12:57:34.934442-0800 liveactivitiesd Activity discarded: 22713DF6-E853-4B34-85FA-CD08D8FCA91B Again, I'm not ending this activity in my code. I'll occasionally see this happen in my app, and the only solution I've found is to restart my device. Afterwards, everything seems fine. Is this a bug?
4
2
738
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
1d
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
215
2d
AppStore.requestReview(in:) never presents on iOS 27 Simulator (works on iOS 26)
Calling AppStore.requestReview(in:) with a valid, foreground-active UIWindowScene never presents the rating/review sheet on iOS 27 Simulator. The identical code works correctly on iOS 26 and earlier Simulator runtimes. Repro: if let windowScene = UIApplication.shared.connectedScenes .compactMap({ $0 as? UIWindowScene }) .first(where: { $0.activationState == .foregroundActive }) { AppStore.requestReview(in: windowScene) } Fresh Simulator install (Erase All Content and Settings first, to rule out the 3-per-365-day throttle). Run on iOS 27 Simulator → no sheet appears, no error, no console output. Run the identical build on iOS 26 Simulator → sheet appears as expected. Also tried: The SwiftUI @Environment(.requestReview) action (RequestReviewAction) instead of the UIKit windowScene call — same result, no prompt on iOS 27 Simulator. Ruled out an Xcode/Simulator-runtime version mismatch: reproduces both with an older Xcode + separately-downloaded iOS 27 runtime, AND with the matching Xcode 27 beta + its bundled iOS 27 Simulator. Checked the iOS 27 beta release notes — no mention of requestReview/StoreKit review prompt changes. Environment: Xcode [fill in version/beta] iOS 27 Simulator (beta [fill in]) Simulator device: [e.g. iPhone 16] Expected: Review prompt presents (subject to the documented frequency limit), matching iOS 26 behavior. Actual: No prompt, no error, on both the UIKit and SwiftUI review-request APIs.
3
0
1.3k
2d
iOS 27 SwiftUI zoom: toolbar remains and root content briefly stops responding after rapid swipe-back
Feedback: FB24659815. I have submitted a screen recording and screenshot through Feedback Assistant. In GGame, quickly swiping back after opening a game home page with the system SwiftUI zoom transition leaves the destination navigation title, back button, settings button and history button over the visible lobby for about one second. During that interval, lobby content does not respond to taps or scrolling, while the tab bar still works. Steps to reproduce: Open the game lobby. Tap a game icon to enter its home page using zoom. Immediately swipe right to return, attempting to interrupt the incoming animation. When the lobby reappears, immediately try to tap or scroll its content and observe the navigation controls. Expected: once the return transition finishes, the destination controls disappear and the visible lobby accepts taps and scrolling. Interrupted entry and cancelled interactive return should remain supported. Current investigation environment: iPhone 16 Pro, iOS 27.0 Seed 7 (24A5430a), Xcode 27 beta 4. The supplied owner recording shows the visual symptom across Connect Four, Chinese Chess and Chess; the exact build used in those original attachments has not been independently verified. The app uses NavigationStack, matchedTransitionSource and navigationTransition(.zoom(...)). It also has application-side navigation-bar visibility, transition-state and gesture coordination. We have not isolated the exact symptoms in a minimal project without that logic, so the root cause remains unconfirmed. Potentially related discussions: https://developer.apple.com/forums/thread/796805 https://developer.apple.com/forums/thread/802908 Those reports primarily describe disappearing source views that remain tappable. Our issue involves lingering destination controls and temporarily unresponsive root content. I am opening a separate thread to track these differences. Has anyone observed this specific combination? Could the SwiftUI/navigation team check FB24659815 and advise whether this is a framework issue or an application-side lifecycle/gesture interaction? We would appreciate a fix or supported workaround that preserves the system zoom animation and interactive cancellation. The temporary loss of lobby interaction makes this especially disruptive.
Topic: UI Frameworks SubTopic: SwiftUI Tags:
0
0
493
4d
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
641
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
6d
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
572
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
264
1w
Conformance of Optional to AccessibilityRotorContent is incorrectly available from iOS 27
Using accessibilityRotor(_:entries:) as described in the documentation works fine on Xcode 26 and iOS 26 whereas it fails to compile on Xcode 27 when at least iOS 26 is selected as the minimum deployment target. .accessibilityElement(children: .contain) .accessibilityRotor("VIPs") { // ❗️Conformance of 'Optional<Wrapped>' to 'AccessibilityRotorContent' is only available in iOS 27.0 or newer ForEach(messages) { message in // If the Message is from a VIP, make a Rotor entry for it. if message.isVIP { AccessibilityRotorEntry(message.subject, id: message.id) } } } The error states "Conformance of 'Optional' to 'AccessibilityRotorContent' is only available in iOS 27.0 or newer" which should not be the case as the code was compiling prior to Xcode and iOS 27. Feedback is FB24587642. It contains a sample project to reproduce the issue. Using Xcode 27 beta 6 with iOS 26 as minimum deployment target and Swift 6 language mode.
0
0
64
1w
CarPlay Video entitlement causes blank screen and no CPTemplateApplicationScene callbacks
I have CarPlay Video enabled for my account and App ID. I tested both my main app and a completely new minimal iOS app with a new Bundle ID. The minimal app only contains: UIApplicationDelegate CPTemplateApplicationScene configuration CPTemplateApplicationSceneDelegate A single CPListTemplate root Results: With com.apple.developer.carplay-audio only, CarPlay launches normally. When com.apple.developer.carplay-video is added, CarPlay opens a blank screen. No CarPlay callbacks are called: application(:configurationForConnecting:options:) CPTemplateApplicationSceneDelegate.templateApplicationScene(:didConnect:) CPApplicationDelegate.didConnectCarInterfaceController The signed app and embedded provisioning profile both contain com.apple.developer.carplay-video. Does CarPlay Video require an additional runtime allowlist, specific head unit support, a different scene configuration, or another entitlement beyond com.apple.developer.carplay-video?
3
0
440
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
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.5k
Activity
4h
SuspendingClock how do I use it
I;m trying to write a function that returns elapsed time in milliseconds. from the developer decimation it looks like I should use SuspendingClock. But beyond that I haven't got a clue. Any suggestions?
Replies
0
Boosts
0
Views
18
Activity
6h
Paged ScrollView loses page alignment when resized on iOS 27
A paged ScrollView loses its page when the window is resized on iPadOS 27: ScrollView(.horizontal) { HStack(spacing: 0) { ForEach(pages) { page in PageView(page).containerRelativeFrame(.horizontal) } } .scrollTargetLayout() } .scrollTargetBehavior(.paging) .scrollPosition(id: $selection) Expected: the selected page stays edge-aligned after the resize (as TabView(.page) does). Actual: The content offset is preserved in points, not pages — the view rests between pages. scrollPosition(id:) writes nil during the resize, so the selection can't be recovered from the binding. Both .paging and .viewAligned are affected. Repro project (broken ScrollView, TabView control, and workaround side by side, with live instrumentation): https://github.com/katebrr/PagedScrollResizeLab Why not TabView(.page): it has no API for scroll position/progress observation (our analytics depend on it), inter-page spacing, partial-width peeking pages, or pausing the swipe mid-gesture. Workaround (Workaround/View+ScrollPositionResize.swift in the repo): restore the last non-nil selection via scrollTo one Task.yield() after the resize. Works, but lands a frame late and relies on undocumented behavior. Questions: Is this behavior intended, or a bug? Is there a supported way to keep a paged ScrollView anchored to its page across resizes? Is there a more robust formulation than scrollTo after Task.yield()? Filed as FB24688033.
Topic: UI Frameworks SubTopic: SwiftUI
Replies
4
Boosts
1
Views
244
Activity
10h
How to avoid the traffic light buttons on iPad
Right now, the traffic light buttons overlapped on my iPad app top corner on windows mode (full screen is fine). How do I properly design my app to avoid the traffic light buttons? Detect that it is iPadOS 26?
Topic: UI Frameworks SubTopic: SwiftUI
Replies
7
Boosts
4
Views
1k
Activity
12h
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 Menu in iOS 26 Dark Mode does not render properly
I'm currently developing a new app and uses Menu in it. The Menu cannot display text color normally and after if collapses my second text also disappears for a short time. FB19221675 Does anyone has this same issue in iOS 26?
Topic: UI Frameworks SubTopic: SwiftUI
Replies
4
Boosts
1
Views
758
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
198
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
312
Activity
1d
Live Activity ending immediately after being created
I'm seeing a Live Activity that's ended almost immediately after I'm creating it. I'm not ending the activity in my code, so something is happening at the system level. iOS version is 18.3.1. Looking at the logs for liveactivitiesd, I see that it was successfully created: default 12:57:34.837266-0800 liveactivitiesd Created activity: 22713DF6-E853-4B34-85FA-CD08D8FCA91B default 12:57:34.837639-0800 liveactivitiesd Starting activity: identifier: 22713DF6-E853-4B34-85FA-CD08D8FCA91B; createdDate: 2025-02-17 20:57:34 +0000; state: active; deviceIdentifier: local; resolvedContentSources: [ActivityKit.ActivityContentSource.process(target: <snip>), ActivityKit.ActivityContentSource.sync]; lastUpdateDate: 2025-02-17 20:57:34 +0000; endingOptions: nil default 12:57:34.858701-0800 liveactivitiesd Activity did start 22713DF6-E853-4B34-85FA-CD08D8FCA91B But then moments later, it's immediately ended: default 12:57:34.933963-0800 liveactivitiesd Ending activity 22713DF6-E853-4B34-85FA-CD08D8FCA91B for XPC participant content source <private> default 12:57:34.933983-0800 liveactivitiesd Stopping activity: 22713DF6-E853-4B34-85FA-CD08D8FCA91B default 12:57:34.934019-0800 liveactivitiesd Activity: identifier: 22713DF6-E853-4B34-85FA-CD08D8FCA91B; createdDate: 2025-02-17 20:57:34 +0000; state: active; deviceIdentifier: local; resolvedContentSources: [ActivityKit.ActivityContentSource.process(target: <snip>), ActivityKit.ActivityContentSource.sync]; lastUpdateDate: 2025-02-17 20:57:34 +0000; endingOptions: nil should be discarded now default 12:57:34.934442-0800 liveactivitiesd Activity discarded: 22713DF6-E853-4B34-85FA-CD08D8FCA91B Again, I'm not ending this activity in my code. I'll occasionally see this happen in my app, and the only solution I've found is to restart my device. Afterwards, everything seems fine. Is this a bug?
Replies
4
Boosts
2
Views
738
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
1d
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
215
Activity
2d
AppStore.requestReview(in:) never presents on iOS 27 Simulator (works on iOS 26)
Calling AppStore.requestReview(in:) with a valid, foreground-active UIWindowScene never presents the rating/review sheet on iOS 27 Simulator. The identical code works correctly on iOS 26 and earlier Simulator runtimes. Repro: if let windowScene = UIApplication.shared.connectedScenes .compactMap({ $0 as? UIWindowScene }) .first(where: { $0.activationState == .foregroundActive }) { AppStore.requestReview(in: windowScene) } Fresh Simulator install (Erase All Content and Settings first, to rule out the 3-per-365-day throttle). Run on iOS 27 Simulator → no sheet appears, no error, no console output. Run the identical build on iOS 26 Simulator → sheet appears as expected. Also tried: The SwiftUI @Environment(.requestReview) action (RequestReviewAction) instead of the UIKit windowScene call — same result, no prompt on iOS 27 Simulator. Ruled out an Xcode/Simulator-runtime version mismatch: reproduces both with an older Xcode + separately-downloaded iOS 27 runtime, AND with the matching Xcode 27 beta + its bundled iOS 27 Simulator. Checked the iOS 27 beta release notes — no mention of requestReview/StoreKit review prompt changes. Environment: Xcode [fill in version/beta] iOS 27 Simulator (beta [fill in]) Simulator device: [e.g. iPhone 16] Expected: Review prompt presents (subject to the documented frequency limit), matching iOS 26 behavior. Actual: No prompt, no error, on both the UIKit and SwiftUI review-request APIs.
Replies
3
Boosts
0
Views
1.3k
Activity
2d
iOS 27 SwiftUI zoom: toolbar remains and root content briefly stops responding after rapid swipe-back
Feedback: FB24659815. I have submitted a screen recording and screenshot through Feedback Assistant. In GGame, quickly swiping back after opening a game home page with the system SwiftUI zoom transition leaves the destination navigation title, back button, settings button and history button over the visible lobby for about one second. During that interval, lobby content does not respond to taps or scrolling, while the tab bar still works. Steps to reproduce: Open the game lobby. Tap a game icon to enter its home page using zoom. Immediately swipe right to return, attempting to interrupt the incoming animation. When the lobby reappears, immediately try to tap or scroll its content and observe the navigation controls. Expected: once the return transition finishes, the destination controls disappear and the visible lobby accepts taps and scrolling. Interrupted entry and cancelled interactive return should remain supported. Current investigation environment: iPhone 16 Pro, iOS 27.0 Seed 7 (24A5430a), Xcode 27 beta 4. The supplied owner recording shows the visual symptom across Connect Four, Chinese Chess and Chess; the exact build used in those original attachments has not been independently verified. The app uses NavigationStack, matchedTransitionSource and navigationTransition(.zoom(...)). It also has application-side navigation-bar visibility, transition-state and gesture coordination. We have not isolated the exact symptoms in a minimal project without that logic, so the root cause remains unconfirmed. Potentially related discussions: https://developer.apple.com/forums/thread/796805 https://developer.apple.com/forums/thread/802908 Those reports primarily describe disappearing source views that remain tappable. Our issue involves lingering destination controls and temporarily unresponsive root content. I am opening a separate thread to track these differences. Has anyone observed this specific combination? Could the SwiftUI/navigation team check FB24659815 and advise whether this is a framework issue or an application-side lifecycle/gesture interaction? We would appreciate a fix or supported workaround that preserves the system zoom animation and interactive cancellation. The temporary loss of lobby interaction makes this especially disruptive.
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Replies
0
Boosts
0
Views
493
Activity
4d
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
641
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
6d
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
572
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
264
Activity
1w
Conformance of Optional to AccessibilityRotorContent is incorrectly available from iOS 27
Using accessibilityRotor(_:entries:) as described in the documentation works fine on Xcode 26 and iOS 26 whereas it fails to compile on Xcode 27 when at least iOS 26 is selected as the minimum deployment target. .accessibilityElement(children: .contain) .accessibilityRotor("VIPs") { // ❗️Conformance of 'Optional<Wrapped>' to 'AccessibilityRotorContent' is only available in iOS 27.0 or newer ForEach(messages) { message in // If the Message is from a VIP, make a Rotor entry for it. if message.isVIP { AccessibilityRotorEntry(message.subject, id: message.id) } } } The error states "Conformance of 'Optional' to 'AccessibilityRotorContent' is only available in iOS 27.0 or newer" which should not be the case as the code was compiling prior to Xcode and iOS 27. Feedback is FB24587642. It contains a sample project to reproduce the issue. Using Xcode 27 beta 6 with iOS 26 as minimum deployment target and Swift 6 language mode.
Replies
0
Boosts
0
Views
64
Activity
1w
CarPlay Video entitlement causes blank screen and no CPTemplateApplicationScene callbacks
I have CarPlay Video enabled for my account and App ID. I tested both my main app and a completely new minimal iOS app with a new Bundle ID. The minimal app only contains: UIApplicationDelegate CPTemplateApplicationScene configuration CPTemplateApplicationSceneDelegate A single CPListTemplate root Results: With com.apple.developer.carplay-audio only, CarPlay launches normally. When com.apple.developer.carplay-video is added, CarPlay opens a blank screen. No CarPlay callbacks are called: application(:configurationForConnecting:options:) CPTemplateApplicationSceneDelegate.templateApplicationScene(:didConnect:) CPApplicationDelegate.didConnectCarInterfaceController The signed app and embedded provisioning profile both contain com.apple.developer.carplay-video. Does CarPlay Video require an additional runtime allowlist, specific head unit support, a different scene configuration, or another entitlement beyond com.apple.developer.carplay-video?
Replies
3
Boosts
0
Views
440
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