“swiftui”

Hmm, this sounds like something at a data level, which may not be the responsibility of the ForEach. What does your model look like? Traditionally, you could do this with a .reduce on a standard Swift collection, and pass the result into SwiftUI's ForEach. Though I'm not quite sure I understand your question fully. Could you elaborate or show a code example? Thanks :)

The concurrency requirement for a framework like SwiftUI is different than an application. SwiftUI's API has to be compatible with a vast amount of use cases, including apps building in Swift 5 mode, apps using older SDKs where compiler diagnostic with regard to concurrency behaves differently, etc. Nonisolated inits is necessary to maintain source compatibility with all these edge use cases. Unless you are working on a framework that needs to be source/ABI compatible with older compilers, an unknown number of concurrency setting combinations, etc (in which case, bravo!), you really shouldn't have the burden of maintaining nonisolated initializers. It's a little surprising that you need to dependency inject a view. Usually dependency injection deals with data flow. I'd consider using other method to perhaps modularize your view code. For example, if your view isn't changing frequently, you can remove dependencies between views using AnyView.

We've made improvements specifically for the performance of DisclosureGroup inside of List in macOS 27.0. Wow! That’s great to hear! Thank you for making those improvements. Lists and tables are still areas where SwiftUI can be challenging to use on macOS, so I always look forward to the performance improvements and API refinements that arrive each year. In that case, my scenario may provide a useful test case. I’ll put together a detailed report and submit it through Feedback Assistant.

This is a perfectly good pattern to have your sheet set to the custom detent of the height of the view it contains. This can get tricky with ScrollViews in sheets in which case you need to measure the size of the view inside the ScrollView since the ScrollView itself doesn't have a preferred size when it's height proposal is nil. For slightly better performance you can use on geometry change instead: import SwiftUI @main struct MyApp: App { var body: some Scene { WindowGroup { ContentView() } } } struct ContentView: View { @State private var showingSheet = false @State private var swatchHeight: CGFloat = 100 @State private var measuredSheetHeight: CGFloat = 100 @State private var selectedDetent: PresentationDetent = .height(100) var body: some View { Button(Show Sheet) { showingSheet = true } .sheet(isPresented: $showingSheet) { AutoSizingSheet( swatchHeight: $swatchHeight, measuredSheetHeight: $measuredSheetHeight, selectedDetent: $selectedDetent ) } } } private struct AutoSizingSheet: View { @Bindi

The performance considerations really depend on your specific use case, especially if the views you're asking ViewThatFits to choose between are complex, since you're effectively initializing and measuring each candidate view and all of its children, and this happens on every layout pass. For resizability, the best way to react to changes in size is by tracking size class changes for overall window size, or onGeometryChange for tracking the size of individual views. The nice thing about this is that it gives you more control over the thresholds at which the decision of which view to display happens. Instead of making a conditional view decision on every frame of a resize action, you could try defining break points for your layout. For instance, you might code up some logic where when the parent view's width moves between certain ranges, you set a state variable that specifies which view to show. onGeometryChange's action closure only fires when the value returned by its transform closure changes, so this allo

You don't have to transform the data if you know the selected item is being selected again. SwiftUI must support all use cases, and some use cases demand that the binding gets called over and over again!

Great question! In SwiftUI, we have made it as easy as possible to use it in the Swift 6 language mode. You should not need to define your custom Views initializers as nonisolated, because the expectation is that they will be initialized from the parent view's isolation context, and View protocol is @MainActor in SwiftUI. This means that there is really no reason for your view to be initialized from a nonisolated context, since the context will be main-actor-isolated anyway. Great observation that SwiftUI's own custom Views have their initializer marked as nonisolated. This is a pattern that lets us have more flexibility internally in the framework, but in terms of API, we rely on the fact that these views will be automatically isolated to the @MainActor when used in View.body. While this is a pattern we use internally, it is not needed to replicate for your own custom components. I hope this answers your question! If not, we'd love to see the sample code where it is tricky to avoid

In iOS 27, iPhone apps can now be resized for iPhone Mirroring, or when running on an iPad. SwiftUI makes it really easy to support resizability by leveraging size classes and more, and you can learn more about resizability from What’s New in SwiftUI. We encourage you to reconsider the requirement and design the app for all Apple devices, meeting customers where they are.

Hello @ADietz, Thank you for contributing to the Developer Forums This Q&A is about SwiftUI, if you have a question about SwiftUI, we have engineers available to answer your questions! For testing questions, please create a separate post in the Forums and it will receive better proper attention there!  Travis