“swiftui”

I have been pleased to see SwiftUI’s List performance improve over the years. However, when using a List that contains DisclosureGroup views, expanding and collapsing items becomes significantly slower as the amount of data grows. In my case, I need to control the initial expanded/collapsed state of each disclosure item, so I cannot use the recursive List(_:children:) API. Is there a recommended way to improve the performance of a List containing DisclosureGroup views, or is falling back to AppKit’s NSOutlineView currently the only practical solution? (Yes, for context, my app is for macOS.) The following code shows the relevant portion of my implementation: List(self.summary.files, selection: $selection) { file in DisclosureGroup(isExpanded: $expandedFileURLs.contains(file.id)) { ForEach(file.matches) { match in FolderFindMatchView(match: match) .tag(FolderFind.ResultID.match(fileID: file.id, matchID: match.id)) } } label: { FolderFindFileResultView(file: file) .draggable(item: FolderFindDraggedFile

If I want to implement the view style pattern that various SwiftUI components have (like ButtonStyle for Button and PickerStyle for Picker, to name a few) for my own custom components, is there any guidance on how to do that? Specifically, is there a way to do that without having to resort to using AnyView? My attempts to implement this have been fine with retaining type information using some View and generics, up until the point I need to create an interface for specifying a view style to use and propagating that down to the component that I'm styling. Using the SwiftUI environment seems like the natural way to do this propagation, but I seem to run afoul of the type system when trying to use it. If we take ButtonStyle from SwiftUI as an example of the general structure of this pattern, we're talking about having a protocol with an associated Body type, and a corresponding makeBody function that does the actual styling of the component and returns a Body instance. Because of the a

I am encountering a systemic issue on macOS where NSViewRepresentable (and some native container views like Table) completely discard explicit SwiftUI animations when the state change is handled via an .onChange modifier. While the exact same reactive architecture produces fluid animations on iOS, the AppKit bridge on macOS snaps the frame updates instantly. I have filed a formal bug report for this behavior, but I want to open this up to the community to see if anyone has found a cleaner architectural workaround. The Problem When observing a state change (e.g., via @AppStorage, @SceneStorage, or local state) using .onChange, applying a withAnimation block fails to animate the underlying layer changes in an AppKit representable view. // The Reactive Pattern that breaks on macOS .onChange(of: toggle) { newValue in withAnimation(.easeInOut(duration: 0.5)) { self.targetColor = newValue ? .systemBlue : .systemRed } } The Diagnostic Anomaly If you inspect context.transaction inside the updateNSView(_:cont

We've been getting stack overflows in code we don't control, in the background AsyncRenderer thread in a chain of calls to updateInheritedViewAsync. But the stack is less than 200 calls deep, presumably because it's a background thread with a smaller stack limit. Is it possible to adjust AsyncRenderer's stack limit? Or otherwise, what limits should we be aware of to prevent running into this issue? com.apple.SwiftUI.AsyncRenderer: EXC_BAD_ACCESS (code=2, address=0x16f5ebe30) #0 0x000000019c6b4460 in function signature specialization of static SwiftUI.DisplayList.ViewUpdater.Model.merge(item: inout SwiftUI.DisplayList.Item, index: SwiftUI.DisplayList.Index, into: inout SwiftUI.DisplayList.ViewUpdater.Model.State) -> SwiftUI.DisplayList.ViewUpdater.Model.MergedViewRequirements () #1 0x000000019c7c2850 in SwiftUI.DisplayList.ViewUpdater.updateInheritedViewAsync(platform: SwiftUI.DisplayList.ViewUpdater.Platform, oldItem: SwiftUI.DisplayList.Item, oldParentState: Swift.UnsafePointer, newItem: SwiftUI.DisplayL

Hi! I’m struggling a bit with data flows in SwiftUI. Most SwiftUI sample apps I’ve seen use one large app model / store and inject that into the environment. That works for small samples, but I’m not sure how this should scale in a real app where the data is naturally split into multiple models/services. For example, I may have separate types for things like: @Observable final class AuthModel { ... } @Observable final class MediaSourcesModel { ... } @Observable final class UsersModel { ... } final class HTTPClient { ... } Some of these only make sense once the user is logged in. For example, media sources, user data, and the HTTP client may all depend on the current user/session/token. What I’m struggling with is where these objects should be owned and created in a SwiftUI app. I’m trying to avoid creating them directly inside a view body, because that can recreate them as the view updates. I’m also unsure whether putting this setup in custom view initializers is the right direction

Good morning! Our app is currently a mix of UIKit and SwiftUI. All new code is SwiftUI and we’re gradually replacing old code but for now we have SwiftUI views in UIHostingControllers where needed. Our app is a dark color scheme regardless of the device light/dark setting. One issue we’ve have is that some view in the hierarchy of the UIHostingController seems to have a white background. This is not normally visible, but when sliding views on and off in navigation, there’s a hint of white showing at the edge of the view as it moves. It’s subtle but users have noticed. I thought I filed this bug some time ago but I can’t find it. Just wondering if you’re aware and if there’s any update.

Previously, the Mac version of my app was built with Mac Catalyst. However, because using the menu bar was inconvenient, I started migrating the Mac version to a native Mac build. Later, I found that starting around macOS 26.4.1, the menu bar that used to appear with my original SwiftUI implementation suddenly stopped showing. As a result, I had to switch back and use an AppKit bridge instead. In addition, I noticed that many visual elements look very strange when built with Mac Catalyst, so I have to adjust each page one by one. I would like to know whether there is a guide for migrating from Mac Catalyst to native Mac, especially regarding style adaptation, so that I can follow the guide and make the necessary changes systematically. Finally, since one of SwiftUI’s advantages is multi-platform deployment, why can’t these styling issues be adapted automatically?

Good morning! Not sure this is strictly a SwiftUI question but it is a UI question. The biggest problems we’ve had in adopting the updated UI in recent releases center around the tab bar. We’re an iOS/iPadOS app with a tabbed UI. Having the tab bar arbitrarily jump from the bottom of the screen to the top at a certain size makes laying out our UI very difficult. We’ve worked around this so far by using a custom bar, but that’s clunky and doesn’t work well with Liquid Glass. Are there any changes to this behavior in the 27 releases given the even greater emphasis on resizability?

Is this the right way to pass data to a sheet for editing? struct Detail: View { ... // The single atomic source of truth for our sheet presentation @State var editorConfig: EditorConfig? // Completely encapsulated local configuration package struct EditorConfig: Identifiable { var id: PersistentIdentifier { item.persistentModelID } let context: ModelContext let item: Item } var body: some View { ... Button(Edit) { // 1. Spin up a separate scratchpad container layer let context = ModelContext(modelContext.container) context.autosaveEnabled = false // 2. Safely resolve our model inside the new isolated playground if let sandboxItem = context.model(for: item.persistentModelID) as? Item { // 3. Package it up to trigger the sheet presentation editorConfig = EditorConfig(context: context, item: sandboxItem) } } } } // 4. SwiftUI tracks value replacement accurately without ghost state bugs .sheet(item: $editorConfig) { config in // Inject the isolated context into the sheet's environment chain EditorView(i

In the SwiftUI group lab, an engineer mentioned that there were new ways to customize SwiftUI screen transitions. They mentioned there is a crossfade, which I see in the docs, but they also mentioned other customizations. Did they misspeak, or are there custom screen transitions? I'd love a modern, SwiftUI replacement for custom presentation controllers from UIKit!

I'm wondering what the easiest way to reordering a view in a stack is whilst maintaining structural identity, so that it animates/transitions correctly + state is maintained. Ideally if in a LazyVStack it would maintain the laziness too. Think of a stack where if a normal ForEach was used the view may end up being a switch over up to 20 different types of views. I know custom Layouts can be used but they currently cannot be lazy and it seems like a fair bit of work for something that seems fairly simple. Can the below approach be optimised? import SwiftUI struct GroupDemoView: View { @State private var animatesChanges = false @State private var shouldReorder = false private let reorderAnimation = Animation.spring(duration: 3, bounce: 0.5) var body: some View { VStack(spacing: 28) { VStack(spacing: 12) { Toggle(Animate changes, isOn: $animatesChanges) Toggle(Reorder subviews, isOn: animatesChanges ? $shouldReorder.animation(reorderAnimation) : $shouldReorder) } .frame(maxWidth: 240) ScrollView { Reord

For apps still using UIKit view controllers presented over a SwiftUI hierarchy (or vice versa), what's the recommended approach in iOS 27 for finding the correct presenting context across the new window scene configurations, especially with resizable windows? — Divya Ravi, Senior iOS Engineer

I've been adopting SwiftUI into a legacy UIKit app. Individual views work great, but when I try to intermix SwiftUI and UIKit navigation things go bad fast. What is the best practice here?