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.

Hello community, I am implementing a Live Activity for my existing App Store app. The Live Activity works perfectly on the iOS Simulator, but it completely fails to appear on the physical device's lock screen. When I call Activity.request, it succeeds and returns a valid Activity ID, but the physical device's console immediately outputs the following errors from liveactivitiesd: liveactivitiesd is not entitled to specify a scene target. Defaulting containingProcess target to liveactivitiesd No asset provider bundle ID provided I have spent days debugging this and have tried every known workaround. Here is the comprehensive list of what I have already verified and attempted: Environment: Xcode: 16.4 iOS Device: iPhone 13 mini, iOS 26.3.1 macOS: Sequoia 15.6 What I have verified/tried (to avoid duplicate suggestions): NSSupportsLiveActivities: It is set to YES in the main app's Info.plist. I also tried adding it to the Widget Extension's Info.plist just in case. App Icons: The main app has a valid AppIcon set in Assets.xcassets. The Primary App Icon Set Name in Build Settings is correctly set to AppIcon. Bundle IDs: They match perfectly (com.mycompany.app and com.mycompany.app.MyWidget). Version & Build Numbers: The main app and the Widget Extension have exactly the same Version and Build numbers. App Groups & Entitlements: Checked and perfectly synced between the main app and the extension. Dummy Widget: Since it's a Live-Activity-only extension, I added a standard static DummyWidget to the WidgetBundle to prevent the known iOS 17 bug where the system ignores extensions without home screen widgets. Memory/Sanitizers: Ensured Address Sanitizer and Zombie Objects are completely disabled in the Scheme to prevent the 30MB memory limit crash on the device. Nuclear Option: Completely deleted the Widget Extension target, wiped DerivedData, restarted the Mac and iPhone, and recreated the extension from scratch. Minimal UI Test: Replaced the widget's UI with a simple Text("Test") to rule out any SwiftUI rendering crashes. Device Settings: Verified that "Live Activities" is enabled under "Face ID & Passcode" settings on the physical iPhone. Despite all of this, the Simulator works flawlessy, while the device throws No asset provider bundle ID provided and shows nothing. Does anyone know what specific condition causes liveactivitiesd to fail to find the asset provider (the parent app) on a physical device for an existing app? Are there any undocumented provisioning profile quirks or obscure Build Settings I might be missing? Any insights would be deeply appreciated. Thank you!

On iOS 26 I’m seeing a small stutter when dismissing a SwiftUI .sheet with the swipe-down gesture. The same code was smooth on iOS 18. Has anyone else experienced this issue?

Hi guys, I’m new on SwiftUI world. I wanted to ask how to achieve this kind of morph transition with ToolbarItem button just like the picture attached below. I have tried using Menu & confirmationDialog API but i didn’t achieve the same kind of looks here. Is there some kind of native API for this kind of transition? Thanks in advance guys 😁👍

Hi everyone, I’m building a SwiftUI app using NavigationStack and running into a weird nav bar issue. For the setup I have a 'home' screen with a vertical ScrollView and a large edge-to-edge header that extends under the top safe area (using .ignoresSafeArea(edges: .top)). I also have a 'detail' screen with a similar immersive layout, where the header/poster image sits at the top and the ScrollView also extends under the top area. I’m using the native navigation bar on both screens and default back button, not a custom nav bar, and I’m not manually configuring UINavigationBarAppearance, I'm just relying on SwiftUI’s default/automatic toolbar behavior. The problem I’m facing is when I push from home to the detail screen, the top nav area briefly flickers and shows the system navigation bar/material background (white in light mode, black in dark mode). It’s clearly the system material, not the poster/image underneath. The screen initially renders with that nav bar state (white/dark), and only after I start scrolling does it correct itself and visually align with the header/background behind it. What I'm thinking is that maybe the detail screen initially renders with systemBackground, so the nav bar uses its default (standard) appearance on the first frame, and only after layout/interaction, once the image-derived background settles, does it switch to the correct scroll-edge/transparent style. One important thing, if I hide the nav bar on the detail screen using .toolbar(.hidden, for: .navigationBar), the issue disappears completely. So this seems specifically tied to the native nav bar’s initial render/appearance timing during the push, rather than just the layout or image loading. I’d prefer to keep the native nav bar and back button rather than implement a custom approach. Has anyone faced this issue before, or is there a correct way to structure edge-to-edge content under the nav bar so it renders properly on first push? Video of the issue: https://imgur.com/a/OYHtYbp NavigationStack { ScrollView { HeroView() } .ignoresSafeArea(edges: .top) .navigationTitle("Cinema") .toolbarTitleDisplayMode(.inlineLarge) .toolbarBackgroundVisibility(.automatic, for: .navigationBar) .navigationDestination(for: Route.self) { route in DetailView(movie: route.movie) } } var body: some View { ScrollView { HeaderPosterView() } .ignoresSafeArea(edges: .top) .navigationBarTitleDisplayMode(.inline) .toolbarBackgroundVisibility(.automatic, for: .navigationBar) } }

