At WWDC25 we launched a new type of Lab event for the developer community - Group Labs. A Group Lab is a panel Q&A designed for a large audience of developers. Group Labs are a unique opportunity for the community to submit questions directly to a panel of Apple engineers and designers. Here are the highlights from the WWDC25 Group Lab for SwiftUI. What's your favorite new feature introduced to SwiftUI this year? The new rich text editor, a collaborative effort across multiple Apple teams. The safe area bar, simplifying the management of scroll view insets, safe areas, and overlays. NavigationLink indicator visibility control, a highly requested feature now available and back-deployed. Performance improvements to existing components (lists, scroll views, etc.) that come "for free" without requiring API adoption. Regarding performance profiling, it's recommended to use the new SwiftUI Instruments tool when you have a good understanding of your code and notice a performance drop after a specific change. This helps build a mental map between your code and the profiler's output. The "cause-and-effect graph" in the tool is particularly useful for identifying what's triggering expensive view updates, even if the issue isn't immediately apparent in your own code. My app is primarily UIKit-based, but I'm interested in adopting some newer SwiftUI-only scene types like MenuBarExtra or using SwiftUI-exclusive features. Is there a better way to bridge these worlds now? Yes, "scene bridging" makes it possible to use SwiftUI scenes from UIKit or AppKit lifecycle apps. This allows you to display purely SwiftUI scenes from your existing UIKit/AppKit code. Furthermore, you can use SwiftUI scene-specific modifiers to affect those scenes. Scene bridging is a great way to introduce SwiftUI into your apps. This also allows UIKit apps brought to Vision OS to integrate volumes and immersive spaces. It's also a great way to customize your experience with Assistive Access API. Can you please share any bad practices we should avoid when integrating Liquid Glass in our SwiftUI Apps? Avoid these common mistakes when integrating liquid glass: Overlapping Glass: Don't overlap liquid glass elements, as this can create visual artifacts. Scrolling Content Collisions: Be cautious when using liquid glass within scrolling content to prevent collisions with toolbar and navigation bar glass. Unnecessary Tinting: Resist the urge to tint the glass for branding or other purposes. Liquid glass should primarily be used to draw attention and convey meaning. Improper Grouping: Use the GlassEffectContainer to group related glass elements. This helps the system optimize rendering by limiting the search area for glass interactions. Navigation Bar Tinting: Avoid tinting navigation bars for branding, as this conflicts with the liquid glass effect. Instead, move branding colors into the content of the scroll view. This allows the color to be visible behind the glass at the top of the view, but it moves out of the way as the user scrolls, allowing the controls to revert to their standard monochrome style for better readability. Thanks for improving the performance of SwiftUI List this year. How about LazyVStack in ScrollView? Does it now also reuse the views inside the stack? Are there any best practices for improving the performance when using LazyVStack with large number of items? SwiftUI has improved scroll performance, including idle prefetching. When using LazyVStack with a large number of items, ensure your ForEach returns a static number of views. If you're returning multiple views within the ForEach, wrap them in a VStack to signal to SwiftUI that it's a single row, allowing for optimizations. Reuse is handled as an implementation detail within SwiftUI. Use the performance instrument to identify expensive views and determine how to optimize your app. If you encounter performance issues or hitches in scrolling, use the new SwiftUI Instruments tool to diagnose the problem. Implementing the new iOS 26 tab bar seems to have very low contrast when darker content is underneath, is there anything we should be doing to increase the contrast for tab bars? The new design is still in beta. If you're experiencing low contrast issues, especially with darker content underneath, please file feedback. It's generally not recommended to modify standard system components. As all apps on the platform are adopting liquid glass, feedback is crucial for tuning the experience based on a wider range of apps. Early feedback, especially regarding contrast and accessibility, is valuable for improving the system for all users. If I’m starting a new multi-platform app (iOS/iPadOS/macOS) that will heavily depend on UIKit/AppKit for the core structure and components (split, collection, table, and outline views), should I still use SwiftUI to manage the app lifecycle? Why? Even if your new multi-platform app heavily relies on UIKit/AppKit for core structure and components, it's generally recommended to still use SwiftUI to manage the app lifecycle. This sets you up for easier integration of SwiftUI components in the future and allows you to quickly adopt new SwiftUI features. Interoperability between SwiftUI and UIKit/AppKit is a core principle, with APIs to facilitate going back and forth between the two frameworks. Scene bridging allows you to bring existing SwiftUI scenes into apps that use a UIKit lifecycle, or vice versa. Think of it not as a binary choice, but as a mix of whatever you need. I’d love to know more about the matchedTransitionSource API you’ve added - is it a native way to have elements morph from a VStack to a sheet for example? What is the use case for it? The matchedTransitionSource API helps connect different views during transitions, such as when presenting popovers or other presentations from toolbar items. It's a way to link the user interaction to the presented content. For example, it can be used to visually connect an element in a VStack to a sheet. It can also be used to create a zoom effect where an element appears to enlarge, and these transitions are fully interactive, allowing users to swipe. It creates a nice, polished experience for the user. Support for this API has been added to toolbar items this year, and it was already available for standard views.

