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.

Any idea how to achieve this? I've tried: ToolbarItemGroup(placement: .principal) and ToolbarItem(placement: .principal) also tried with a VStack but it does not work.

'm trying to write my own stack, and the issue I'm encountering is how to get the child content of a ForEach. // // ContentView.swift // test // // Created by cnsinda on 2025/10/18. // import SwiftUI public struct MyStack<Content: View>: View { var content: [Content] public init(@MyStackBuilder<Content> content: @escaping () -> [Content]) { self.content = content() } public var body: some View { VStack { // I expect to get 9, but it always returns 1. Text("count:\(content.count)") } } } @resultBuilder public enum MyStackBuilder<Value: View> { static func buildBlock() -> [Value] { [] } public static func buildBlock(_ components: Value...) -> [Value] { components } public static func buildBlock(_ components: [Value]...) -> [Value] { components.flatMap { $0 } } // hit public static func buildExpression(_ expression: Value) -> [Value] { [expression] } public static func buildArray(_ components: [[Value]]) -> [Value] { components.flatMap { $0 } } static func buildFinalResult(_ components: [Value]) -> [Value] { components } public static func buildExpression(_ expression: ForEach<[Int], Int, Value>) -> [Value] { expression.data.flatMap { index in [expression.content(index)] } } public static func buildEither(first: [Value]) -> [Value] { return first } public static func buildEither(second: [Value]) -> [Value] { return second } public static func buildIf(_ element: [Value]?) -> [Value] { return element ?? [] } } struct ContentView: View { var body: some View { ZStack { MyStack { ForEach([100, 110, 120, 130, 140, 150, 160, 170, 180], id: \.self) { item in Rectangle().frame(width: item, height: 20).padding(10) } } } .frame(width: 600, height: 600) } } My expectation is to get each individual Rectangle(), but the actual result is that the entire ForEach is treated as a single View. What should I do?

I'm trying to create a UI with two button bars (top and bottom) inside the detail view of a NavigationSplitView, instead of using the built-in .toolbar() modifier. I'm using .ignoresSafeArea(.container, edges: .vertical) so the detail view can reach into that area. However, in macOS and iOS 26 the top button is not clickable/tappable because it is behind an invisible View created by the non-existent toolbar. Interestingly enough, if I apply .buttonStyle(.borderless) to the top button it becomes clickable (in macOS). On the iPad the behavior is different depending on the iPad OS version. In iOS 26, the button is tappable only by the bottom half. In iOS 18 the button is always tappable. Here's the code for the screenshot: import SwiftUI struct ContentView2: View { @State private var sidebarSelection: String? @State private var contentSelection: String? @State private var showContentColumn = true @State private var showBars = true var body: some View { NavigationSplitView { // Sidebar List(selection: $sidebarSelection) { Text("Show Content Column").tag("three") Text("Hide Content Column").tag("two") } .navigationTitle("Sidebar") } detail: { VStack(spacing: 0) { if showBars { HStack { Button("Click Me") { withAnimation { showBars.toggle() } } .buttonStyle(.borderedProminent) } .frame(maxWidth: .infinity, minHeight: 50, idealHeight: 50, maxHeight: 50) .background(.gray) .transition(.move(edge: .top)) } ZStack { Text("Detail View") } .frame(maxWidth: .infinity, maxHeight: .infinity, alignment: .init(horizontal: .center, vertical: .center)) .border(.red) .onTapGesture(count: 2) { withAnimation { showBars.toggle() } } if showBars { HStack { Button("Click Me") { withAnimation { showBars.toggle() } } } .frame(maxWidth: .infinity, minHeight: 50, idealHeight: 50, maxHeight: 50) .background(.gray) .transition(.move(edge: .bottom)) } } .ignoresSafeArea(.container, edges: .vertical) .toolbarVisibility(.hidden) } .toolbarVisibility(.visible) } } I'm confused by this very inconsistent behavior and I haven't been able to find a way to get this UI to work across both platforms. Does anybody know how to remove the transparent toolbar that is preventing clicks/taps in this top section of the view? I'm hoping there's an idiomatic, native SwiftUI way to do it.