Hi everyone, I’m building a SwiftUI app using NavigationStack and running into a weird nav bar issue. For the setup I have a 'home' screen with a vertical ScrollView and a large edge-to-edge header that extends under the top safe area (using .ignoresSafeArea(edges: .top)). I also have a 'detail' screen with a similar immersive layout, where the header/poster image sits at the top and the ScrollView also extends under the top area. I’m using the native navigation bar on both screens and default back button, not a custom nav bar, and I’m not manually configuring UINavigationBarAppearance, I'm just relying on SwiftUI’s default/automatic toolbar behavior. The problem I’m facing is when I push from home to the detail screen, the top nav area briefly flickers and shows the system navigation bar/material background (white in light mode, black in dark mode). It’s clearly the system material, not the poster/image underneath. The screen initially renders with that nav bar state (white/dark), and only after I start scrolling does it correct itself and visually align with the header/background behind it. What I'm thinking is that maybe the detail screen initially renders with systemBackground, so the nav bar uses its default (standard) appearance on the first frame, and only after layout/interaction, once the image-derived background settles, does it switch to the correct scroll-edge/transparent style. One important thing, if I hide the nav bar on the detail screen using .toolbar(.hidden, for: .navigationBar), the issue disappears completely. So this seems specifically tied to the native nav bar’s initial render/appearance timing during the push, rather than just the layout or image loading. I’d prefer to keep the native nav bar and back button rather than implement a custom approach. Has anyone faced this issue before, or is there a correct way to structure edge-to-edge content under the nav bar so it renders properly on first push? Video of the issue: https://imgur.com/a/OYHtYbp

I have attached a screenshot showing the type of behavior in Apple's own Weather app that I am looking to disable in my own app. There is a zoom / card effect where the presenting view shrinks / zooms in the background, exposing a different background color that can look out of place. Notice that when dragging the map view to dismiss it, the views behind it are zoomed in exposing a different background. The presenting view that has this "card" effect has hard edges that do not match the screens corner radius as well, so it just looks out of place. Using this as an example, what would be the way to keep this matched zoom transition but keeping the Weather's background still going edge to edge? In my app I am trying to keep my mesh gradient edge to edge and not zoomed in with black or white borders in a similar situation to what we are seeing in the Weather app on 26.4 Let me know if I need to explain it more. Thank you!

I have two apps written in SwiftUI. Both use a NavigationSplitView as their primary content with a list-based sidebar. Both apps have a few toolbar items offering functionality relevant to the application purpose. Both sidebars have toolbar items, declared using the .toolbar view modifier, that add ToolbarItems to their view (a "filter" menu). Both the apps' main content view use .toolbar to add some ToolbarItems to the main content toolbar as well. Both also include the SidebarCommands() command group. My question is this: in one app, when I click the Hide Sidebar button, the toolbar items that were attached to the sidebar move to the main toolbar. In my second app, the toolbar items move to the "More" disclosure menu at the end of the toolbar. Video showing sidebar leading Video showing sidebar trailing I want behavior like the first app (where the toolbar items end up in the leading edge of the main toolbar) in the second app, but I've scrubbed through both applications' toolbar code, I've had coding assistants compare the two, I've tried stripping down the toolbar items to remove all but the Hide Sidebar. Nothing I can discover shows me why one app moves the toolbar items to the main toolbar up front, while the other moves them to the back. Am I missing something about how to declare toolbar items? Is there some visibility priority thing I’m missing?

