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 UI Frameworks. How would you recommend developers start adopting the new design? Start by focusing on the foundational structural elements of your application, working from the "top down" or "bottom up" based on your application's hierarchy. These structural changes, like edge-to-edge content and updated navigation and controls, often require corresponding code modifications. As a first step, recompile your application with the new SDK to see what updates are automatically applied, especially if you've been using standard controls. Then, carefully analyze where the new design elements can be applied to your UI, paying particular attention to custom controls or UI that could benefit from a refresh. Address the large structural items first then focus on smaller details is recommended. Will we need to migrate our UI code to Swift and SwiftUI to adopt the new design? No, you will not need to migrate your UI code to Swift and SwiftUI to adopt the new design. The UI frameworks fully support the new design, allowing you to migrate your app with as little effort as possible, especially if you've been using standard controls. The goal is to make it easy to adopt the new design, regardless of your current UI framework, to achieve a cohesive look across the operating system. What was the reason for choosing Liquid Glass over frosted glass, as used in visionOS? The choice of Liquid Glass was driven by the desire to bring content to life. The see-through nature of Liquid Glass enhances this effect. The appearance of Liquid Glass adapts based on its size; larger glass elements look more frosted, which aligns with the design of visionOS, where everything feels larger and benefits from the frosted look. What are best practices for apps that use customized navigation bars? The new design emphasizes behavior and transitions as much as static appearance. Consider whether you truly need a custom navigation bar, or if the system-provided controls can meet your needs. Explore new APIs for subtitles and custom views in navigation bars, designed to support common use cases. If you still require a custom solution, ensure you're respecting safe areas using APIs like SwiftUI's safeAreaInset. When working with Liquid Glass, group related buttons in shared containers to maintain design consistency. Finally, mark glass containers as interactive. For branding, instead of coloring the navigation bar directly, consider incorporating branding colors into the content area behind the Liquid Glass controls. This creates a dynamic effect where the color is visible through the glass and moves with the content as the user scrolls. I want to know why new UI Framework APIs aren’t backward compatible, specifically in SwiftUI? It leads to code with lots of if-else statements. Existing APIs have been updated to work with the new design where possible, ensuring that apps using those APIs will adopt the new design and function on both older and newer operating systems. However, new APIs often depend on deep integration across the framework and graphics stack, making backward compatibility impractical. When using these new APIs, it's important to consider how they fit within the context of the latest OS. The use of if-else statements allows you to maintain compatibility with older systems while taking full advantage of the new APIs and design features on newer systems. If you are using new APIs, it likely means you are implementing something very specific to the new design language. Using conditional code allows you to intentionally create different code paths for the new design versus older operating systems. Prefer to use if #available where appropriate to intentionally adopt new design elements. Are there any Liquid Glass materials in iOS or macOS that are only available as part of dedicated components? Or are all those materials available through new UIKit and AppKit views? Yes, some variations of the Liquid Glass material are exclusively available through dedicated components like sliders, segmented controls, and tab bars. However, the "regular" and "clear" glass materials should satisfy most application requirements. If you encounter situations where these options are insufficient, please file feedback. If I were to create an app today, how should I design it to make it future proof using Liquid Glass? The best approach to future-proof your app is to utilize standard system controls and design your UI to align with the standard system look and feel. Using the framework-provided declarative API generally leads to easier adoption of future design changes, as you're expressing intent rather than specifying pixel-perfect visuals. Pay close attention to the design sessions offered this year, which cover the design motivation behind the Liquid Glass material and best practices for its use. Is it possible to implement your own sidebar on macOS without NSSplitViewController, but still provide the Liquid Glass appearance? While technically possible to create a custom sidebar that approximates the Liquid Glass appearance without using NSSplitViewController, it is not recommended. The system implementation of the sidebar involves significant unseen complexity, including interlayering with scroll edge effects and fullscreen behaviors. NSSplitViewController provides the necessary level of abstraction for the framework to handle these details correctly. Regarding the SceneDelagate and scene based life-cycle, I would like to confirm that AppDelegate is not going away. Also if the above is a correct understanding, is there any advice as to what should, and should not, be moved to the SceneDelegate? UIApplicationDelegate is not going away and still serves a purpose for application-level interactions with the system and managing scenes at a higher level. Move code related to your app's scene or UI into the UISceneDelegate. Remember that adopting scenes doesn't necessarily mean supporting multiple scenes; an app can be scene-based but still support only one scene. Refer to the tech note Migrating to the UIKit scene-based life cycle and the Make your UIKit app more flexible WWDC25 session for more information.

