Hello,
I am experiencing a crash in a SwiftUI app.
It happens when I place multiple views inside a ScrollView.
The crash occurs only on a physical device (it does not reproduce in the Simulator).
It happens during runtime, seemingly while SwiftUI is updating or laying out the view hierarchy.
I have not been able to determine the exact cause.
I am attaching a text file with the entire backtrace from LLDB.
swiftui_crash_backtrace
Is this a known SwiftUI issue?
Any recommendations on how to further investigate or work around it?
Any help or suggestions would be appreciated.
Xcode 16.3 / iOS 18.6.2
Thank you!
SwiftUI
RSS for tagProvide views, controls, and layout structures for declaring your app's user interface using SwiftUI.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Hello,
I’ve encountered what seems to be a bug with the keyboard dismissal animation on iOS 26.0 Beta (25A5349a), Xcode Version 26.0 beta 5 (17A5295f).
When dismissing the keyboard from a SwiftUI TextField using @FocusState, the keyboard does not animate downward as expected. Instead, it instantly disappears, which feels jarring and inconsistent with system behavior.
I am attaching a short video demonstrating the issue. Below is the minimal reproducible code sample:
//
// ContentView.swift
// TestingKeyboardDismissal
//
// Created by Sasha Morozov on 27/08/25.
//
import SwiftUI
struct ContentView: View {
@State private var text: String = ""
@FocusState private var isFocused: Bool
var body: some View {
ZStack {
Color.clear.ignoresSafeArea()
VStack(spacing: 20) {
TextField("Enter text here...", text: $text)
.textFieldStyle(.roundedBorder)
.focused($isFocused)
.padding(.horizontal)
HStack {
Button("Focus") { isFocused = true }
.buttonStyle(.borderedProminent)
Button("Unfocus") { isFocused = false }
.buttonStyle(.bordered)
}
}
.frame(maxWidth: .infinity, maxHeight: .infinity, alignment: .center)
.padding()
}
.ignoresSafeArea(.keyboard, edges: .bottom)
}
}
#Preview {
ContentView()
}
Steps to reproduce:
Run** the app on iOS 26.0 beta 5 (17A5295f).
Tap Focus → keyboard appears as expected.
Tap Unfocus → keyboard disappears instantly without the usual slide-down animation.
Expected result:
Keyboard should animate smoothly downwards when dismissed.
Actual result:
Keyboard instantly vanishes without animation.
p.s. we should be really able to upload videos here for demostration
When building with the iOS 26 SDK (currently beta 4), the navigation title is often illegible when rendering a Map view.
For example, note how the title "Choose Location" is obscured by the map's text ("South America") in the screenshot below:
This screenshot is the result of the following view code:
import MapKit
import SwiftUI
struct Demo: View {
var body: some View {
NavigationStack {
Map()
.navigationTitle(Text("Choose Location"))
.navigationBarTitleDisplayMode(.inline)
}
}
}
I tried using the scrollEdgeEffectStyle(_:for:) modifier to apply a scroll edge effect to the top of the screen, in hopes of making the title legible, but that doesn't seem to have any effect. Specifically, the following code seems to produce the exact same result shown in the screenshot above.
import MapKit
import SwiftUI
struct Demo: View {
var body: some View {
NavigationStack {
Map()
.scrollEdgeEffectStyle(.hard, for: .top) // ⬅️ no apparent effect
.navigationTitle(Text("Choose Location"))
.navigationBarTitleDisplayMode(.inline)
}
}
}
Is there a recommended way to resolve this issue so that the navigation title is always readable?
Hello!
I have experienced a weird bug in iOS 26 Beta (8) and previous beta versions. The safe area inset is not correctly aligned with the keyboard toolbar on real devices and simulators.
When you focus a new textfield the bottom safe area is correctly placed aligned the keyboard toolbar.
On real devices the safe area inset view is covered slightly by the keyboard toolbar, which is even worse than on the simulator.
Here's a clip from a simulator:
Here's the code that reproduced the bug I experienced in our app.
#Preview {
NavigationStack {
ScrollView {
TextField("", text: .constant(""))
.padding()
.background(Color.secondary)
TextField("", text: .constant(""))
.padding()
.background(Color.green)
}
.padding()
.safeAreaInset(edge: .bottom, content: {
Color.red
.frame(maxWidth: .infinity)
.frame(height: 40)
})
.toolbar {
ToolbarItem(placement: .keyboard) {
Button {} label: {
Text("test")
}
}
}
}
}
I have a custom list and I want to make the names in the list editable through double tap. I know how to solve this hacky ways.
But are there no solid way to achieve this? like having .disabled without graying it out?
Topic:
UI Frameworks
SubTopic:
SwiftUI
When building with iOS 26 SDK beta 5 (23A5308f), onTapGesture is no longer being triggered on Map views. This appears to be a regression in beta 5 specifically, as this issue was not present in beta 4.
How to reproduce
Code
The following code demonstrates the issue, as seen in the videos below.
import MapKit
import SwiftUI
struct ContentView: View {
@State private var location = CGPoint.zero
var body: some View {
Map()
.onTapGesture { location in
self.location = location
}
.safeAreaInset(edge: .bottom) {
VStack(alignment: .center) {
Text("iOS \(UIDevice.current.systemVersion)")
.font(.largeTitle)
Text("Tapped Location")
Text("\(location.x), \(location.y)")
}
.frame(maxWidth: .infinity, alignment: .center)
.background(.background)
}
}
}
Demo
The gifs below show the behavior in iOS 18.5 (in which the tap gestures are recognized and tapped coordinate is displayed in the safe area inset) and iOS 26 beta 5 (in which the tap gestures have no effect):
iOS 18
iOS 26
Next steps?
Is there a recommended workaround for this issue?
On iPhone, I would like to have a more button at the top right of the navigation bar, a search field in the bottom toolbar, and a plus button to the right of the search field. I've achieved this via the code below.
But on iPad they should be in the navigation bar at the trailing edge from left to right: plus, more, search field. Just like the Shortcuts app, if there's not enough horizontal space, the search field should collapse into a button, and with even smaller space the search bar should become full-width under the navigation bar.
Right now on iPad the search bar is full width under the navigation bar, more at top right, plus at bottom middle, no matter how big the window is.
How can I achieve that? Any way to specify them for the system to more automatically do the right thing, or would I need to check specifically for iPhone vs iPad UIDevice to change the code?
struct ContentView: View {
@State private var searchText = ""
var body: some View {
NavigationStack {
VStack {
Text("Hello, world!")
}
.navigationTitle("Test App")
.searchable(text: $searchText)
.toolbar {
ToolbarItem {
Menu {
//...
} label: {
Label("More", systemImage: "ellipsis")
}
}
DefaultToolbarItem(kind: .search, placement: .bottomBar)
ToolbarSpacer(.fixed, placement: .bottomBar)
ToolbarItem(placement: .bottomBar) {
Button {
print("Add tapped")
} label: {
Label("Add", systemImage: "plus")
}
}
}
}
}
}
Hi,
In the WWDC25 session Elevate an app with Swift concurrency (timestamps: 8:04 and later), the StickerViewModel is shown annotated with @Observable but not @MainActor. The narration mentions that updates happen on the main thread, but that guarantee is left implicit in the calling code.
In Swift 6, though, one of the major benefits is stronger compiler enforcement against data races and isolation rules. If a view model were also annotated with @MainActor, then the compiler could enforce that observable state is only updated on the main actor, preventing accidental background mutations or updates that can cause data races between nonisolated and main actor-isolated uses.
Since @Observable already signals that state changes are intended to be observed (and in practice, usually by views), it seems natural that such types should also be main-actor isolated. Otherwise, we’re left with an implicit expectation that updates will always come from the main thread, but without the compiler’s help in enforcing that rule.
This also ties into the concept of local reasoning that was emphasized in other Swift 6 talks (e.g. Beyond the basics of structured concurrency). With @MainActor, I can look at a view model and immediately know that all of its state is main-actor isolated. With only @Observable, that guarantee is left out, which feels like it weakens the clarity that Swift 6 is trying to promote.
Would it be considered a best practice in Swift 6 to use both @Observable and @MainActor for UI-facing view models? Or is the intention that SwiftUI developers should rely on calling context to ensure main-thread updates, even if that means the compiler cannot enforce isolation?
Thanks!
I really enjoyed using SwiftData for persistence until I found out that the CloudKit integration ensures changes are only eventually consistent, and that changes can propagate to other devices after as long as minutes, making it useless for any feature that involves handoff between devices. Devastating news but I guess it’s on me for nrtfm. I may try my hand at a custom model context DataStore integrating Powersync, but that’s a whole trip and before I embark on it I was wondering if anyone had suggestions for resolving this problem in a simple and elegant manager that allows me to keep as much of the machinery within Apple’s ecosystem as possible, while ensure reliable “live” updates to SwiftData stores on all eligible devices.
I've been exploring the resources from WWDC25 Session 280: "Code-along: Cook up a rich text experience in SwiftUI with AttributedString" and the SwiftUI documentation on "Building rich SwiftUI text experiences." After spending some time experimenting and trying to implement these features with these APIs on iOS26 , I’ve run into a specific question.
Is there a way to programmatically trigger the Format Sheet directly—for example, from a custom button—rather than requiring the user to go through the multi-step process of selecting text, opening the context menu, tapping "Format," and then selecting "More"?
I’d like to provide a more streamlined editing experience in my app. Any guidance would be greatly appreciated!
In my SwiftUI iOS app, I need to detect which key (and modifier flags – Command, Option, Shift, Control) a user presses, but I don't want to pre-register them using .keyboardShortcut(_:modifiers:).
My use case is that keyboard shortcuts are user-configurable, so I need to capture the actual key + modifier combination dynamically at runtime and perform the appropriate action based on the user’s settings.
Questions:
What is the recommended way to detect arbitrary key + modifier combinations in SwiftUI on iOS?
Is there a SwiftUI-native solution for this, or should I rely on UIPressesEvent and wrap it with UIViewControllerRepresentable?
If UIKit bridging is necessary, what is the cleanest pattern for integrating this with SwiftUI views (e.g., Buttons)?
Any official guidance or best practices would be greatly appreciated!
I'm writing an iOS app that shares content with buddies. So my app will run in one language but the shared content will use the locale configured for the buddy.
I found this Apple documentation which suggests that locale: (Locale(identifier: is the solution.
Apple Documentation
But I can't get it to work.
Here's sample code.
struct LocalizationDemoView: View {
@State var isEnglish = true
var body: some View {
var myLocale: String { isEnglish ? "en": "de" }
VStack {
Toggle("Switch language", isOn: $isEnglish).frame(maxWidth: 200)
HStack {
Text("\(myLocale): ")
Text(String(localized: "Hello world!", locale: (Locale(identifier: myLocale)), comment: "To share"))
}
}
}
}
And here's the excerpt from the string catalog:
{
"sourceLanguage" : "en",
"strings" : {
"Hello world!" : {
"comment" : "To share",
"localizations" : {
"de" : {
"stringUnit" : {
"state" : "translated",
"value" : "🇩🇪 Moin Welt!"
}
},
"en" : {
"stringUnit" : {
"state" : "translated",
"value" : "🇬🇧 Hello world!"
}
}
}
}
}
}
Has Apple reduced support for string catalogs or is my code wrong?
Xcode 16.4 compiled on MacOS 15.6.1, device iOS 18.6.2
For a number of complex views in my app, I need to embed scrollable objects (like List, Form or TextEditor) in a ScrollView. To do that, I need to apply a limit to the height of the embedded object.
What I would like to do is set that limit to the actual height of the content being displayed in the List, Form, TextEditor, etc. (Note that this height calculation should be dynamic, so that content changes are properly displayed.
I attempted the following:
@State listHeight: CGFloat = .zero
List {
... content here
}
.onScrollGeometryChange(for: CGFloat.self, of: { geometry in
return geometry.contentSize.height
}, action: { oldValue, newValue in
if oldValue != newValue {
listHeight = newValue
}
})
.frame(height: listHeight)
.scrollDisabled(true)
This does not work because geometry.contentSize.height is always 0. So it is apparent that .onScrollGeometryChangedoes not interact with the internal scrolling mechanism of List. (Note, however, that.scrollDisabled` does work.)
Does anyone have a suggestion on how I might get this to work?
In SwiftUI for macOS, when implementing a DragGesture inside a ScrollVIew, how can I implement auto-scrolling when the mouse is not actively moving?
In AppKit, this would normally be done with a periodic event so that auto-scrolling continues to take place even if the user isn't actively moving the mouse. This is essential behaviour when implementing something like a drag-to-select gesture.
NSView.autoscroll(with: NSEvent) -> Bool
Is there anything in SwiftUI or ScrollView to accomplish this behaviour?
If you create a NavigationSplitView, then the sidebar is automatically adorned with a sidebar material effect. This affects the views background as well as any controls that are in the view.
What is the correct way to disable this behaviour so that I can use a NavigationSplitView without the material effects being applied?
The best I've come up with so far is to explicitly set the background on the sidebar but I'm curious if that's the correct way or I'm just getting lucky.
struct ContentView: View {
var body: some View {
NavigationSplitView {
// This works, but is it correct?
SidebarView()
.background(.windowBackground)
} detail: {
DetailView()
}
}
}
Hello,
It's impossible to manage hit area for textfield and it's already too small by default (detected with Accessibility Inspector).
I'm tried to force with modifier "frame(minHeight: xxx)", the component change the height but the hit area is still in same size.
Have to tips to fix this issue?
Is it possible to add an ornament below a tab bar like this? Or does the whole side bar have to be an ornament to build this?
What is the correct way to track the number of items in a relationship using SwiftData and SwiftUI?
Imagine a macOS application with a sidebar that lists Folders and Tags. An Item can belong to a Folder and have many Tags. In the sidebar, I want to show the name of the Folder or Tag along with the number of Items in it.
I feel like I'm missing something obvious within SwiftData to wire this up such that my SwiftUI views correctly updated whenever the underlying modelContext is updated.
// The basic schema
@Model final class Item {
var name = "Untitled Item"
var folder: Folder? = nil
var tags: [Tag] = []
}
@Model final class Folder {
var name = "Untitled Folder"
var items: [Item] = []
}
@Model final class Tag {
var name = "Untitled Tag"
var items: [Item] = []
}
// A SwiftUI view to show a Folder.
struct FolderRowView: View {
let folder: Folder
// Should I use an @Query here??
// @Query var items: [Item]
var body: some View {
HStack {
Text(folder.name)
Spacer()
Text(folder.items.count.formatted())
}
}
}
The above code works, once, but if I then add a new Item to that Folder, then this SwiftUI view does not update. I can make it work if I use an @Query with an #Predicate but even then I'm not quite sure how the #Predicate is supposed to be written. (And it seems excessive to have an @Query on every single row, given how many there could be.)
struct FolderView: View {
@Query private var items: [Item]
private var folder: Folder
init(folder: Folder) {
self.folder = folder
// I've read online that this needs to be captured outside the Predicate?
let identifier = folder.persistentModelID
_items = Query(filter: #Predicate { link in
// Is this syntax correct? The results seem inconsistent in my app...
if let folder = link.folder {
return folder.persistentModelID == identifier
} else {
return false
}
})
}
var body: some View {
HStack {
Text(folder.name)
Spacer()
// This mostly works.
Text(links.count.formatted())
}
}
}
As I try to integrate SwiftData and SwiftUI into a traditional macOS app with a sidebar, content view and inspector I'm finding it challenging to understand how to wire everything up.
In this particular example, tracking the count, is there a "correct" way to handle this?
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
When performing custom layout in AppKit, it's essential that you pixel align frames using methods like backingAlignedRect. The alignment differs depending on the backingScaleFactor of the parent window.
When building custom Layouts in SwiftUI, how should you compute the alignment of a subview.frame in placeSubviews() before calling subview.place(...)?
Surprisingly, I haven't seen any mention of this in the WWDC videos. However, if I create a Rectangle of width 1px and then position it on fractional coordinates, I get a blurry view, as I would expect.
Rounding to whole numbers works, but on Retina screens you should be able to round to 0.5 as well.
func placeSubviews(
in bounds: CGRect,
proposal: ProposedViewSize,
subviews: Subviews,
cache: inout Void
) {
// This should be backing aligned based on the parent window's backing scale factor.
var frame = CGRect(
x: 10.3,
y: 10.8,
width: 300.6,
height: 300.1
)
subview.place(
at: frame.origin,
anchor: .topLeading,
proposal: ProposedViewSize(frame.size)
)
}