Hello everyone, I am experiencing a layout issue in a SwiftUI project where an icon inside a button becomes laggy after the keyboard is dismissed. I have a custom input bar designed with an HStack containing a TextField and a Button with a microphone.fill icon. The entire HStack is styled using a .clipShape(.capsule) and a background color and I am using @FocusState to manage the keyboard focus. When the user taps the TextField, the keyboard appears, and the entire view moves up correctly to make room. But when the keyboard is dismissed by the button action isPromptFieldFocused = false, the capsule-shaped background and the text field return to their original position, but the icon on the button (and just the icon) doesn't. The microphone icon inside the button does not follow the movement. It remains stuck at the "keyboard-up" height for a moment until the view is refreshed, breaking the UI. And by the way, the icon correctly returns to its original position with the other UI elements if the user presses the return key on their keyboard. import SwiftUI struct ContentView: View { @State var userText: String = "" @FocusState var isTextFieldFocused: Bool var body: some View { HStack { TextField("Type here...", text: $userText) .focused($isTextFieldFocused) .textInputAutocapitalization(.sentences) .textFieldStyle(PlainTextFieldStyle()) .padding(.leading, 12) .padding(.trailing, 4) Button(action: { print("Microphone pressed") isPromptFieldFocused = false }) { Image(systemName: "microphone.fill") .font(.system(size: 22, weight: .semibold)) .foregroundStyle(.white) .padding(14) } .background(Color.black) .clipShape(Circle()) .padding(.trailing, 14) .padding(.vertical, 14) } .background(Color.lightGray) .clipShape(Capsule()) .padding() } } I've already tried using different animation types (e.g., .default, .spring) and explicitly setting the frame of the button. Has anyone encountered this specific behavior where an Image(systemName:) ignores the parent container's transition during keyboard dismissal? I would appreciate any insights on how to ensure the entire HStack and its children animate back down in sync.

I have a simple reproducer here: struct ContentView: View { @State private var isOn = false @State private var isPresented = false var body: some View { NavigationStack { Color.blue .toolbar { ToolbarItem(placement: .topBarTrailing) { Button("Press here") { isPresented = true } .popover(isPresented: $isPresented) { Color.green .frame(idealWidth: 400, idealHeight: 500) .presentationCompactAdaptation(.popover) } } } } } } When I tap on the button in the toolbar you can see there is a hang then the popover shows. Then every time after there is no longer a hang so this seems like a bug. Any ideas? I'm using Xcode 26.3 and a iPad Pro 13-inch (M5) (26.4) simulator.

If you use .navigationTransition(.zoom(sourceID: zoomID, in: namespace)) with a carousel or a card view, which uses : .stroke(Color.secondary.opacity(0.5), lineWidth: 5) It causes the border stroke to render incorrectly, and even in some cases, the card glitches out and disappears from the screen. The card is clickable but there is no entity in the placeholder of that place.

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

Navigation title also scroll below the content when using scrollview. working fine in iOS 18 and below. one of the UI component is outside the scrollview which is causing the issue. struct ContentView: View { var body: some View { VStack { Rectangle() .frame(maxWidth: .infinity) .frame(height: 60) .padding(.horizontal) .padding(.top) ScrollView { ForEach(0...5, id: \.self) { _ in RoundedRectangle(cornerRadius: 10) .fill(.green) .frame(maxWidth: .infinity) .frame(height: 100) .padding(.horizontal) } } } .navigationTitle("Hello World") } }

Navigation title scroll along with the content in iOS 26. working fine in iOS 18 and below. One of my UI component is outside the scrollview which is causing the issue. var body: some View { VStack { Rectangle() .frame(maxWidth: .infinity) .frame(height: 60) .padding(.horizontal) .padding(.top) ScrollView { ForEach(0...5, id: \.self) { _ in RoundedRectangle(cornerRadius: 10) .fill(.green) .frame(maxWidth: .infinity) .frame(height: 100) .padding(.horizontal) } } } .navigationTitle("Hello World") } }