Filed as FB20766506 I have a very simple use case for a rectangular widget on the iPhone lock screen: One Text element which should fill as much space as possible. However, it only ever does 2 per default and then eclipses the rest of the string. Three separate Text elements work fine, so does a fixedSize modifier hack (with that even four lines are possible!). Am I completely misunderstanding something or why is this not possible per default? Other apps' widgets like Health do it as well. My attempt (background added for emphasis) Health app widget var body: some View { VStack(alignment: .leading) { /// This should span three lines, but only spans 2 which eclipsed text. Text("This is a very long text which should span multiple lines.") // .fixedSize(horizontal: false, vertical: true) /// Using this fixes it as well, but that does not seem like a good default solution. /// Three separate `Text` elements work fine. // Text("This is a very long") // Text("text which should") // Text("span multiple lines.") } .frame(maxWidth: .infinity, maxHeight: .infinity, alignment: .leading) .background(Color.black) /// Added for emphasis of the widget frame }

We use SwiftUI's .tabViewBottomAccessory in our iOS apps for displaying an Audio MiniPlayer View (like in the Apple Music App). TabView(selection: $viewModel.selectedTab) { // Tabs here } .tabViewBottomAccessory { if viewModel.showAudioMiniPlayer { MiniPlayerView() } } The Problem This code works perfectly on iOS 26.0. When viewModel.showAudioMiniPlayer is false, the accessory is completely hidden. However, on iOS 26.1 (23B5059e), when 'viewModel.showAudioMiniPlayer' becomes false, the MiniPlayerView disappears, but an empty container remains, leaving a blank space above the tab bar. Is this a known Bug in iOS 26.1 and are there any effective workarounds?