Here’s a recap of the Live Q&A for SwiftUI foundations: Build great apps with SwiftUI. If you participated and asked questions, thank you for coming and participating! If you weren’t able to join us live we hope this recap is useful Where can I watch the VOD? Is the sample code “Wishlist” that was shown available for download? You can view the replay of the entire event here https://www.youtube.com/watch?v=Z3vloOtZLkQ The sample code for the Wishlist app will be made available in the coming weeks on the Apple Developer website, we'll send an update via email when it is available. What are the best practices when it comes to building complex navigations in SwiftUI? The developer website has documentation on navigation style best practices. Explore navigation basics like NavigationStack and TabView to get a ground-up understanding. For documentation on navigation APIs see Navigation. How can I integrate UIKit with my SwiftUI app? What about adding SwiftUI into my UIKit app? See UIKit integration: Add UIKit views to your SwiftUI app, or use SwiftUI views in your UIKit app. Both UIKit and SwiftUI provide API to show a view hierarchy of the other. For UIKit to SwiftUI, you would use UIViewControllerRepresentable. For SwiftUI to UIKit, you would use UIHostingController. Landmarks: Interfacing with UIKit walks you through step by step how to implement UIKit in SwiftUI with UIViewControllerRepresentable, and this WWDC22 video demonstrates UIHostingController, for those that want to add SwiftUI to their UIKit. Does Wishlist feature a new iOS 26 font? How can I add custom fonts and text of my app? We’re glad to hear many of you liked wide text shown in Wishlist, however, It is the default system font with some light SwiftUI styling! Check it out for yourself in the sample code when made available, and you can learn more about customizing fonts and text by seeing Font and Applying custom fonts to text. Does Xcode have a dependency graph we can use to optimize our SwiftUI Views? Xcode comes with Instruments. Instruments is the best way to figure out what is causing excessive updates and other issues with performance. That link provides direct tutorials and resources for how to use and understand. Previews also have many useful tools for analyzing SwiftUI views, for more info see Previews in Xcode Check out this video from our latest WWDC Optimize SwiftUI performance with Instruments for information on how to use Instruments to profile and optimize your app with real-world applications If you still have questions, Check out the Instruments section of these forums and create a post so the community has the opportunity to help guide you. Are there UI debugging tools to help diagnose layout issues? Yes, Xcode also features a View Debugger located by selecting the View Debug Hierarchy, pictured below. Use the View Debugger to capture and inspect your view hierarchy, identifying which views affect window sizing. The SwiftUI Inspector also lets you examine view frames and layout behavior. See Diagnosing issues in the appearance of a running app to learn about debugging visual and layout issues. As an absolute beginner, what would be the first go-to step to go for training? Do I need prior knowledge of frameworks to get started with SwiftUI? A great place to learn how to develop for Apple platforms is with Pathways! Many developers start with Develop in Swift tutorials, which exposes you to several frameworks while teaching you the basics of SwiftUI. When you're ready to take your learning further, you can read the documentation for the specific frameworks that interest you at https://developer.apple.com/documentation/.

Hello everyone, The setup: I have an iPadOS app. The app does not require full screen (Requires full screen option is disabled). The problem: The app starts looking unpolished when the canvas becomes too small. What I tried: I am trying to limit the canvas size for our app when run in Stage Manager. How: I saw that UIWindowScene has sizeRestrictions. This property is not always set as per documentation: https://developer.apple.com/documentation/uikit/uiwindowscene/sizerestrictions From my experiments, it only works when it's run on MacOS (in compatibility mode in our case). Console logs: Stage Manager - Requires full screen - OFF willConnectToSession - sizeRestrictions: nil sceneDidBecomeActive - sizeRestrictions: nil Stage Manager - Requires full screen - ON willConnectToSession - sizeRestrictions: nil sceneDidBecomeActive - sizeRestrictions: nil Stage Manager - Requires full screen - OFF - RUN on MacOS willConnectToSession - sizeRestrictions: Available sceneDidBecomeActive - sizeRestrictions: Available Question: Is there a way to enforce this minimum canvas size?