To whom it may concern that deals with bugs in SwiftUI for iOS 26: Inadvertently discovered a bug which duplicates ToolbarItem in any placement in the toolbar when navigationBarBackButtonHidden is set to true. .toolbar{ ToolbarItem(placement: .confirmationAction) { Button("Stop", systemImage: "stop.fill"){ //some action } } } .navigationBarBackButtonHidden(true) Expected Behavior Show the ToolbarItem Actual Behavior Duplicates items in the placement position. Thank you.

[Also submitted as FB21536505] When presenting a NavigationStack inside a .sheet, applying .tint(Color) does not affect the system back button on pushed destinations. The sheet’s close button adopts the tint, but the back chevron remains the default system color. REPRO Create a new iOS project and replace ContentView.swift with the code below. —or— Present a .sheet containing a NavigationStack. Apply .tint(.red) to the NavigationStack or sheet content. Push a destination using NavigationLink. EXPECTED The back button chevron adopts the provided tint color, consistent with other toolbar buttons and UIKit navigation behavior. ACTUAL The back button chevron remains the default system color. NOTES Reproduces consistently on: iOS 26.2 (23C54) iOS 26.3 (23D5089e) SCREEN RECORDING SAMPLE CODE import SwiftUI struct ContentView: View { @State private var isSheetPresented = false var body: some View { Button("Open Settings Sheet") { isSheetPresented = true } .sheet(isPresented: $isSheetPresented) { NavigationStack { List { NavigationLink("Push Detail") { DetailView() } } .navigationTitle("Settings") .navigationBarTitleDisplayMode(.inline) .toolbar { ToolbarItem(placement: .automatic) { Button("Close", systemImage: "xmark") { isSheetPresented = false } } } } .tint(.red) } } } private struct DetailView: View { var body: some View { List { Text("Detail View") } .navigationTitle("Detail") .navigationBarTitleDisplayMode(.inline) } }

The zoom navigation transition with matchedTransitionSource in tabViewBottomAccessory does not work when a Published var in an ObservableObjector Observable gets changed. Here is an minimal reproducible example with ObservableObject: import SwiftUI import Combine private final class ViewModel: ObservableObject { @Published var isPresented = false } struct ContentView: View { @Namespace private var namespace @StateObject private var viewModel = ViewModel() // @State private var isPresented = false var body: some View { TabView { Button { viewModel.isPresented = true } label: { Text("Start") } .tabItem { Image(systemName: "house") Text("Home") } Text("Search") .tabItem { Image(systemName: "magnifyingglass") Text("Search") } Text("Profile") .tabItem { Image(systemName: "person") Text("Profile") } } .sheet(isPresented: $viewModel.isPresented) { Text("Sheet") .presentationDragIndicator(.visible) .navigationTransition(.zoom(sourceID: "tabViewBottomAccessoryTransition", in: namespace)) } .tabViewBottomAccessory { Button { viewModel.isPresented = true } label: { Text("BottomAccessory") } .matchedTransitionSource(id: "tabViewBottomAccessoryTransition", in: namespace) } } } However, when using only a State property everything works: import SwiftUI import Combine private final class ViewModel: ObservableObject { @Published var isPresented = false } struct ContentView: View { @Namespace private var namespace // @StateObject private var viewModel = ViewModel() @State private var isPresented = false var body: some View { TabView { Button { isPresented = true } label: { Text("Start") } .tabItem { Image(systemName: "house") Text("Home") } Text("Search") .tabItem { Image(systemName: "magnifyingglass") Text("Search") } Text("Profile") .tabItem { Image(systemName: "person") Text("Profile") } } .sheet(isPresented: $isPresented) { Text("Sheet") .presentationDragIndicator(.visible) .navigationTransition(.zoom(sourceID: "tabViewBottomAccessoryTransition", in: namespace)) } .tabViewBottomAccessory { Button { isPresented = true } label: { Text("BottomAccessory") } .matchedTransitionSource(id: "tabViewBottomAccessoryTransition", in: namespace) } } }

In the new iOS 26 design, the navigation bar and tab bar will have a dark gradient background. We found that the color of this gradient depends on the background color of the page. For example, in the following page, our background color is green, so the navigation bar and tab bar will change the gradient to green. Is there any way to change this gradient color? I tried .toolbarBackground(.hidden, for: .navigationBar), but does not work。 I tried .toolbarBackground(LinearGradient(colors: [.black.opacity(0.4), .black.opacity(0)], startPoint: .top, endPoint: .bottom), for: .navigationBar), but it looks like the default gradient is the superposition of the gradient I defined, not a replacement.

Let me ask the general question first, then explain the context... Each Tab of a TabView defines a separate View hierarchy. (I'm assuming that the root view of each Tab defines its own NavigationStack.) Since an @Environment is supposed to serve data to the child views in its view hierarchy, does this mean that it is possible to define Environments in each tab's root view with the same name (i.e. key) but different values? (I.e., I want a subview to access an environment value for the current view hierarchy without requiring that the subview have any knowledge of which hierarchy it is being called from.) The actual use case has to do with using @Environment in a tabbed application to inject a router in subviews. (Each Tab has its own NavigationStack and its own NavigationPath.) I have an @Observable router class which manages a NavigationPath.. The root view of each Tab in the application has its own instance of that router object (and hence, it's own NavigationPath). I want to inject that router into all of the subviews in each Tab's view hierarchy, so that I can use path-based navigation. My current implementation injects the router throughout the view hierarchies via constructor injection. This works, but is a real pain and includes a bunch of duplicate code. I would like to use @Environment injection instead, but this can only work if @Environment stores its EnvironmentValues on a per view-hierarchy (rather than a per-application) basis. So, can this approach work? what experience can you share concerting router-based navigation in a TabView-based app? Thanks.

Anytime I launch a view that contains a textfield, as soon as it’s in focus the view dismisses, and I log this warning, I have tried everything I could think of and still no solution, anyone know a workaround to this? note: this happens both on simulator and physical devices -[rtiinputsystemclient remotetextinputsessionwithid:performinputoperation:] perform input operation requires a valid sessionid. input modality = keyboard, input operation = , custom infotype = uiemojisearchoperations

The following code segments run when building and running the app, or after going home and re-opening the app, but now when quitting the app and re-opening it again. What code can do that? init() { print("test") } .onAppear { print("test) } .onChange(of: scenePhase) { _, newValue in print(newValue) }

Overview I have a custom type Statistics that has 3 properties inside it I am trying to return this as part of the AppIntent's perforrm method struct Statistics { var countA: Int var countB: Int var countC: Int } I would like to implement the AppIntent to return Statistics as follows: func perform() async throws -> some IntentResult & ReturnsValue<Statistics> { ... ... } Problem It doesn't make much sense to make Statistics as an AppEntity as this is only computed as a result. Statistics doesn't exist as a persisted entity in the app. Questions How can I implement Statistics? Does it have to be AppEntity (I am trying to avoid this)? (defaultQuery would never be used.) What is the correct way tackle this?

reality Converter Where is the download link? I can't find it

I built this very simple example to demonstrate the issue im facing on iOS 26 when trying to use custom ToolbarItem element for .largeTitle. Code: struct ContentView: View { var body: some View { NavigationStack { Screen() .navigationTitle("First") .toolbar { ToolbarItem(placement: .largeTitle) { Text("First") .font(.largeTitle) .border(Color.black) } } .navigationDestination(for: Int.self) { integer in DestinationScreen(integer: integer) } } } } struct Screen: View { var body: some View { List { ForEach(1..<50) { index in NavigationLink(value: index) { Text(index.description) .font(.largeTitle) } } } } } struct DestinationScreen: View { let integer: Int var body: some View { HStack { Text(integer.description) .font(.largeTitle) Spacer() } .padding() .navigationTitle(integer.description) .toolbar { ToolbarItem(placement: .largeTitle) { Text(integer.description) .font(.largeTitle) .border(Color.black) } } } } As shown on the gif, when navigating between pages, titles are going to overlap for a short while. Other questions: Why is it required for .navigationTitle() to exist (empty string wouldn't work!) so that the ToolbarItem .largeTitle can render at all? If none is added, this ToolbarItem simply won't appear Why isn't the large title naturally aligning to the leading side? Apple doc. doesn't mention any of this behaviour as far as I know but in general these placement should replicate known established behaviours, and .largeTitle should be leading aligned. Another issue is shown on the image below. When using both .largeTitle and .title (to simulate the same behaviour of transition between large and inline title when scrolling), both will appear at the same time. The large title will disappear as you scroll down which is fine.

SwiftUI's colorScheme modifier is said to be deprecated in favour of preferredColorScheme but the two work differently. See the below sample app, colorScheme changes the underlying view colour while preferredColorScheme doesn't. Is that a bug of preferredColorScheme? import SwiftUI struct ContentView: View { let color = Color(light: .red, dark: .green) var body: some View { VStack { HStack { color.colorScheme(.light) color.colorScheme(.dark) } HStack { color.preferredColorScheme(.light) color.preferredColorScheme(.dark) } } } } #Preview { ContentView() } @main struct TheApp: App { var body: some Scene { WindowGroup { ContentView() } } } extension UIColor { convenience init(light: UIColor, dark: UIColor) { self.init { v in switch v.userInterfaceStyle { case .light: light case .dark: dark case .unspecified: fatalError() @unknown default: fatalError() } } } } extension Color { init(light: Color, dark: Color) { self.init(UIColor(light: UIColor(light), dark: UIColor(dark))) } }

Hey there, Link to the sample project: https://github.com/dev-loic/AppleSampleScrolling Context We are working on creating a feed of posts in SwiftUI. So far, we have successfully implemented a classic feed that opens from the top, with bottom pagination — a standard use case. Our goal, however, is to allow the feed to open from any post, not just the first one. For example, we would like to open the feed directly at the 3rd post and then trigger a network call to load elements both above and below it. Our main focus here is on preserving the scroll position while opening the screen and waiting for the network call to complete. To illustrate the issue, I created a sample project (attached) with two screens: MainView, which contains buttons to open the feed in different states. ScrollingView, which initially shows a single element, simulates a 3-second network call, and then populates with new data depending on which button was tapped. I am currently using Xcode 26 beta 6, but I can also reproduce this issue on Xcode 16.3. Tests on sample project I click on a button and just wait the 3 seconds for the call. In this scenario, I expect that the “focused item” stays at the exact same place on the screen. I also expect to see items below and above being added. Simulator iPhone 16 / iOS 18.4 with itemsHeight = 100 position = 0, 1, 2, 3 ⇒ works as expected position = 4, 5, 6, 7, 8, 9 ⇒ scroll is reset to the top and we loose the focused item Simulator iPhone 16 / iOS 18.4 with itemsHeight = 500 position = 0, 1, 2, 3, 4 ⇒ works as expected position = 5, 6, 7 ⇒ I have a glitch (the focused element moves on the screen) but the focused element is still visible position = 8, 9 ⇒ scroll is reset to the top and we loose the focused item Simulator iPhone 16 / iOS 26 with itemsHeight = 100 or 500 position = 0, 1, 2, 3, 4 ⇒ works as expected position = 5, 6, 7, 8, 9 ⇒ I have a glitch (the focused element moves on the screen) but the focused element is still visible Device iPhone 15 / iOS 26 with itemsHeight = 100 position = 0, 1, 2, 3, 4 ⇒ works as expected position = 5, 6, 7, 8, 9 ⇒ I have a glitch (the focused element moves on the screen) but the focused element is still visible Device iPhone 15 / iOS 26 with itemsHeight = 500 position = 0, 1, 2, 3 ⇒ works as expected position = 4, 5, 6, 7, 8, 9 ⇒ I have a glitch (the focused element moves on the screen) but the focused element is still visible Not any user interaction Moreover, in this scenario, the user does not interact with the screen during the simulated network call. Regardless of the situation, if the ScrollView is in motion, its position always resets to the top. This behavior prevents us from implementing automatic pagination when scrolling upward, which is ultimately our goal. My conclusion so far As far as I know it seems not possible to have both keeping scroll possible and upward automatic pagination using a SwiftUI LazyVStack inside a ScrollView. This appears to be standard behavior in messaging apps or other feed-based apps, and I’m wondering if I might be missing something. Thank you in advance for any guidance you can provide on this topic. Cheers

Hi everyone, I believe this should be a simple and expected default behavior in a real-world app, but I’m unable to make it work: I have a View (a screen/page in this case) that calls an endpoint using async/await. If the endpoint hasn’t finished, but I navigate forward to a DetailView, I want the endpoint to continue fetching data (i.e., inside the @StateObject ViewModel that the View owns). This way, when I go back, the View will have refreshed with the fetched data once it completes. If the endpoint hasn’t finished and I navigate back to the previous screen, I want it to be canceled, and the @StateObject ViewModel should be deinitialized. I can achieve 1 and 3 using the .task modifier, since it automatically cancels the asynchronous task when the view disappears: view .task { await vm.getData() } I can achieve 1 and 2 using a structured Task in the View (or in the ViewModel, its the same behavior), for example: .onFirstAppearOnly { Task { away vm.getData() } } onFirstAppearOnly is a custom modifier that I have for calling onAppear only once in view lifecycle. Just to clarify, I dont think that part is important for the purpose of the example My question is: How can I achieve all three behaviors? My minimum deployment target is iOS 15, and I’m using NavigationView + NavigationLink. However, I have also tried using NavigationStack + NavigationPath and still couldn’t get it to work. Any help would be much appreciated. Thank you!

I'm working on a NavigationStack based app. Somewhere I'm using: @Environment(\.dismiss) private var dismiss and when trying to navigate to that view it gets stuck. I used Self._printChanges() and discovered the environment variable dismiss is changing repeatedly. Obviously I am not changing that variable explicitly. I wasn't able to reproduce this in a small project so far, but does anybody have any idea what kind of thing I could be doing that might be causing this issue? iOS 17.0.3

Hello Apple Developer Forum Community, I’ve got a problem with the display of my SwiftUI View, that is tested on my physical iPhone. It’s shown very small (Picture) and on the Xcode Canvas Simulator it get’s shown right. What is the problem with my code?

How to change the image launch screen using story to show picture display in rotated view when ipad in portrait orientation ? Current launch screen -Image Portrait Orientation -Image Landscape Orientation -Info Setting Expected launch screen as below (Not Working) -Expected Launch Screen I have uploaded the entire sample source here

Hi everyone 👋 I’m fairly new to iOS development and I’ve been stuck on a SwiftUI issue for a while now, so I’m hoping someone here can spot what I’m doing wrong. I’m using navigationTransition(.zoom) together with matchedTransitionSource to animate navigation between views. The UI consists of a grid of items (currently a LazyVGrid, though the issue seems unrelated to laziness). Tapping an item zooms it into its detail view, which is structurally the same view type and can contain further items. All good expect that interactive swipe-back sometimes causes the item to disappear from the grid once the parent view is revealed. This only happens when dismissing via the drag gesture; it does not occur when using the back button. I’ve attached a short demo showing the issue and the Swift file containing the relevant view code. Is there something obvious I’m doing wrong with navigationTransition / matchedTransitionSource, or is this a known limitation or bug with interactive swipe-back? Thanks in advance. import SwiftUI struct TestFileView: View { @Namespace private var ns: Namespace.ID let nodeName: String let children: [String] let pathPrefix: String private func transitionID(for childName: String) -> String { "Zoom-\(pathPrefix)->\(childName)" } private let columns = Array(repeating: GridItem(.flexible(), spacing: 12), count: 3) var body: some View { ScrollView { VStack(alignment: .leading, spacing: 12) { Text(nodeName) .font(.title.bold()) .padding(.bottom, 6) LazyVGrid(columns: columns, spacing: 12) { ForEach(children, id: \.self) { childName in let id = transitionID(for: childName) NavigationLink { TestFileView( nodeName: childName, children: childrenFor(childName), pathPrefix: "\(pathPrefix)/\(childName)" ) .navigationTransition(.zoom(sourceID: id, in: ns)) } label: { TestFileCard(title: childName) .matchedTransitionSource(id: id, in: ns) } .buttonStyle(.plain) } } } .padding() } } private func childrenFor(_ name: String) -> [String] { switch name { case "Lorem": return ["Ipsum", "Dolor", "Sit"] case "Ipsum": return ["Amet", "Consectetur"] case "Dolor": return ["Adipiscing", "Elit", "Sed"] case "Sit": return ["Do", "Eiusmod"] case "Amet": return ["Tempor", "Incididunt", "Labore"] case "Adipiscing": return ["Magna", "Aliqua"] case "Elit": return ["Ut", "Enim", "Minim"] case "Tempor": return ["Veniam", "Quis"] case "Magna": return ["Nostrud", "Exercitation"] default: return [] } } } struct TestFileCard: View { let title: String var body: some View { VStack(alignment: .leading, spacing: 8) { Image(systemName: "square.stack.3d.up") .symbolRenderingMode(.hierarchical) .font(.headline) Text(title) .font(.subheadline.weight(.semibold)) .lineLimit(2) .minimumScaleFactor(0.85) Spacer(minLength: 0) } .padding(12) .frame(maxWidth: .infinity, minHeight: 90, alignment: .topLeading) .background(.thinMaterial, in: RoundedRectangle(cornerRadius: 14, style: .continuous)) } } private struct TestRoot: View { var body: some View { NavigationStack { TestFileView( nodeName: "Lorem", children: ["Ipsum", "Dolor", "Sit"], pathPrefix: "Lorem" ) } } } #Preview { TestRoot() }

I’m running Xcode 26.1.1 (17B100) with deployment target iOS 18.0+, and I’m seeing a consistent and reproducible issue on real devices (iPhone 13 Pro, iPhone 15 Pro): Problem The first time the user taps into a TextField or a SwiftUI .searchable field after app launch, the app freezes for 30–45 seconds before the keyboard appears. During the freeze, the device console floods with: XPC connection interrupted Reporter disconnected. { function=sendMessage, reporterID=XXXXXXXXXXXX } -[RTIInputSystemClient remoteTextInputSessionWithID:performInputOperation:] perform input operation requires a valid sessionID. inputModality = Keyboard customInfoType = UIEmojiSearchOperations After the keyboard finally appears once, the issue never happens again until the app is force-quit. This occurs on device Reproduction Steps Minimal reproducible setup: Create a new SwiftUI app. Add a single TextField or .searchable modifier. Install Firebase (Firestore or Analytics is enough). Build and run on device. Tap the text field immediately after the home screen appears. Result: App freezes for 30–45 seconds before keyboard appears, with continuous XPC/RTIInputSystem errors in the logs. If Firebase is removed, the issue occurs less often, but still happens occasionally. Even If Firebase initialization is delayed by ~0.5 seconds, the issue is still there. Question Is this a known issue with iOS 18 / RTIInputSystem / Xcode 26.1.1, and is there a recommended workaround? Delaying Firebase initialization avoids the freeze, but this isn’t ideal for production apps with startup authentication requirements. Any guidance or confirmation would be appreciated.

Is there any reason why the SwiftUI Image hasn’t a direct init(data: Data) like UIImage from UIKit? In my opinion it’s very unintuitive and expensive to create a UIImage in the first step to create a SwiftUI Image with Image(uiImage: UIImage) in the second step. In addition to that, this causes unnecessary UIKit imports. In my opinion this is a very obvious small in the API, so are there any reasons why it is what it is? Best regards

Are we allowed to use AI-generated images for our Swift Student Challenge Project? The instructions say that we can use third party content but must cite/credit it and be transparent about it. Are we allowed to do the same for AI-generated images? Will this dock points on creativity?