We have a custom implementation of what we call a “Scrollable Header” in our app. After building with Xcode 26, we’ve observed a change in behavior with the List component. The issue can be seen in the attached GIF: As the user scrolls up, the header is expected to collapse smoothly, and it does—until the moment the next list item becomes visible. At that point, the header collapses prematurely, without any apparent reason. We’ve identified that this behavior occurs after the list’s data-fetching logic runs, which loads additional items as the user scrolls. Below is the ViewModifier responsible for handling the collapsing header logic: @available(iOS 18.0, *) public struct L3CollapseHeaderIOS18: ViewModifier { private let minHeight: Double = 0 private let expandedHeight: CGFloat private let L3Height = 44.0 private let isViewVisible: Bool @Binding private var currentHeight: CGFloat @State private var lastOffset: ScrollOffsetInfo = ScrollOffsetInfo(offset: 0.0, offsetToBottom: 0.0, scrollableContent: 0.0) init(currentHeight: Binding<CGFloat>, expectedHeight: CGFloat, isViewVisible: Bool) { self._currentHeight = currentHeight self.expandedHeight = expectedHeight self.isViewVisible = isViewVisible } public func body(content: Content) -> some View { content .onScrollGeometryChange(for: ScrollOffsetInfo.self, of: { geometry in if isViewVisible { return ScrollOffsetInfo(offset: geometry.contentOffset.y, offsetToBottom: (geometry.contentSize.height) - (geometry.contentOffset.y + geometry.containerSize.height), scrollableContent: geometry.contentSize.height - geometry.containerSize.height) } else { return lastOffset } }, action: { oldValue, newValue in if isViewVisible { expandOrCollapseHeader(oldValue: oldValue, newValue: newValue) } }) } private func expandOrCollapseHeader(oldValue: ScrollOffsetInfo, newValue: ScrollOffsetInfo) { let oldScrollableContent = round(oldValue.scrollableContent) let newScrollableContent = round(newValue.scrollableContent) print("@@ scrollable content: \(newScrollableContent), old value: \(oldScrollableContent)") if newScrollableContent != oldScrollableContent {/*abs(newValue.offset) - abs(oldValue.offset) > 80*/ return } let isInitialPosition = newValue.offset == 0 && lastOffset.offset == 0 let isTryingToBounceUp = newValue.offset < 0 let isTryingToBounceDown = newValue.offsetToBottom < 0 // As the header collapses, the scrollable content decreases its size let remainingHeaderSpaceVisible = expandedHeight - currentHeight // remainingHeaderSpaceVisible is summed to know the exact scrollableContent size let isScrollableContentSmallToAnimate = (newValue.scrollableContent + remainingHeaderSpaceVisible) < (expandedHeight * 2 + currentHeight) if isInitialPosition || isScrollableContentSmallToAnimate { expandHeader(0) return } let scrollDirection = scrollDirection(newValue, oldOffset: oldValue) switch scrollDirection { case .up(let value): if isTryingToBounceUp { expandHeader(0) return } print("@@ will collapse with value: \(value)") collapseHeader(value) case .down(let value): if isTryingToBounceDown { collapseHeader(0) return } print("@@ will expand with value: \(value)") expandHeader(value) case .insignificant: return } } private func expandHeader(_ value: CGFloat) { currentHeight = min(68.0, currentHeight - value) } private func collapseHeader(_ value: CGFloat) { currentHeight = max(0, currentHeight - value) } private func scrollDirection(_ currentOffset: ScrollOffsetInfo, oldOffset: ScrollOffsetInfo) -> ScrollDirection { let scrollOffsetDifference = abs(currentOffset.offset) - abs(oldOffset.offset) print("@@ currentOffset: \(currentOffset.offset), oldOffset: \(oldOffset.offset), difference: \(scrollOffsetDifference)") let status: ScrollDirection = scrollOffsetDifference > 0 ? .up(scrollOffsetDifference) : .down(scrollOffsetDifference) lastOffset = currentOffset return status } enum ScrollDirection { case up(CGFloat) case down(CGFloat) case insignificant } } public struct ScrollOffsetInfo: Equatable { public let offset: CGFloat public let offsetToBottom: CGFloat public let scrollableContent: CGFloat } public struct ScrollOffsetInfoPreferenceKey: PreferenceKey { public static var defaultValue: ScrollOffsetInfo = ScrollOffsetInfo(offset: 0, offsetToBottom: 0, scrollableContent: 0) public static func reduce(value: inout ScrollOffsetInfo, nextValue: () -> ScrollOffsetInfo) { } } We use this ViewModifier to monitor updates to the List’s frame via the onScrollGeometryChange method. From our investigation (see the screenshot below), it appears that onScrollGeometryChange is triggered just before the content size updates. The first event we receive corresponds to the view’s offset, and only nanoseconds later do we receive updates about the content’s scrollable height. I’ll share the code for the List component using this modifier in the comments (it exceeded the character limit here). Can anyone help us understand why this change in behavior occurs after building with Xcode 26? Thanks in advance for any insights.

I am using AlarmKit to schedule alarms in an app I am working on, however my scheduled alarms only show up on the lock screen. If I am on the home screen or elsewhere I only hear the sound of the alarm, but no UI shows up. Environment: iOS 26 beta 3 Xcode 26 beta 3

Hi! I wrote a SwiftUI based app which does use a layout similar to a calendar. A week view with 5 day-views. Each day view may contain several record views. I've implemented a drag for the records which works well inside a day view (up and down) but I can't get it working between the days. Here is an example how it looks: Any idea or example how to get the proper coordinate information related to the week view inside the rectangle view? A GeometryReader inside the Rectangle view does not give me the needed information. I have currently no idea how to implement it properly…

When showing an Alert from within a Popover that has a fixed height, the newly presented Alert is in the same position but gets limited by the Popovers height causing the title of the Alert to be hidden. Is this intentional behavior or are Alerts not supported within Popovers and I'd have to pass it through to my main view? Code: // // DemoalertPopover.swift // ******** // // Created by Thilo on 26.06.2023. // import SwiftUI struct DemoAlertPopover: View { @Environment(\.dismiss) var dismiss @State private var showDeleteConfirmation = false let dateFormatter: DateFormatter = { let formatter = DateFormatter() formatter.dateFormat = "dd.MM.yyyy" return formatter }() var body: some View { VStack(alignment: .leading, spacing: 0) { HStack { Text("Title").font(.extraLargeTitle).lineLimit(1) Spacer() Button(action: { dismiss() }) { Label("Close", systemImage: "xmark").labelStyle(.iconOnly) } } HStack(alignment: .center) { Text("Content").font(.largeTitle) Text("Content2").foregroundStyle(.secondary) } LazyVGrid(columns: [GridItem(.flexible(), spacing: 10),GridItem(.flexible(), spacing: 10),], spacing: 10) { Button(action: { showDeleteConfirmation = true }) { ZStack{ Image(systemName: "trash.fill").resizable().foregroundColor(.primary) }.aspectRatio(1/1,contentMode: .fit) .frame(maxWidth: .infinity).padding(5) }.aspectRatio(3/1,contentMode: .fit) }.alert("Are you sure you want to delete ...?", isPresented: $showDeleteConfirmation) { Button("Trash",role: .destructive, action: { print("Deleted") dismiss() }) Button("Cancel", role: .cancel) {} } message: { Text("This is a small message below the title, just so you know.") } } .padding(.all, 10).frame(width: 300) } } #Preview { DemoAlertPopover() } Video: https://www.youtube.com/shorts/31Kl7qbJIiA

Filed in Feedback as FB20772137 Zoom transition originating from inside tabViewBottomAccessory, when the binding passed to fullScreenCover's item is a Binding other than a "$-synthesized" binding, the animation fails with the following error (and crucially fails to perform the desired animation): Starting a zoom transition from a nil view will trigger a fallback transition. To get the best possible teansition, be sure to provide a view that's visible and in a window. What I want to do is pass a binding to a property inside an ObservableObject (or @Observable, but it doesn't matter) to hold the item representing the presentation. But this stopped working as of 26.1b4. It worked in 26.1b3 and in 26.0 (and 26.0.1) Here's the gist of code that will reproduce the issue (I've omitted irrelevant details in the interest of brevity): struct ContentView: View { @Binding var presentation: PresentationDestination? @Namespace private var animation var body: some View { // Omitted TabView stuff… .tabViewBottomAccessory { miniPlayer .matchedTransitionSource( id: "player", in: animation ) } .fullScreenCover( item: $presentation, content: { _ in fullScreenPlayer .navigationTransition( .zoom( sourceID: "player", in: animation ) ) }) } As you can see, ContentView takes a Binding to the presentation, but it matters how this binding is constructed. This works: @State private var presentation: PresentationDestination … ContentView(presentation: $presentation) This fails (as does ObservableObject with @Published): @Observable class Router2 { var presentation: PresentationDestination? } … @State private var router2 = Router2() … ContentView(presentation: $router2.presentation) Also, this fails: @State private var presentation: PresentationDestination … ContentView( presentation: .init(get: { presentation }, set: { newValue in presentation = newValue }) ) These differences are unexpected, of course. I consider this a regression in 26.1b4 I should add that if I move the source of the transition to somewhere outside tabViewBottomAccessory things seem to work fine.

When I create a SwiftUI toolbar item with placement of .keyboard on iOS 26, the item appears directly on top of and in contact with the keyboard. This does not look good visually nor does it match the behavior seen in Apple's apps, such as Reminders. Adding padding to the contents of the toolbar item only expands the size of the item but does not separate the capsule background of the item from the keyboard. How can I add vertical padding or spacing to separate the toolbar item capsule from the keyboard?

In iOS 26.1, SwiftUI's tabViewBottomAccessory API cannot control visibility properly. The tabViewBottomAccessory remains always visible, which is inconsistent with the behavior in iOS 26.0 / iOS 26.0.1. ` struct ContentView: View { enum Tabs { case first } @State private var selection: Tabs = .first @State private var showBottomAccessory: Bool = true var body: some View { tabView } var tabView: some View { TabView(selection: $selection) { Tab(value: .first) { content } label: { VStack { Text("first") } } } .tabViewBottomAccessory { if showBottomAccessory { Text("BottomAccessory") } } } var content: some View { Button("change") { showBottomAccessory.toggle() } } } `

Hi there, Upon using List View for tabular information showcase on both iOS and iPadOS, I have come to realize that the drag and drop support works only for iPadOS but not iOS. Although it is possible to workaround this by using a ScrollView wrapping around a LazyVStack instead, the editing mode along with left-wipe to delete feature would be missing. Not to mention that this workaround only supports single item rather than multiple items. Therefore, I am here to ask if the drag and drop will come to support devices running iOS, and if so, when will this feature ship. If not, will LazyVStack/LazyHStack support native editing mode. Thank you for your time.

When a TextField is set to a rightToLeft layout, it gets strange and unnecessary padding on the left side. This pushes the text away from the edge. This issue doesn't occur in the leftToRight layout, where the text aligns correctly. Does anyone know how to get rid of this extra padding? Environment: Xcode version: 26.0.1 Device: iPhone 13 iOS version: 26.0 Code: struct ContentView: View { @State var textInput: String = "" var body: some View { VStack { Text("rightToLeft") TextField("placeholder", text: $textInput) .background(Color.red) .environment(\.layoutDirection, .rightToLeft) Text("leftToRight") TextField("placeholder", text: $textInput) .background(Color.red) .environment(\.layoutDirection, .leftToRight) } .padding() } }

Hi everyone, I'm updating my app to adopt the new search bar design in iOS 26 and I'm running into some UI issues depending on the implementation pattern. I'm using Xcode 26.0.1 and SwiftUI 6. I've tried two main approaches for search, and each has a specific problem related to TabView. Pattern 1: Searchable View Inside a Standard Tab In this pattern, the search bar is specific to one of the main tabs. The Code: struct ContentView: View { var body: some View { TabView { Tab("Main", systemImage: "list.bullet") { MainView() } Tab("View1", systemImage: "gearshape") { Text("View1") } Tab("View2", systemImage: "gearshape") { Text("View2") } } } } struct MainView: View { @State private var searchText = "" var body: some View { NavigationStack { List { Text("Text 1") Text("Text 2") } .searchable(text: $searchText, placement: .toolbar) .navigationTitle("Main") } } } The Problem: When I preview MainView directly, the search bar correctly appears at the bottom, matching the new iOS 26 design. However, when MainView is presented inside the TabView in ContentView, two issues occur: Incorrect Position: The search bar reverts to the old style, appearing at the top of the view, attached to the navigation bar. Initially Hidden: Often, on the first appearance of the view, the search bar is hidden until I actively pull down on the list. It seems like the TabView environment is interfering with the expected placement and initial state of the searchable modifier. Pattern 2: Dedicated Global Search Tab (role: .search) Here, I'm using a dedicated tab for a global search experience, with the searchable modifier on the TabView itself. The Code: struct ContentView: View { @State private var searchText: String = "" var body: some View { TabView { Tab(role: .search) { SearchView() } Tab("Main", systemImage: "list.bullet") { MainView() } Tab("View1", systemImage: "gearshape") { Text("View1") } Tab("View2", systemImage: "gearshape") { Text("View2") } } .searchable(text: $searchText) } } struct MainView: View { var body: some View { NavigationStack { List { Text("Text 1") Text("Text 2") } .navigationTitle("Main") } } } The Problem: The search state is leaking into other tabs in an unexpected way. Steps to Reproduce: Run the app and tap on the "Search" tab. Tap the search bar to activate it and bring up the keyboard. Now, tap on the "Main" tab. Result: The app switches to MainView, but the search bar remains active and focused at the top of the MainView. This is incorrect; the search UI should be dismissed when switching away from the search context. Interestingly, if I tap on "View1" or "View2" (which don't have a NavigationStack), the search bar is correctly dismissed. This suggests the .searchable modifier on the TabView is attaching its UI to the first available NavigationStack it finds in the selected tab. My Questions: For Pattern 1, is there a correct way to ensure the new bottom-placed search bar appears reliably inside a TabView? For Pattern 2, how can I ensure the search state is properly dismissed when navigating away from the search tab, even to a tab that contains a NavigationStack? Is this a potential bug, or am I misusing the APIs for these scenarios? Any guidance or workarounds would be greatly appreciated. Thanks!

We are building a CarPlay app and have run into an issue with data updates. When the app is running on the CarPlay display and the iPhone screen is locked, no data updates are shown on the CarPlay screen. As soon as the phone is unlocked, the data updates appear instantly on the CarPlay display. Has anyone encountered this behavior before? Is there a specific setting, entitlement, or background mode we need to enable in order to ensure the CarPlay app continues to receive and display data while the iPhone is locked? Any guidance would be greatly appreciated.

I am working with the rich TextEditor introduced in iOS 26, but I am having trouble preserving AttributedString formatting when converting to/from RTF. Here is my exporting logic in my view model (AttributedString to RTF) let nsAttrStr = NSAttributedString(self.text) // text is an AttributedString (bound to the TextEditor input) let range = NSRange(location: 0, length: nsAttrStr.length) let options: [NSAttributedString.DocumentAttributeKey: Any] = [ .documentType: NSAttributedString.DocumentType.rtf ] guard let data = try? nsAttrStr.data(from: range, documentAttributes: options) else { return nil } let rtfBase64 = data.base64EncodedString() When I inspect the result, it seems to lose the font, size, boldness, etc which is being correctly rendered in the TextEditor. When I convert back from RTF to an AttributedString, it reverts to the default text formatting applied in the TextEditor. Any ideas what could be going wrong?

This example is based on the latest version of Swift 6.2 for macOS. I have several classes that cannot conform to Codable for various reasons. This, unfortunately, prevents me from using Transferable. If I serialize a class instance into a Data blob and use that for drag-and-drop, it works perfectly — the drag operation succeeds. However, the destination has no way to distinguish between different types of Data blobs. All I’d need is a way to specify a unique identifier and type that I could reference in the drop handler to determine what kind of object I’m working with. Being restricted to Transferable feels quite limiting when your data models can’t conform to Codable. It’s honestly frustrating. Has anyone else run into this issue? Is there a reliable workaround? I tried creating a Transferable wrapper like this: struct CustomObjectTransfer: Codable, Transferable { var data: Data static var transferRepresentation: some TransferRepresentation { // Cannot use '.myGreatSettings' because Main actor–isolated static property 'myGreatSettings' cannot be referenced from a nonisolated context CodableRepresentation(contentType: .init(exportedAs: "com.yourProject.settings")) } } extension UTType { static let myGreatSettings: UTType = UTType("com.yourProject.settings")! } In my list view .draggable ( CustomObjectTransfer(data: myObjectData) ) The UI correctly recognizes the item as draggable. If I misspell the exportedAs identifier, it even throws an error, confirming that the exported type is being recognized by the system. However, the drop destination completely ignores this type: .dropDestination(for: CustomObjectTransfer.self) { items, location in dump(items) return true }isTargeted: { isTargeted in myDestinationIsTargeted = isTargeted } If I switch to using Data.self directly — wrapping the original object data manually — everything works. I can deserialize and validate the data as needed. The problem arises when handling multiple custom drag types. The drop target accepts any data, regardless of its intended type. You only find out the actual type after the drop occurs, during validation — which is too late. By then, isTargeted has already turned true, making the drop appear valid to the user when it actually isn’t. Again anyone else feel this pain? Or is there a workaround that I am missing?

I have multiple document based SwiftUI apps without any NavigationBar customization. Since upgrading to iOS 26 , when these apps launch, sometimes their navigation bar icons appear grey (as if only the button shadows were showing) and the document title is white, so it’s invisible. One of the apps has an Inspector: here, whenever the Inspector appears, the colors are correct. This behavior has been consistent since the first iOS 26 developer beta and can be reproduced on iOS 26.1 beta 23B5064e. So far I have only managed to reproduce this in light mode.

I'm running the new iOS 26 SwiftUI Instruments and seeing a lot of red/hitches, even with Apple's own Backyard Birds sample project. Is anyone else experiencing this? Not sure if it's a general iOS 26 issue or specific to my device (iPhone SE 2nd gen). Would appreciate hearing if others are seeing similar results.