Hello, In my SwiftUI App i'm trying to create a custom UI trait and a matching bridged SwiftUI environment key. I want to override the environment key in a swift view and then have that reflect in the current UITraitCollection. I'm following the pattern in the linked video but am not seeing the changes reflect in the current trait collection when I update the swift env value. I can't find anything online that is helping. Does anyone know what I am missing? https://developer.apple.com/videos/play/wwdc2023/10057/ // Setup enum CustomTheme: String, Codable { case theme1 = “theme1”, theme2 = “theme2” } struct customThemeTrait: UITraitDefinition { static let defaultValue = brand.theme1 static let affectsColorAppearance = true static let identifier = "com.appName.customTheme" } extension UITraitCollection { var customTheme: CustomTheme { self[customThemeTrait.self] } } extension UIMutableTraits { var customTheme: CustomTheme { get { self[customThemeTrait.self] } set { self[customThemeTrait.self] = newValue } } } private struct customThemeKey: EnvironmentKey { static let defaultValue: CustomTheme = .theme1 } extension customThemeKey: UITraitBridgedEnvironmentKey { static func read(from traitCollection: UITraitCollection) -> CustomTheme { traitCollection.customTheme } static func write(to mutableTraits: inout UIMutableTraits, value: CustomTheme) { mutableTraits.customTheme = value } } extension EnvironmentValues { var customTheme: CustomTheme { get { self[customThemeKey.self] } set { self[customThemeKey.self] = newValue } } } // Attempted Usage extension Color { static func primaryBackground() -> Color { UITraitCollection.current.customTheme == .theme1 ? Color.red : Color.blue } } struct ContentView: View { @State private var theme = .theme1 var body: some View { if (dataHasLoaded && themeIsSet) { HomeView() .environment(\.customTheme, theme) } else { SelectThemeView( theme: self.theme, setContentThemeHandler) } } func setContentThemeHandler(theme: customTheme) { self.theme = theme } } struct HomeView() { @Environment(\.customTheme) private var currentTheme: customTheme var body: some View { VStack { Text("currentTheme: \(currentTheme.rawValue)") .background(Color.primaryBackground()) Text("currentUITrait: \(UITraitCollection.current.customTheme.rawValue)") .background(Color.primaryBackground()) } } } OUTCOME: After selecting theme2 in the theme selector view and navigating to the homeView, the background is still red and the env and trait values print the following: currentTheme: theme2 currentUITrait: theme1 Can anyone help me identify what I am missing?

When a parent view is selected for the detail pane of a NavigationSplitView subviews appear as expected but not with the dimensions set by .frame on the subview. Toggling the flag works as expected, appearing the subview with the idealWidth. I persist the flag in a SwiftData @Model class so that on restart and first appearance of the parent view the Right View subview presence is as it was left. The problem is that the .frame size is ignored, apparently. No manner of programatic view refresh seems to trigger a resize to the preferred values, only toggling the flag. Is there a better way to handle a collapsing subview in an HSplitView? Why is the .frame not respected? In this example I've added the else clause so HSplitView always has two views with .frame settings but the result is the same without it. VStack { HSplitView { VStack { Text("left view") } .frame( minWidth: 100, idealWidth: .infinity, maxWidth: .infinity, maxHeight: .infinity ) if documentSettings.nwIsPieChartShowing { VStack { Text("right view") } .frame( minWidth: 100, idealWidth: 200, maxWidth: .infinity, maxHeight: .infinity ) } else { Text("") .frame( minWidth: 0, idealWidth: 0, maxWidth: 0, maxHeight: .infinity ) } } HStack { Button("Right View", systemImage: { documentSettings.nwIsPieChartShowing ? "chart.pie.fill" : "chart.pie"}(), action: { documentSettings.nwIsPieChartShowing.toggle() } ) } } } } MacOS Sequoia 15.3.1, Xcode 16.2

import SwiftUI struct ContentView: View { var body: some View { VStack { Button ("Button 1") { print ("Button 1"); } .keyboardShortcut("k", modifiers: .command) Button ("Button 2") { print ("Button 2"); } .keyboardShortcut("k", modifiers: .command) } } } I the above snippet, I have assigned the same keyboard shortcut (cmd +k) to 2 different buttons. According to the docs, if multiple controls are associated with the same shortcut, the first one found is used. How do I figure out if Button 1 would be found first during the traversal or Button 2 ? Is it based on the order of declaration? Is it always the case that Button 1 would be found first since it was declared before Button 2 ?

