The toolbar in the the Mail app uses seems to force a .soft scrollEdgeEffectStyle, however I can't seem to reproduce this. Even when putting .scrollEdgeEffectStyle(.soft, for: .top) all over my code, a NavigationSplitView seems to force a "classic" toolbar. Example, top is the mail app, bottom is my swiftUI app:

Hi everyone, I’m testing our SwiftUI app on both Xcode simulator and a real iPhone. On the simulator, everything looks clean and aligned. But when I run it on an actual iPhone (same build, iOS 18), the layout looks broken—fonts overlap, spacing is off, and elements are misaligned. Both screenshots are from the exact same screen and time. First is simulator, second is iPhone. Any idea why this difference happens? Is there something I should check in terms of rendering or layout settings? Thanks in advance!

When building with the iOS 26 SDK (currently beta 4), the navigation title is often illegible when rendering a Map view. For example, note how the title "Choose Location" is obscured by the map's text ("South America") in the screenshot below: This screenshot is the result of the following view code: import MapKit import SwiftUI struct Demo: View { var body: some View { NavigationStack { Map() .navigationTitle(Text("Choose Location")) .navigationBarTitleDisplayMode(.inline) } } } I tried using the scrollEdgeEffectStyle(_:for:) modifier to apply a scroll edge effect to the top of the screen, in hopes of making the title legible, but that doesn't seem to have any effect. Specifically, the following code seems to produce the exact same result shown in the screenshot above. import MapKit import SwiftUI struct Demo: View { var body: some View { NavigationStack { Map() .scrollEdgeEffectStyle(.hard, for: .top) // ⬅️ no apparent effect .navigationTitle(Text("Choose Location")) .navigationBarTitleDisplayMode(.inline) } } } Is there a recommended way to resolve this issue so that the navigation title is always readable?

I'm currently exploring ways to update a widget's display independently of the timeline mechanism. While researching, I came across this thread and started experimenting with the approach: https://developer.apple.com/forums/thread/720640 As part of the implementation, I'm attempting to render a 00:00-style time string using a single custom font glyph via .timer. However, I noticed that the colon character used in .timer doesn't appear to be the standard Unicode 0x003A (colon). It seems to be a different character entirely. Does anyone happen to know exactly which character this colon is? Any insights would be appreciated.

With Xcode 26.0 Beta 4 the container concentric API is finally available, which is great! What I was wondering is how to use this API for button shapes. At the moment it seems that there is no ButtonBorderShape available that would behave like ConcentricRectangle. Is this intentional or is it expected that with upcoming beta versions we can also use the concentric style as button border shapes? Or is there maybe another way of getting the buttons shape to behave like a concentric shape? A use case I currently see is having the button as part of a container, using the .bordered button style and then aligning the corners of the button use the concentric style. Any information about this is highly appreciated. Thank you very much!

In a UIKit-based project, I am attempting to integrate SwiftUI components. However, I encounter a persistent issue that hinders this integration. This problem arises when pushing a SwiftUI view using UIHostingController and subsequently attempting to push a UIKit view controller using UIViewControllerRepresentable. Not only are the navigation items and title from the view controller disregarded, but more concerningly, my tab bar item title is set to nil. This renders it impossible for me to utilize SwiftUI within my application when I wish to present older UIKit view controllers from there. This feedback has all the details and a sample project. FB18956999

For over five years, this persistent issue has affected all platforms, and despite submitting numerous feedback reports, my concerns have remained unaddressed. When utilizing a UIHostingController within a UINavigationController, the toolbar items and title defined in the SwiftUI view manifest with a substantial delay. This delay is particularly noticeable with the introduction of Liquid Glass, resulting in a jarring transition. Although I had nearly lost hope, the issue was resolved in iOS 26 beta 3 when the push occurs from within a UISplitViewController. However, the problem persists outside of this context. Ultimately, this issue hinders my ability to develop high-quality applications and restricts my use of SwiftUI within my UIKit project for similar purposes. I sincerely hope that this issue can be resolved, enabling me to fully rely on SwiftUI in my project. Please prioritize this matter and make the necessary changes that were already made in UISplitViewController. This feedback has all the details and a sample project. FB14000542 Before the push: During the push: A second after the push finishes:

H there! I'm new to mergeable libraries, so sorry if I missed anything obvious. We have some really huge projects with mergeable libraries that started failing to build with Xcode 26 beta 3. After doing some research I managed to create a very small project where I was able to reproduce the issues. The project just contains a SwiftUI app and a framework. The framework includes just a class that is used from a SwiftUI view included in the app. Problems I found the following: Default configuration (no mergeable libraries) Everything works as expected Automatic mergeable libraries In this case I just set Create Merged Binary to Automatic. In this case: the application can be properly built and run in the simulator the SwiftUI preview stops working with the following report: == PREVIEW UPDATE ERROR: FailedToAnalyzeBuiltTargetDescription: Could not analyze the built target description for MLibTestCase to create the preview. buildableName: MLibTestCase ================================== | UnrecognizedLinkerArguments: Unrecognized linker arguments | | arguments: -no_merge_framework | Manual mergeable libraries In this case I set: Create Merged Binary to Automatic in the app target Build Mergeable Library to Yes in the library target and I get exactly the same result as above. But if in addition I set: MAKE_MERGEABLE to YES as a User-Defined setting in the library target now things gets really worse, as: linking no longer works, failing with the following error: duplicate symbol '_relinkableLibraryClassesCount' in: [...]/Build/Products/Debug-iphonesimulator/MLib.framework/MLib bundle-file duplicate symbol '_relinkableLibraryClasses' in: [...]/Build/Products/Debug-iphonesimulator/MLib.framework/MLib bundle-file ld: 2 duplicate symbols the SwiftUI preview fails, but now due to the error mentioned above: == PREVIEW UPDATE ERROR: SchemeBuildError: Failed to build the scheme “MLibTestCase” linker command failed with exit code 1 (use -v to see invocation) Conclusions, thoughts and doubts After watching the WWDC session on mergeable libraries and reading the corresponding Apple documentation I got the feeling that Xcode would automatically manage mergeable libraries in both Debug and Release configurations, doing different things, but after performing this experiment with Xcode 26 beta 3 I'm no longer convinced that this is the case. Anyway, our projects seemed to be working properly until Xcode 26 beta 2, using the last mentioned settings, this is, manual merged binary, with frameworks including the build mergeable library and MAKE_MERGEABLE settings. In addition, the symbols causing the duplication error seem to be synthesized by the linker in the case of mergeable libraries, so it's weird to get this error related with something that the linker is supposed to manage automatically. And don't forget that Unrecognized linker argument... So: Has Xcode 26 beta 3 changed the way mergeable libraries are treated and configured, or is this a bug? In case this is not a bug, are we now supposed to provide different settings for Debug and Release builds? (I could create a merged binary only in the Release configuration, but again, we didn't have to do this before this Xcode version)

Hello there! I've been struggline with this thing for a two days now, and seems like it's a bug in SwiftUI. Navigation title is jumping on top of the ScrollView's content when switching tabs in TabView. Steps to reproduce: Scroll one tab to the bottom so that the large title is hidden and the floating toolbar appears. Go to another tab in the tab bar. Go back to the initial tab (it is still scrolled), and press the current tab button again to scroll to the top. The navigation title will glitch and be on top of the content. The animation fixes if you scroll again manually. Video: https://share.cleanshot.com/PFCSKMlH Code (simplified): import SwiftData import SwiftUI @main struct MyApp: App { var body: some Scene { WindowGroup { TabsContentView() } } } // ... struct TabsContentView: View { enum Tab { case library, profile } @State private var selectedTab: Tab = .library var body: some View { TabView(selection: $selectedTab) { NavigationStack { YourLibraryList() .navigationTitle("Your Library") } .tabItem { Label("Library", systemImage: "tray.fill") } .tag(Tab.library) NavigationStack { VStack { Spacer() Text("Profile") .font(.largeTitle) .foregroundColor(Color.theme.text) Text("Manage your account and preferences here") .font(.body) .foregroundColor(Color.theme.mutedForeground) .multilineTextAlignment(.center) .padding(.horizontal) Spacer() } .navigationTitle("Explore") } .tabItem { Label("Profile", systemImage: "person.fill") } .tag(Tab.profile) } .toolbarBackground(.ultraThinMaterial, for: .tabBar) .toolbarBackground(.visible, for: .tabBar) } } // ... struct YourLibraryList: View { var body: some View { ScrollView { VStack(spacing: 12) { ForEach(1 ... 20, id: \.self) { number in RoundedRectangle(cornerRadius: 12) .fill(Color.blue.opacity(0.1)) .stroke(Color.blue, lineWidth: 1) .frame(height: 60) .overlay( Text("\(number)") .font(.title2) .fontWeight(.semibold) .foregroundColor(.blue) ) } } .padding(.horizontal) } } }

Hello! I am trying to create an iOS app that is based around a very large, vertically scrolling text view. The text is broken up into many sections, and the user should be able to press buttons in the navigation, which programmatically scroll to those sections. The user can also change the font size in a settings menu. It should generally keep the user's spot when resizing fonts or rotating the screen (from portrait to landscape). The problem I've been having is that no method of lazy text loading allows accurate enough navigation, and the text is too long to calculate the whole UI all at once. Here's my process in trying to find a solution: My app is built in SwiftUI, so I started with a ScrollView and a LazyVStack, and I used .scrollPosition() and bound it to an Int?. It worked pretty well for most scroll locations both on screen and far off the screen, but when I programmatically scroll to a location that is off the screen but not very far off, it completely misses. So, I investigated UIKit, and found that UITextView was a much better fit for the way I wanted to present the long text. I could also programmatically navigate by storing the NSRange of each section. I tried to use scrollRangeToVisible(), but for long distance it would scroll so that the desired section was just below the viewport and thus off screen. Then I tried to use UITextView's textLayoutManager.textViewportLayoutController.relocateViewport() to send it to the correct NSTextRange, it would not jump all the way, but instead would do nothing until I tried to scroll again and it would jump slightly forward. I tried to use textViewportLayoutController.layoutViewport() after the jump, and that fixed the glitch when scrolling, but it still did not jump to the correct place, only slightly forward. Then, I looked into TextKit 2 and the way it worked to try to find a solution. From what I can tell, it seems that to affect the NSTextViewportLayoutController without having to rewrite it, I need an NSTextViewportLayoutControllerDelegate, but the delegate required me to manually lay out the views, and in all the examples I've seen that use a custom NSTextViewportLayoutControllerDelegate, they wrote their own custom text view instead of using the default UITextView. I started looking into writing a custom text view so I can get the programmatic scroll to work consistently. However, it felt like, from a maintainability standpoint, it would probably be best to stick with what Apple has already implemented. For now, I found a workaround that scrolls consistently. Here is the code: if let start = self.textView.position(from: self.textView.beginningOfDocument, offset: desiredLineRange.location) { let location = textView.caretRect(for: start) self.textView.setContentOffset(CGPoint(x: 0, y: location.origin.y), animated: false) } if let start = self.textView.position(from: self.textView.beginningOfDocument, offset: desiredLineRange.location) { let location = textView.caretRect(for: start) self.textView.setContentOffset(CGPoint(x: 0, y: location.origin.y), animated: false) } It does the job, because the first time it gets close enough, and the second time it gets to the precise location, but it just feels like a bit of a hack to run the same code twice. I was wondering if anyone knows what I could be doing wrong and if Apple provides any solutions for this? (Also, all my UIKit navigation attempts ran inside an @objc func, which I passed using button.addTarget(self, action: #selector(buttonTapped), for: .touchUpInside). Just so you know in case it may be a problem with the way Swift and UIKit handle concurrency/parallel tasks). Thank you!

I'm running into an issue in Xcode when working on a visionOS app. Whenever I try to drag a 3D model entity in my scene, the drag gesture doesn't work if there's a UITextView (or SwiftUI TextEditor) in background of the 3D entity. It seems like the UITextView is intercepting the gesture or preventing the drag interaction from reaching the 3D content. Interestingly, when the 3D entity is placed infront of the ScrollView, the drag works as expected. Has anyone else experienced this behavior? Is this a known limitation or a bug in the current tooling? Any workarounds or fixes would be appreciated. Thanks!

Experiencing 100% CPU usage in SwiftUI app using UIHostingController, only on iOS 26 beta and Xcode beta. Issue involves excessive view updates in AttributeGraph propagation. Stack trace (main thread): thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP frame #0: 0x00000001c38b9aa4 AttributeGraph`AG::Graph::propagate_dirty(AG::AttributeID) + 416 frame #1: 0x00000001d9a743ec SwiftUICore`SwiftUI.ObservationGraphMutation.apply() -> () + 656 frame #2: 0x00000001d97c0d4c SwiftUICore`function signature specialization <Arg[2] = [Closure Propagated : closure #1 () -> () in SwiftUI.(AsyncTransaction in _F9F204BD2F8DB167A76F17F3FB1B3335).apply() -> (), Argument Types : [SwiftUI.AsyncTransaction]> of generic specialization <()> of closure #1 () throws -> τ_0_0 in SwiftUI.withTransaction<τ_0_0>(SwiftUI.Transaction, () throws -> τ_0_0) throws -> τ_0_0 + 336 frame #3: 0x00000001d9a6ac80 SwiftUICore`merged function signature specialization <Arg[3] = Owned To Guaranteed> of function signature specialization <Arg[1] = [Closure Propagated : implicit closure #2 () -> () in implicit closure #1 @Sendable (SwiftUI.(AsyncTransaction in _F9F204BD2F8DB167A76F17F3FB1B3335)) -> () -> () in SwiftUI.GraphHost.flushTransactions() -> (), Argument Types : [SwiftUI.AsyncTransaction]> of SwiftUI.GraphHost.runTransaction(_: Swift.Optional<SwiftUI.Transaction>, do: () -> (), id: Swift.Optional<Swift.UInt32>) -> () + 196 frame #4: 0x00000001d9a52ab0 SwiftUICore`SwiftUI.GraphHost.flushTransactions() -> () + 176 frame #5: 0x00000001d8461aac SwiftUI`closure #1 (SwiftUI.GraphHost) -> () in SwiftUI._UIHostingView._renderForTest(interval: Swift.Double) -> () + 20 frame #6: 0x00000001d9bf3b38 SwiftUICore`partial apply forwarder for closure #1 (SwiftUI.ViewGraph) -> τ_1_0 in SwiftUI.ViewGraphRootValueUpdater.updateGraph<τ_0_0>(body: (SwiftUI.GraphHost) -> τ_1_0) -> τ_1_0 + 20 frame #7: 0x00000001d9e16dc4 SwiftUICore`SwiftUI.ViewGraphRootValueUpdater._updateViewGraph<τ_0_0>(body: (SwiftUI.ViewGraph) -> τ_1_0) -> Swift.Optional<τ_1_0> + 200 frame #8: 0x00000001d9e1546c SwiftUICore`SwiftUI.ViewGraphRootValueUpdater.updateGraph<τ_0_0>(body: (SwiftUI.GraphHost) -> τ_1_0) -> τ_1_0 + 136 frame #9: 0x00000001d8461a7c SwiftUI`closure #1 () -> () in closure #1 () -> () in closure #1 () -> () in SwiftUI._UIHostingView.beginTransaction() -> () + 144 frame #10: 0x00000001d846aed0 SwiftUI`partial apply forwarder for closure #1 () -> () in closure #1 () -> () in closure #1 () -> () in SwiftUI._UIHostingView.beginTransaction() -> () + 20 frame #11: 0x00000001d984f814 SwiftUICore`closure #1 () throws -> τ_0_0 in static SwiftUI.Update.ensure<τ_0_0>(() throws -> τ_0_0) throws -> τ_0_0 + 48 frame #12: 0x00000001d984e114 SwiftUICore`static SwiftUI.Update.ensure<τ_0_0>(() throws -> τ_0_0) throws -> τ_0_0 + 96 frame #13: 0x00000001d846aeac SwiftUI`partial apply forwarder for closure #1 () -> () in closure #1 () -> () in SwiftUI._UIHostingView.beginTransaction() -> () + 64 frame #14: 0x00000001851eab1c UIKitCore`___lldb_unnamed_symbol311742 + 20 * frame #15: 0x00000001852b56a8 UIKitCore`___lldb_unnamed_symbol315200 + 44 frame #16: 0x0000000185175120 UIKitCore`___lldb_unnamed_symbol308851 + 20 frame #17: 0x00000001d984e920 SwiftUICore`static SwiftUI.Update.dispatchImmediately<τ_0_0>(reason: Swift.Optional<SwiftUI.CustomEventTrace.ActionEventType.Reason>, _: () -> τ_0_0) -> τ_0_0 + 300 frame #18: 0x00000001d95a7428 SwiftUICore`static SwiftUI.ViewGraphHostUpdate.dispatchImmediately<τ_0_0>(() -> τ_0_0) -> τ_0_0 + 40 frame #19: 0x00000001852b59dc UIKitCore`___lldb_unnamed_symbol315204 + 192 frame #20: 0x00000001852b54a4 UIKitCore`___lldb_unnamed_symbol315199 + 64 frame #21: 0x0000000185745dd4 UIKitCore`_UIUpdateSequenceRunNext + 120 frame #22: 0x0000000186144fac UIKitCore`schedulerStepScheduledMainSectionContinue + 56 frame #23: 0x00000002505ad150 UpdateCycle`UC::DriverCore::continueProcessing() + 36 frame #24: 0x0000000180445b20 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24 frame #25: 0x0000000180445a68 CoreFoundation`__CFRunLoopDoSource0 + 168 frame #26: 0x00000001804451f4 CoreFoundation`__CFRunLoopDoSources0 + 220 frame #27: 0x00000001804443a8 CoreFoundation`__CFRunLoopRun + 756 frame #28: 0x000000018043f458 CoreFoundation`_CFRunLoopRunSpecificWithOptions + 496 frame #29: 0x00000001928d19bc GraphicsServices`GSEventRunModal + 116 frame #30: 0x0000000186224480 UIKitCore`-[UIApplication _run] + 772 frame #31: 0x0000000186228650 UIKitCore`UIApplicationMain + 124 frame #32: 0x000000010bb1b504 MyApp.debug.dylib`main at main.swift:13:1 frame #33: 0x00000001043813d0 dyld_sim`start_sim + 20 frame #34: 0x000000010468ab98 dyld`start + 6076 Used let _ = Self.printChanges() in my SwiftUI View and got infinite changes of \_UICornerProvider.<computed 0x000000018527ffd8 (Optional<UICoordinateSpace>)> changed. Reproduces only on beta; works on stable iOS. Likely beta-specific bug in SwiftUI rendering.

Hi everyone, I've noticed a significant change in the visual behavior of List section headers between iOS 18 and iOS 26 beta that I'd like to clarify. Current Behavior: iOS 18 and earlier: Section headers with .listStyle(.plain) display with a translucent material background (regular material with blur effect) when pinned to the top during scrolling iOS 26 beta: Section headers with .listStyle(.plain) appear with a transparent/clear background even when pinned to the top Sample Code: struct ContentView: View { var body: some View { NavigationStack { List(1 ..< 5) { headerIndex in Section { ForEach(1...5, id: \.self) { rowIndex in HStack { Text("Row \(rowIndex)") .frame(height: 40) .padding(.horizontal) .background(Color.blue) Spacer() Image(systemName: "chevron.right") .foregroundStyle(.secondary) .font(.title3) } } } header: { Text("Header \(headerIndex)") .frame(height: 44) } .listRowSeparator(.hidden) } .listStyle(.plain) .clipped() } } } Questions: Is this change in header background behavior for .plain list style intentional in iOS 26? If so, what's the recommended way to maintain the previous material background appearance when headers are pinned? Should this be filed as feedback if it's unintended behavior? Testing Environment: Xcode 26.0 beta 3 (17A5276g) iOS 26 beta (23A5287g) vs iOS 18.5 Tested on simulator The translucent header background when pinned was quite useful for maintaining readability over scrolling content, so I'm hoping to understand if this is the new expected behavior or if there's a way to preserve the previous appearance. Any insights would be greatly appreciated! iOS 18.5 iOS 26 Beta

What are the SwiftUI equivalent of NSSplitViewController.automaticallyAdjustsSafeAreaInsets NSToolbarItem.style These were introduced in the WWDC 2025 session named "Build an AppKit app with the new design". Jeff introduced only the AppKit API's while there was no mention of SwiftUI API

I am trying to create a menu picker for two or three text items. Small miracles, but I have it basically working. Problem is it uses a set, and I want to pass arrays. I need to modify PickerView so the Bound Parameter is an [String] instead of Set. Have been fighting this for a while now... Hoping for insights. struct PickerView: View { @Binding var colorChoices: Set<String> let defaults = UserDefaults.standard var body: some View { let possibleColors = defaults.object(forKey: "ColorChoices") as? [String] ?? [String]() Menu { ForEach(possibleColors, id: \.self) { item in Button(action: { if colorChoices.contains(item) { colorChoices.remove(item) } else { colorChoices.insert(item) } }) { HStack { Text(item) Spacer() if colorChoices.contains(item) { Image(systemName: "checkmark") } } } } } label: { Label("Select Items", systemImage: "ellipsis.circle") } Text("Selected Colors: \(colorChoices, format: .list(type: .and))") } } #Preview("empty") { @Previewable @State var colorChoices: Set<String> = [] PickerView(colorChoices: $colorChoices) } #Preview("Prefilled") { @Previewable @State var colorChoices: Set<String> = ["Red","Blue"] PickerView(colorChoices: $colorChoices) } My Content View is suppose to set default values the first time it runs, if no values already exist... import SwiftUI struct ContentView: View { @State private var viewDidLoad: Bool = false var body: some View { HomeView() .onAppear { // The following code should execute once the first time contentview loads. If a user navigates back to it, it should not execute a second time. if viewDidLoad == false { viewDidLoad = true // load user defaults let defaults = UserDefaults.standard // set the default list of school colors, unless the user has already updated it prior let defaultColorChoices: [String] = ["Black","Gold","Blue","Red","Green","White"] let colorChoices = defaults.object(forKey: "ColorChoices") as? [String] ?? defaultColorChoices defaults.set(colorChoices, forKey: "ColorChoices") } } } } #Preview { ContentView() } PickLoader allows you to dynamically add or delete choices from the list... import SwiftUI struct PickLoader: View { @State private var newColor: String = "" var body: some View { Form { Section("Active Color Choices") { // we should have set a default color list in contentview, so empty string should not be possible. let defaults = UserDefaults.standard let colorChoices = defaults.object(forKey: "ColorChoices") as? [String] ?? [String]() List { ForEach(colorChoices, id: \.self) { color in Text(color) } .onDelete(perform: delete) HStack { TextField("Add a color", text: $newColor) Button("Add"){ defaults.set(colorChoices + [newColor], forKey: "ColorChoices") newColor = "" } } } } } .navigationTitle("Load Picker") Button("Reset Default Choices") { let defaults = UserDefaults.standard //UserDefaults.standard.removeObject(forKey: "ColorChoices") let colorChoices: [String] = ["Black","Gold","Blue","Red","Green","White"] defaults.set(colorChoices, forKey: "ColorChoices") } Button("Clear all choices") { let defaults = UserDefaults.standard defaults.removeObject(forKey: "ColorChoices") } } } func delete(at offsets: IndexSet) { let defaults = UserDefaults.standard var colorChoices = defaults.object(forKey: "ColorChoices") as? [String] ?? [String]() colorChoices.remove(atOffsets: offsets) defaults.set(colorChoices, forKey: "ColorChoices") } #Preview { PickLoader() } And finally HomeView is where I am testing from - to see if binding works properly... import SwiftUI struct HomeView: View { //@State private var selection: Set<String> = [] //@State private var selection: Set<String> = ["Blue"] @State private var selection: Set<String> = ["Blue", "Red"] var body: some View { NavigationStack { List { Section("Edit Picker") { NavigationLink("Load Picker") { PickLoader() } } Section("Test Picker") { PickerView(colorChoices: $selection) } Section("Current Results") { Text("Current Selection: \(selection, format: .list(type: .and))") } } .navigationBarTitle("Hello, World!") } } } #Preview { HomeView() } If anyone uses this code, there are still issues - buttons on Loader don't update the list on the screen for one, and also dealing with deleting choices that are in use - how does picker deal with them? Probably simply add to the list automatically and move on. If anyone has insights on any of this also, great! but first I just need to understand how to accept an array instead of a set in pickerView. I have tried using a computed value with a get and set, but I can't seem to get it right. Thanks for any assistance! Cheers!

Hello! I’m excited to see that Look to Scroll has been included in visionOS 26 Beta. I’m aiming to achieve a feature where the user’s gaze at a specific edge automatically scrolls to that position. However, I’ve experimented with ScrollView and haven’t been able to trigger this functionality. Could you advise if additional API modifiers are necessary? Thank you!

"/Users/rich/Work/IdeaBlitz/IdeaBlitz/IdeaListView.swift:30:25 The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions" Is it just me? I get this on syntax errors, missing commas, missing quotes, and for no particular reason at all that I can see. I don't think I've been able to write a single, simple, SwiftUI view without seeing this multiple times. "Breaking it up" just makes it harder to read. Simple, inline, 2-page views become 8-page, totally unreadable, monstrosities. Am I doing something wrong? Or is this just the state of SwiftUI today? Or is there some way to tell the compiler to take more time on this expression? I mean, if these can be broken up automatically, then why doesn't the compiler to that already?

Development environment: Simulator: iOS 26 beta 3 iPhone 16 (for testing) Simulator 2: iPadOS 26 beta 3 iPad Air 13 inch (M3) (for testing) Connected Device: iPadOS 26 beta 3 iPad Pro 11 inch (M4) (for testing) Dev Device: macOS Tahoe 26 beta 3 Macbook Air When using the NavigationSplitView element, the sidebar has a built-in panel toggle button. However, when I click the toggle button to toggle the sidebar section in SwiftUI 26 on both simulator 2 and the connected device, it has a slight animation glitch before going back to normal. What's going on? This is my code for the specific view that has the NavigationSplitView (and all views are connected through TabViews): RecordsPage.swift Here are image references: When I clicked the toggle: After 1~2 seconds: These images are in the state of the panel being hidden.

I am trying to get the new PresentationComponent working in VisionOS26 as seen in this WWDC video: https://developer.apple.com/videos/play/wwdc2025/274/?time=962 (18:29 minutes into video) Here is some other example code but it doesn't work either: https://stepinto.vision/devlogs/project-graveyard-devlog-002/ My simple Text view (that I am adding as a PresentationComponent) does not appear in my RealityView even though the entity is found. Here is a simple example built from an Xcode immersive view default project: struct ImmersiveView: View { @Environment(AppModel.self) var appModel var body: some View { RealityView { content in // Add the initial RealityKit content if let immersiveContentEntity = try? await Entity(named: "Immersive", in: realityKitContentBundle) { content.add(immersiveContentEntity) if let materializedImmersiveContentEntity = try? await Entity(named: "Test", in: realityKitContentBundle) { content.add(materializedImmersiveContentEntity) var presentation = PresentationComponent( configuration: .popover(arrowEdge: .bottom), content: Text("Hello, World!") .foregroundColor(.red) ) presentation.isPresented = true materializedImmersiveContentEntity.components.set(presentation) } } } } } Here is the Apple reference: https://developer.apple.com/documentation/realitykit/presentationcomponent

One of the most common ways to provide a window size in visionOS is to use the defaultSize scene modifier. WindowGroup(id: "someID") { SomeView() } .defaultSize(CGSize(width: 600, height: 600)) Starting in visionOS 26, using this has a side effect. visionOS 26 will restore windows that have been locked in place or snapped to surfaces. If a user has manually adjusted the size of a locked/snapped window, the users size is only restore in some cases. Manual resize respected Leaving a room and returning later Taking the headset off and putting it back on later Manual resize NOT respected Device restart. In this case, the window is reopened where it was locked, but the size is set back to the values passed to defaultSize. The manual resizing adjustments the user has made are lost. This is counter to how all other windows and widgets work. I reported this last month (FB18429638), but haven't heard back if this is a bug or intended behavior. Questions What is the best way to provide a default window size that will only be used when opening new windows–and not used during scene restoration? Should we try to keep track of window size after users adjust them and save that somewhere? If this is intended behavior, can someone please update the docs accordingly?