My SwiftUI app runs as a floating card window on iOS 26 iPhone instead of full screen. UIRequiresFullScreen and UIApplicationSupportsMultipleScenes: false don't fix it. What's the iOS 26 Info.plist key or API to opt out of windowed mode? First iOS app, I'm very confused, and have been trying different things for like 3 days. Any nudge in the right direction would be wildly appreciated. Thanks! Mark

Hi, I'm using one ttf font that simulate a bitmap look in my app. However, macOS renders all font with anti-aliasing. On those kind of font, that introduce some artefacts. Is there a way to disable anti-aliasing or some tricks that would make like there were no anti-aliasing? Thanks.

[Also submitted as FB20756013] A popoverTip does not display for toolbar menu buttons in iOS 26.1 (23B5073a). The same code displays tips correctly in iOS 18.6. The issue occurs both in the simulator and on a physical device. Repro Steps Build and run the Sample Code below on iOS 26.1. Observe that the popoverTip does not display. Repeat on iOS 18.6 to confirm expected behavior. Expected popoverTips should appear when attached to a toolbar menu button, as they do in iOS 18.6. Actual No tip is displayed on iOS 26.1. System Info macOS 15.7.1 (24G231) Xcode 26.1 beta 3 (17B5045g) iOS 26.1 (23B5073a) Screenshot Screenshot showing two simulators side by side—iOS 18.6 on the left (tip displayed) and iOS 26.1 on the right (no tip displayed). Sample code import SwiftUI import TipKit struct PopoverTip: Tip { var title: Text { Text("Menu Tip") } var message: Text? { Text("This tip displays on iOS 18.6, but NOT on iOS 26.1.") } } struct ContentView: View { var tip = PopoverTip() var body: some View { NavigationStack { Text("`popoverTip` doesn't display on iOS 26.1 but does in iOS 18.6") .padding() .toolbar { ToolbarItem(placement: .topBarTrailing) { Menu { Button("Dismiss", role: .cancel) { } Button("Do Nothing") { } } label: { Label("More", systemImage: "ellipsis") } .popoverTip(tip) } } .navigationTitle("Popover Tip Issue") .navigationBarTitleDisplayMode(.inline) } } }

[Submitted as FB21961572] When navigating from a tile in a scrolling LazyVGrid to a child view using .navigationTransition(.zoom) and then returning, the source tile can lag behind the rest of the grid if scrolling starts immediately after returning. The lag becomes more pronounced as tile content gets more complex; in this simplified sample, it can seem subtle, but in production-style tiles (as used in both of my apps), it is clearly visible and noticeable. This may be related to another issue I recently filed: Source item disappears after swipe-back with .navigationTransition(.zoom) CONFIGURATION Platform: iOS Simulator and physical device Navigation APIs: matchedTransitionSource + navigationTransition(.zoom) Container: ScrollView + LazyVGrid Sample project: ZoomTransition (DisappearingTile).zip REPRO STEPS Create a new iOS project and replace ContentView with the code below. Run the app in sim or physical device Tap any tile in the scrolling grid to navigate to the child view. Return to the grid (back button or edge swipe). Immediately scroll the grid. Watch the tile that was just opened. EXPECTED All tiles should move together as one coherent scrolling grid, with no per-item lag or desynchronization. ACTUAL The tile that was just opened appears to trail behind neighboring tiles for a short time during immediate scrolling after returning. MINIMAL CODE SAMPLE import SwiftUI struct ContentView: View { @Namespace private var namespace private let tileCount = 40 private let columns = [GridItem(.adaptive(minimum: 110), spacing: 12)] var body: some View { NavigationStack { ScrollView { LazyVGrid(columns: columns, spacing: 12) { ForEach(0..<tileCount, id: \.self) { index in NavigationLink(value: index) { RoundedRectangle(cornerRadius: 16) .fill(color(for: index)) .frame(height: 110) .overlay(alignment: .bottomLeading) { Text("\(index + 1)") .font(.headline) .foregroundStyle(.white) .padding(10) } .matchedTransitionSource(id: index, in: namespace) } .buttonStyle(.plain) } } .padding(16) } .navigationTitle("Zoom Transition Grid") .navigationSubtitle("Open tile, go back, then scroll immediately") .navigationDestination(for: Int.self) { index in Rectangle() .fill(color(for: index)) .ignoresSafeArea() .navigationTransition(.zoom(sourceID: index, in: namespace)) } } } private func color(for index: Int) -> Color { let hue = Double(index % 20) / 20.0 return Color(hue: hue, saturation: 0.8, brightness: 0.9) } } SCREEN RECORDING