I have found a system bug with UINavigationController, UIGestureRecognizerDelegate mainly the swipe back control. I have reproduced this in many apps, while some that use custom swipe back i can not reproduce, however any app using default uikit/swift transitions i can reproduce the flicker/previous screen flashing The Bug: a slight tap or series of quick taps anywhere on the screen (with the slightest (1-2pt -x)confuse the system into thinking its a swipe back gesture, however instead of pushing back to previous screen the UI flickers and flashes the previous screen. for a split second, very easy to reproduce. on screens with lots of options of boxes to tap it happens quite often. I have removed all custom "swipe back from anywhere" logic, all custom gesture logic, and can still reproduce by tapping the edge of the screen with only UINavigationController, UIGestureRecognizerDelegate in my navigation controller. Please let me know the best way to get in contact with someone at apple to either build an extension to prevent this flicker or if a developer has a fix but this is rarely talked about. (velocity limits etc do not work, and just make the gesture feel awful) all the developers i have reached out too have looked into this and have said "its an ios bug, only fix is build a custom swipe back from anywhere, or wait for apple to fix it).... as a small indie app, building my own seems daunting Recap: quick or taps with small x movement flash previous screen instead of pushing back or simply recognizing it as a tap and not flashing previous screen. this happens with no custom code default uikit/swift. Link me your app i can probably reproduce it, I have reproduced it in X(was hard), Retro(easy), and many more. The goal is to have a smooth native swipe/drag back from anywhere gesture while preventing flicking on fast taps or short taps with minor x movement. i have tried everything from setting limits to -x, velocity limits etc. nothing fixes this. happy hacking! PS i hope someone at apple calls me and i can explain this and we can fix it for every app in an update.

After my XCode was upgraded to 16.2, the custom bottom tabbar of iPadAPP could not be displayed properly (I set "traitOverrides.horizontalSizeClass = .compact", otherwise the tabbar would be displayed at the top and it was not the style I wanted) Below are my code and pictures of the running effects of iOS17 and iOS18 override func viewDidLoad() { super.viewDidLoad() setValue(CustomTabBar(), forKey: "tabBar") if #available(iOS 18.0, *) { self.mode = .tabBar self.traitOverrides.horizontalSizeClass = .compact } } } class CustomTabBar: UITabBar { var leftView = UIView() var rightView = UIView() override func sizeThatFits(_ size: CGSize) -> CGSize { var sizeThatFits = super.sizeThatFits(size) sizeThatFits.height = 60 // 自定义高度 return sizeThatFits } override func layoutSubviews() { super.layoutSubviews() self.backgroundColor = .red addSubview(leftView) addSubview(rightView) leftView.backgroundColor = .green leftView.frame = CGRect(x: 10, y: 4, width: 80, height: 40) rightView.backgroundColor = .green rightView.frame = CGRect(x: 600, y: 4, width: 80, height: 40) } } ![]("https://developer.apple.com/forums/content/attachment/66988297-26dc-4b40-af37-103f6a277563" "title=20250409151648.jpg;width=2394;height=1716")

I’m having a weird UIKit problem. I have a bunch of views in a UIScrollView and I add a UIContextMenuInteraction to all of them when the view is first loaded. Because they're in a scroll view, only some of the views are initially visible. The interaction works great for any of the views that are initially on-screen, but if I scroll to reveal new subviews, the context menu interaction has no effect for those. I used Xcode's View Debugger to confirm that my interaction is still saved in the view's interactions property, even for views that were initially off-screen and were then scrolled in. What could be happening here?

Hi, Im new to SwiftUI and Im trying to implement some drag and drop functionality for some tabs in my application. Im using .draggable(_) and .dropDestination for this and the issue I have is that as I drag the view, the mouse cursor changes to the copy cursor with the green plus sign and I don't like it but I can't figure out how to avoid it. Any help would be appreciated.

I have a scrollview displaying a sequence of circles, which a user should be able to scroll through to select an item. When the user stops scrolling and the animation comes to rest the circle selected should display screen-centered. I had hoped to achieve this using .scrollPosition(id: selectedItem, anchor: .center) but it appears that the anchor argument is ignored when scrolled manually. (BTW - I searched but didn't locate this aspect in the Apple documentation so I'm not confident that this observation is really correct). https://youtu.be/TpXDTuL5yPQ The video shows the user-scrolling behaviour, and also the snap-to-anchor that I would like to achieve, but I would like this WITHOUT forcing a button press. I could juggle the container size and size of the circles so that they naturally fit centered into the screen, but I would prefer a more elegant solution. How can I force the scrolling to come to rest such that the circle glides to rest in the center of the screen/container? struct ItemChooser: View { @State var selectedItem: Int? var body: some View { VStack { Text("You have picked: \(selectedItem ?? 0)") ScrollHorizontalItemChooser(selectedItem: $selectedItem) } } } #Preview { ItemChooser(selectedItem: 1) } struct ScrollHorizontalItemChooser: View { @Binding var selectedItem: Int? @State var scrollAlignment: UnitPoint? = .center let ballSize: CGFloat = 150 let items = Array(1...6) @State var scrollPosition: ScrollPosition = ScrollPosition() var body: some View { VStack { squareUpButton ScrollView(.horizontal) { HStack(spacing: 10) { showBalls } .scrollTargetLayout() } .scrollPosition(id: $selectedItem, anchor: scrollAlignment ) .overlay{ crosshairs } } } var crosshairs: some View { Image(systemName: "scope").scaleEffect(3.0).opacity(0.3) } @ViewBuilder var showBalls: some View { let screenWidth: CGFloat = UIScreen.main.bounds.width var emptySpace: CGFloat {screenWidth / 2 - ballSize / 2 - 10} Spacer(minLength: emptySpace) ForEach(items, id: \.self) { item in poolBall( item) .id(item) } Spacer(minLength: emptySpace) } @ViewBuilder private func poolBall(_ item: Int) -> some View { Text("Item \(item)") .background { Circle() .foregroundColor(Color.green) .frame(width: ballSize, height: ballSize) } .frame(width: ballSize, height: ballSize) } @ViewBuilder var squareUpButton: some View { var tempSelected: Int? = nil Button("Square up with Anchor") { tempSelected = selectedItem selectedItem = 0 DispatchQueue.main.asyncAfter(deadline: .now() + 0.1) { selectedItem = tempSelected ?? 0 } } } }

I am developing a macOS app using SwiftUI, and I am encountering an issue when launching the app at login. The app starts as expected, but the window does not appear automatically. Instead, it remains in the Dock, and the user must manually click the app icon to make the window appear. Additionally, I noticed that the timestamp obtained during the app's initialization (init) differs from the timestamp obtained in .onAppear. This suggests that .onAppear does not trigger until the user interacts with the app. However, I want .onAppear to execute automatically upon login. Steps to Reproduce Build the app and add it to System Settings > General > Login Items as an item that opens at login. Quit the app and restart the Mac. Log in to macOS. Observe that the app starts and appears in the Dock but does not create a window. Click the app icon in the Dock, and only then does the window appear. Expected Behavior The window should be created and appear automatically upon login without requiring user interaction. .onAppear should execute immediately when the app starts at login. Observed Behavior The app launches and is present in the Dock, but the window does not appear. .onAppear does not execute until the user manually clicks the app icon. A discrepancy exists between the timestamps obtained in init and .onAppear. Sample Code Here is a minimal example that reproduces the issue: LoginTestApp.swift import SwiftUI @main struct LoginTestApp: App { @State var date2: Date init(){ date2 = Date() } var body: some Scene { WindowGroup { MainView(date2: $date2) } } } MainView.swift import SwiftUI struct MainView: View { @State var date1: Date? @Binding var date2: Date var body: some View { Text("This is MainView") Text("MainView created: \(date1?.description ?? "")") .onAppear { date1 = Date() } Text("App initialized: \(date2.description)") } } Test Environment Book Pro 13-inch, M1, 2020 macOS Sequoia 15.2 Xcode 16.2 Questions Is this expected behavior in macOS Sequoia 15.2? How can I ensure that .onAppear executes automatically upon login? Is there an alternative approach to ensure the window is displayed without user interaction?

I have received permission from Apple to access SensorKit data for my app. I have granted all necessary permissions, but no data is being retrieved. The didCompleteFetch method is being called, but I’m unsure where to find event data like Device Usage and Ambient Light. Additionally, the didFetchResult method is never called. Could anyone please assist me in resolving this issue? Any guidance or troubleshooting steps would be greatly appreciated. import SensorKit class ViewController: UIViewController, SRSensorReaderDelegate { let store = SRSensorReader(sensor: .deviceUsageReport) override func viewDidLoad() { super.viewDidLoad() requestSensorAuthorization() } func requestSensorAuthorization() { var sensors: Set<SRSensor> = [ .accelerometer, .deviceUsageReport, .messagesUsageReport, .visits, .keyboardMetrics, .phoneUsageReport, .ambientLightSensor ] if #available(iOS 16.4, *) { sensors.insert(.mediaEvents) } SRSensorReader.requestAuthorization(sensors: sensors) { error in if let error = error { print("Authorization failed: \(error.localizedDescription)") } else { self.store.startRecording() self.requestSensorData() print("Authorization granted for requested sensors.") } } } func requestSensorData() { let fromTime = SRAbsoluteTime.fromCFAbsoluteTime(_cf: Date().addingTimeInterval(-60 * 60).timeIntervalSinceReferenceDate) let toTime = SRAbsoluteTime.fromCFAbsoluteTime(_cf: Date().timeIntervalSinceReferenceDate) let request = SRFetchRequest() request.from = fromTime request.to = toTime request.device = SRDevice.current store.fetch(request) store.delegate = self } func sensorReader(_ reader: SRSensorReader, didCompleteFetch fetchRequest: SRFetchRequest) { print("Fetch request completed: \(fetchRequest.from) to \(fetchRequest.to)") Task { do { let samples = try await reader.fetch(fetchRequest) print("Samples count: \(samples)") } catch { print("Error Fetching Data: \(error.localizedDescription)") } } } func sensorReader(_ reader: SRSensorReader, fetching fetchRequest: SRFetchRequest, didFetchResult result: SRFetchResult<AnyObject>) -> Bool { print(result) return true } }

I released an app for iPhone (and it's could be downloaded for iPad also), and now I developered another app for iPad version with the same code and logic but I modified the layout to fit bigger screen and make better user experience and appearance. Howevert the app review rejected my release due to the duplicate content, how can I solve it?

Does causing a swiftui view refresh via modifying observed properties while an alert is visible allowed? I am seeing a warning 'Presenting view controller <SwiftUI.PlatformAlertController> from detached view controller is not supported, and may result in incorrect safe area insets and a corrupt root presentation. Make sure <SwiftUI.PlatformAlertController> is in the view hierarchy before presenting from it. Will become a hard exception in a future release.' and the warning 'Attempt to present <SwiftUI.PlatformAlertController> on (from ) while a presentation is in progress'. The second warning occurs more often.

Hi, I’m practicing with NavigationSplitView for macOS and customizing the sidebar. I’ve managed to adjust most parts, but I couldn’t remove the sidebar’s divider. It seems like it’s not possible in modern SwiftUI. My AppKit knowledge is also not very strong. How can I remove the sidebar divider? I want to use a plain background. I also solved it by creating my own sidebar, but I wanted to try it using NavigationSplitView.

I am using SwiftUI to create an app and I have figured out how to present a scene for my preferences window. However I have yet to find a way to modify the "About "My App"" scene. I am not even sure how to ask the question on other forums because I keep getting informations on application menus. I would like to find information on accessing/changing other menu entries in the menubar (in SwiftUI) an most specifically I would like to find out how to present a custom window (or at least custom information) when the user selects "About "My App"" I guess I don't need a solution but a pointer to documentation that will help me in my quest.

I have the MainView as the active view if the user is logged in(authenticated). the memory allocations when we run profile is pretty good. We have graphql fetching, we have token handling eg: This is All heap: 1 All Heap & Anonymous VM 13,90 MiB 65408 308557 99,10 MiB 373965 Ratio: %0.14, %0.86 After what i have checked this is pretty good for initialise and using multiple repositories eg. But when we change tabs: 1 All Heap & Anonymous VM 24,60 MiB 124651 543832 156,17 MiB 668483 Ratio: %0.07, %0.40 And that is not pretty good. So i guess we need to "kill" it or something. How? I have tried some techniques in a forum this was a recommended way: public struct LazyView<Content: View>: View { private let build: () -> Content @State private var isVisible = false public init(_ build: @escaping () -> Content) { self.build = build } public var body: some View { build() Group { if isVisible { build() } else { Color.clear } } .onAppear { isVisible = true } .onDisappear { isVisible = false } } } But this did not help at all. So under here is the one i use now. So pleace guide me for making this work. import DIKit import CoreKit import PresentationKit import DomainKit public struct MainView: View { @Injected((any MainViewModelProtocol).self) private var viewModel private var selectedTabBinding: Binding<MainTab> { Binding( get: { viewModel.selectedTab }, set: { viewModel.selectTab($0) } ) } public init() { // No additional setup needed } public var body: some View { NavigationStack(path: Binding( get: { viewModel.navigationPath }, set: { _ in } )) { TabView(selection: selectedTabBinding) { LazyView { FeedTabView() } .tabItem { Label("Feed", systemImage: "house") } .tag(MainTab.feed) LazyView { ChatTabView() } .tabItem { Label("Chat", systemImage: "message") } .tag(MainTab.chat) LazyView { JobsTabView() } .tabItem { Label("Jobs", systemImage: "briefcase") } .tag(MainTab.jobs) LazyView { ProfileTabView() } .tabItem { Label("Profile", systemImage: "person") } .tag(MainTab.profile) } .accentColor(.primary) .navigationDestination(for: MainNavigationDestination.self) { destination in switch destination { case .profile(let userId): Text("Profile for \(userId)") case .settings: Text("Settings") case .jobDetails(let id): Text("Job details for \(id)") case .chatThread(let id): Text("Chat thread \(id)") } } } } } import SwiftUI public struct LazyView<Content: View>: View { private let build: () -> Content public init(_ build: @escaping () -> Content) { self.build = build } public var body: some View { build() } }

A NavigationStack with a singular enum for .navigationDestination() works fine. Both NavigationLinks(value:) and directly manipulating the NavigationPath work fine for moving around views. Zero problems. The issue is when we instead use a NavigationSplitView, I've only dabbled with two-column splits (sidebar and detail) so far. Now, if the sidebar has its own NavigationStack, everything works nicely on an iPhone, but on an iPad, you can't push views onto the detail from the sidebar. (They're pushed on the sidebar) You can solve this by keeping a NavigationStack ONLY on the detail. Sidebar links now properly push onto the detail, and the detail can move around views by itself. However, if you mix NavigationLink(value:) with manually changing NavigationPath, it stops working with no error. If you only use links, you're good, if you only change the NavigationPath you're good. Mixing doesn't work. No error in the console either, the breakpoints hit .navigationDestination and the view is returned, but never piled up. (Further attempts do show the NavigationPath is being changed properly, but views aren't changing) This problem didn't happen when just staying on NavigationStack without a NavigationSplitView. Why mix? There's a few reasons to do so. NavigationLinks put the appropriate disclosure indicator (can't replicate its look 100% without it), while NavigationPaths let you trigger navigation without user input (.onChange, etc) Any insights here? I'd put some code samples but there's a metric ton of options I've tested here.

The Problem Push buttons (created as a PDFAnnotation using PDFKit) do not properly write the associated caption's key-value pair (within the annotation's appearance characteristics dictionary) to a PDF document. What is Happening Push button widget annotations can have a caption that is displayed as the button’s label. In the PDF 1.7 specification (ISO PDF32000-2008, s. 12.5.6.19), a widget annotation can have an ‘appearance characteristics dictionary’ (MK) with properties to construct the appearance of the widget. The caption property (CA) is used to construct a button’s caption/label. PDFKit uses the PDFAnnotation .caption property to set the value of a push button’s caption as a string. Observation 1: In an open PDF document (using PDFView), a push button widget annotation can be created and added to a PDFPage using the following code: let pushButton = PDFAnnotation(bounds: pushButtonBounds, forType: .widget, withProperties: nil) pushButton.widgetFieldType = .button pushButton.widgetControlType = .pushButtonControl pushButton.caption = "My Button" page.addAnnotation(pushButton) The PDFAnnotation .caption property is used to set the caption to the required string. As a result, the push button is correctly displayed on the PDFPage with the correct label being display on the button. While the PDF document remains open, the appearance characteristics dictionary (an PDFAppearanceCharacteristics object) retains a key-value pair for the caption with the correct value as expected. On saving/writing to the PDF file, however, the key-value pair for the caption in the appearance characteristics dictionary is not written to the PDF document’s file. Resulting PDF markup: 6 0 obj << /Rect [ 256 299.8977 356 399.8977 ] /Border [ 0 0 0 ] /T (button23) /F 4 /Subtype /Widget /DA (/.AppleSystemUIFont 13 Tf 0 g) /MK 8 0 R /C [ 0 ] /AP 9 0 R /V /Off /M (D:20250330154918Z00'00') /FT /Btn /Type /Annot /Ff 65536 >> endobj 9 0 obj << /N 10 0 R >> endobj 8 0 obj << /BG [ 0.75 ] >> endobj 10 0 obj << /Filter /FlateDecode /Type /XObject /Subtype /Form /FormType 1 /BBox [0 0 100 100] /Resources 11 0 R /Length 170 >> stream x }ê1 Ç0 Öw~≈ ahÈ KÈ q1q0\‚`ú Ÿ¿ 8¯Ôm% u0óª‰.Ô{yπ åP°H-}ª‡à y3 ¸ %≠¡‰ %› g¨$•µMVXø‡Hé†Ö ”î“¿˜® BI•L ˆ†b A pü‰Ã @ÓpB∫ †æœs ãÙ:d8Éwÿr»/}” €∂I÷Bõ B;'+gm Ô˝„ mÙ~ L*>• endstream endobj On closing the PDF document, the assigned value for the push button’s caption is not written to the file and is lost. Observation 2: On reopening the PDF document, and assigning a new value for the already-created push button’s caption, a key-value pair for the caption is again correctly added to the PDFAnnotation appearance characteristics dictionary. On saving/writing to the PDF file, this time, the caption key-value pair in the appearance characteristics dictionary is correctly written/saved to the PDF document file. Resulting PDF markup: 6 0 obj << /Border [ 0 0 0 ] /Rect [ 256 299.8977 356 399.8977 ] /T (button23) /F 4 /BS 8 0 R /Subtype /Widget /DA (/.AppleSystemUIFont 13 Tf 0 g) /MK 9 0 R /C [ 0 ] /AP 10 0 R /V /Off /M (D:20250330154918Z00'00') /FT /Btn /Type /Annot /Ff 65536 >> endobj 10 0 obj << /N 11 0 R >> endobj 9 0 obj << /BG [ 0.75 ] /CA (My Button) >> endobj 8 0 obj << /W 0 >> endobj 11 0 obj << /Filter /FlateDecode /Type /XObject /Subtype /Form /FormType 1 /BBox [0 0 100 100] /Resources 12 0 R /Length 163 >> stream x uè1 ¬@ Ö˜˛ä7∂√]ì´◊Î≠ ¡A 8à”a∑Vj·ø˜jë™ !ÅÑ|y/=ˆËA1òʺ]pDá|=0¬“Œb ø+Õ gùf2E≤∞Ê≈N` û·Xm©-BãZ†H Ÿ ¿≈ºPÄ= Ø míãp •¡ ÈÓÅ˙>é “kó· Ÿb#—¬ Ûã¶2∂Ñ2fiΠ;óDÌiÓ?ü>LÁûÊy;} endstream endobj Impact on User Experience: Push button captions may not be properly saved to the PDF document’s file. This may result in an application redrawing a push button without a caption/label. More so, an application that uses the caption value to “read” a button’s label (e.g., for accessibility purposes) will not be able to do so.

Looking for a solution that keeps the presented view controller fullscreen. The background is that I need to take some screenshots of the presenting view controller while the modal is onscreen. It's a pretty messy operation and we don't want to distract and delay the user by doing it before the modal is presented.

I want to truncate text from head with max 2 lines. I try the following code import SwiftUI struct ContentView: View { @State var content: String = "Hello world! wef wefwwfe wfewe weweffwefwwfwe wfwe" var body: some View { VStack { Text(content) .lineLimit(nil) .truncationMode(.head) .frame(height: 50) Button { content += content } label: { Text("Double") } .buttonStyle(.borderedProminent) } .frame(width: 200, height: 1000) .padding() } } #Preview { ContentView() } It show result like this, this is not what I want.