Hi, I have created this UI using custom view and not a real sheet component. But the animations and interaction is not as smooth. Earlier I was using sheet component and it was working very well, but then I had a need to add a search button on top of sheet (not inside, that is very important). And so I created this whole sheet with custom view and not the sheet component. But it resulted in loss of fluid working and animations that sheet have. Including changing between Medium detent and Large detent. Is it possible to achieve this UI with native sheet component? Or using some other native swiftui view which will have good animation that sheet has?

Hello, I am building an audio player app in SwiftUI and trying to recreate the behavior of Apple Music's mini player and full player. I'm struggling to get the animation to seamlessly transition between the mini player and the full player. Currently, it feels disconnected and doesn't resemble the smooth animation seen in Apple Music. What I want to achieve: Full player that expands/collapses from/to the mini player Smooth artwork transition between both states Drag down to collapse the full player Support both newer APIs like tabViewBottomAccessory and older iOS versions Questions: What is the best way to build this transition in SwiftUI? Should I use matchedGeometryEffect or something else? Should this be a custom container instead of fullScreenCover? How would you support both new and older iOS versions? What is the best way to implement drag to dismiss? Thanks for any help! Example code: struct ContentView: View { @State private var isFullPlayerPresented = false var body: some View { TabView { Tab("Home", systemImage: "house") { Text("Home") .frame(maxWidth: .infinity, maxHeight: .infinity) .background(.green) } Tab("Library", systemImage: "rectangle.stack.fill") { Text("Library") .frame(maxWidth: .infinity, maxHeight: .infinity) .background(.brown) } } .tabViewBottomAccessory(isEnabled: !isFullPlayerPresented) { MiniPlayerView(isFullPlayerPresented: $isFullPlayerPresented) } .fullScreenCover(isPresented: $isFullPlayerPresented) { // Maybe it's not a full screen cover presentation in Apple Music? FullPlayerView(isFullPlayerPresented: $isFullPlayerPresented) } } } Mini player: struct MiniPlayerView: View { @Binding var isFullPlayerPresented: Bool var body: some View { Button { isFullPlayerPresented = true } label: { HStack { Image(systemName: "photo") .resizable() .scaledToFit() .frame(width: 30, height: 30) .clipShape(.rect(cornerRadius: 8)) Spacer() Text("Tap to open full player") Spacer() Button("", systemImage: "play.fill", action: {}) } .padding(.horizontal) .padding(.vertical, 4) } .foregroundStyle(.white) } } Full player: struct FullPlayerView: View { @Binding var isFullPlayerPresented: Bool var body: some View { // This art work needs to snaps to the artwork in mini player Image(systemName: "photo") .resizable() .scaledToFit() .frame(width: 250, height: 250) .clipShape(.rect(cornerRadius: 20)) .frame(maxWidth: .infinity, maxHeight: .infinity) .background(.red) .overlay(alignment: .topTrailing) { Button(role: .close) { isFullPlayerPresented = false } .foregroundStyle(.white) .padding() } } }

When you use .navigationTransition(.zoom(sourceID: "placeholder", in: placehoder)) for navigation animation, going back using the swipe gesture is still very buggy on IOS26. I know it has been mentioned in other places like here: https://developer.apple.com/forums/thread/796805?answerId=856846022#856846022 but nothing seems to have been done to fix this issue. Here is a video showing the bug comparing when the back button is used vs swipe to go back: https://imgur.com/a/JgEusRH I wish there was a way to at least disable the swipe back gesture until this bug is fixed.