Context: I am building a macOS file (currently image only) browser using SwiftUI. The core view is a ScrollView containing a LazyVGrid. The layout is dynamic: as the window resizes, I calculate the optimal number of columns and spacing using a GeometryReader. The Issue: While scrolling is pretty smooth (thanks to custom image caching and prefetching), window resizing is significantly laggy. After having scrolled the UI stutters and drops frames heavily while dragging the window edge. The Code: https://github.com/MorusPatre/Binder

I am adopting some of the new glass UI, but having to duplicate a lot of code to maintain support for previous UI systems in macOS. An example: if #available(macOS 26.0, *) { VStack { /*some 40+ lines of code clipped here for brevity*/ } .cueButtons() .cueStyleGlass() } else { VStack { /*identical 40+ lines of code clipped here for brevity*/ } .cueButtons() .cueStyle() } If I try to use conditional modifiers as indicated here: extension View { func cueStyle(font: Font = .system(size: 45)) -> some View { if #available(macOS 26.0, *) { modifier(GlassCueStyle(font: font)) } else { modifier(CueStyle(font: font)) } } } I get this error: Conflicting arguments to generic parameter 'τ_1_0' ('ModifiedContent<Self, GlassCueStyle>' vs. 'ModifiedContent<Self, CueStyle>') Is there a better way to do this?

There is a problem with the launchscreen of my application on iPadOS 26. After release of the windowed mode feature the launchscreen of my fullscreen landscape-only application is being cropped and doesn't stretch to screen's size when the device is in the portrait mode. How can I fix this?

I need to create a Mac application using Objective-C. The application has to use PHPickerViewController to provide user a familiar interface to pick photos. Here is the Objective-C code that used to present the photo picker. //ViewController.h #import <Cocoa/Cocoa.h> #import <PhotosUI/PhotosUI.h> @interface ViewController : NSViewController<PHPickerViewControllerDelegate> @property (nonatomic, weak) IBOutlet NSImageView *myImageView; @end // ViewController.m @implementation ViewController PHPickerViewController* pickerViewController = nil; - (void)pickPhotos { PHPickerConfiguration *config = [[PHPickerConfiguration alloc] init]; config.selectionLimit = 0; // Allow multiple selections config.filter = [PHPickerFilter imagesFilter]; // Filter for images pickerViewController = [[PHPickerViewController alloc] initWithConfiguration:config]; pickerViewController.preferredContentSize = NSMakeSize(800, 600); pickerViewController.delegate = self; // Set the delegate to handle selection [self presentViewControllerAsModalWindow:pickerViewController]; - (IBAction)clicked:(id)sender { NSLog(@"Button Clicked"); [self pickPhotos]; } - (void)picker:(PHPickerViewController *)picker didFinishPicking:(NSArray<PHPickerResult *> *)results { if (pickerViewController) { [picker dismissViewController:pickerViewController]; } } @end Can you please guide me to show the photo picker to a bigger size?

Is there any way to prevent the keyboard from bouncing when changing the focus state in onSubmit? Or is it not recommended to change focus in onSubmit? The following view is setup so that pressing return on the keyboard should cause focus to move between the TextFields. struct TextFieldFocusState: View { enum Field { case field1 case field2 } @FocusState var focusedField: Field? var body: some View { Form { TextField("Field 1", text: .constant("")) .focused($focusedField, equals: .field1) .onSubmit { focusedField = .field2 } TextField("Field 2", text: .constant("")) .focused($focusedField, equals: .field2) .onSubmit { focusedField = .field1 } } } } I would expect that when pressing return, the keyboard would say on screen. What actually happens is the keyboard appears to bounce when the return key is pressed (first half of gif). I assume this is because onSubmit starts dismissing the keyboard then setting the focus state causes the keyboard to be presented again. The issue doesn't occur when tapping directly on the text fields to change focus (second half of gif).

Is there a way to create a grocery list in swift programmatically? With color and icon? I mean the new Reminders.app v7.0 features. I don't find code or guide in the dev documentation.

Hi all, I’m stuck on a WidgetKit/SwiftUI layout issue. I have a systemMedium widget that shows a block of text. What I want is simple: The text should be as large as possible But it must always fully fit inside the widget No ellipsis (“…”) Short text → big font Longer text → shrink only as much as needed The problem: when I try to make the font larger, the widget often shows only a couple of words and then “…” (or it looks like it’s truncating/clipping), even though I’m using multiline text (lineLimit(nil) etc.). If I keep a small fixed font size, the entire text shows fine — so the input string isn’t truncated. I tried a few approaches: ViewThatFits seeing which font size fits minimumScaleFactor Measuring with NSAttributedString.boundingRect + binary search to calculate the biggest font size that should fit But WidgetKit still behaves inconsistently and I can’t get a reliable “largest size that fits” result. Is there a recommended, production-safe way to do this in WidgetKit? Also: can a SwiftUI Text still end up showing “…” in a widget even with .lineLimit(nil) when it’s constrained vertically? Thanks in advance — any pointers or known patterns would really help.

After updating to macOS 26.3 Release Candidate, all interactions for borderless windows are no longer working. In macOS 26.3 Beta, borderless windows behaved correctly: • Mouse clicks were received normally • Window dragging worked as expected • Interaction logic was fully functional However, in macOS 26.3 RC, all of the above behaviors are broken: • Click events are not delivered • Windows cannot be moved or interacted with • The issue affects all borderless windows This is a regression from the Beta build and appears to be system-level, not app-specific. Environment: • macOS: 26.3 RC • Window type: borderless / frameless windows • Status in 26.3 Beta: working correctly • Status in 26.3 RC: completely broken Could Apple confirm whether this is a known issue or an intentional behavior change in 26.3 RC? If this is a , is there a recommended workaround before the final release? Thanks.

I have Mac apps that embed “Helper Apps” inside their main bundle. The helper apps do work on behalf of the main application. The helper app doesn’t show a dock icon, it does show minimal UI like an open panel in certain situations (part of NSService implementation). And it does make use of the NSApplication lifecycle and auto quits after it completes all work. Currently the helper app is inside the main app bundle at: /Contents/Applications/HelperApp.app Prior to Tahoe these were never displayed to user in LaunchPad but now the Spotlight based AppLauncher displays them. What’s the recommended way to get these out of the Spotlight App list on macOS Tahoe? Thanks in advance.

Hello, I'm trying to create game in macos with transperent titlebar. The title bar t stay transperent when I click inside, but changed to gray when the window resize or get out of focus. How can I make it stay transperent all the time? I did all of this: window.styleMask.insert(.fullSizeContentView) window.titlebarAppearsTransparent = true window.titlebarSeparatorStyle = .none window.titleVisibility = .hidden window.isMovableByWindowBackground = true window.isOpaque = false window.backgroundColor = .black in the swiftUI view created zstack that start with: var body: some View { ZStack { Color.black.ignoresSafeArea() help please :) Thanks.

Hello 👋 I ran into a SwiftUI lifecycle gotcha while debugging a List with .refreshable I share the code used to reproduce the issue @Observable final class CounterModel: Identifiable { let id: String var title: String var value: Int init(id: String, title: String, value: Int = 0) { self.id = id self.title = title self.value = value } deinit { print("deinit", title) } } @Observable final class ObservableCountersStore { var counters: [CounterModel] = [ .init(id: "1", title: "A"), .init(id: "2", title: "B"), .init(id: "3", title: "C") ] func refresh() async { try? await Task.sleep(nanoseconds: 300_000_000) counters = [.init(id: "4", title: "D")] } } struct ObservableCountersListView: View { @State private var store = ObservableCountersStore() var body: some View { List { ForEach(store.counters) { counter in ObservableCounterRow(counter: counter) } } .refreshable { await store.refresh() } } } struct ObservableCounterRow: View { let counter: CounterModel var body: some View { Text(counter.title) } } Observation: After calling refresh(), only some of the previous CounterModel only one CounterModel is deallocated immediately. Others are retained This doesn’t look like a leak, but it made me realize that passing observable reference types directly into List rows leads to non-deterministic object lifetimes, especially with .refreshable. Posting this as a gotcha — curious if this matches intended behavior or if others have run into the same thing.

I have the following view hierarchy in my app: [UINavigationController] -> [MainViewController] -> [MyTabBarController] -> [DashboardViewController] In my MainViewController I have a button that pushes the MyTabBarController onto the navigation controllers stack. In the tab bar controller I only have one tab in this example showing the DashboardViewController. That all works fine, and when I tap the back button on MyTabBarController, everything works fine and the MainViewController is shown again. The UI works exactly how I want it, but when I load up the 'Debug Memory Graph' view, I can see that my DashboardViewController is still in memory and it seems the UITab has a reference to it. The MyTabBarController is NOT in memory anymore. MyTabBarController is very simple: class MyTabBarController: UITabBarController { override func viewDidLoad() { super.viewDidLoad() self.mode = .tabSidebar var allTabs:[UITab] = [] let mainTab = UITab(title: "Dashboard", image: UIImage(systemName: "chart.pie"), identifier: "dashboard", viewControllerProvider: { _ in return UINavigationController(rootViewController: DashboardViewController()) }) allTabs.append(mainTab) setTabs(allTabs, animated: false) } } And the DashboardViewController is empty: class DashboardViewController: UIViewController { } The only reason I created as a seperate class in this example is so I can easily see if it's visible in the memory debug view. I have uploaded the simple sample app to GitHub: https://github.com/fwaddle/TabbarMemoryLeakCheck Anyone have any suggestions? Here is a screen grab of the memory debug view showing the UITab having a reference to the DashboardViewController even though MyTabBarController has been dealloc'd:

Hi all, I’m seeing a lifecycle behavior change on iOS 26.0 (and up). While my app is in the foreground and active, pressing the hardware Lock button triggers didBecomeActive callbacks/notifications even though the app is transitioning away from active state. I’m observing this sequence: willResignActive didBecomeActive willResignActive didEnterBackground This happens for: • UISceneDelegate.sceneDidBecomeActive(:) • UIApplicationDelegate.applicationDidBecomeActive(:) • UIApplication.didBecomeActiveNotification On iOS 18 (same app, same code) I do not see didBecomeActive in the middle of locking/backgrounding. Problem is reproduced on totally new project. I would expect a normal transition to background: • willResignActive → didEnterBackground …and no extra didBecomeActive between them. I have “became active” logic (refresh UI/state, resume timers, analytics). On iOS 26.0 this logic runs unexpectedly during locking, causing unnecessary work and incorrect state transitions. Is this callback ordering expected on iOS 26.0 when pressing the Lock button? If expected, what’s the recommended way to detect a “real” activation (and avoid transient didBecomeActive during locking/backgrounding)? If this is a regression, is there a known workaround or best practice?

inline-code How do you achieve this effect in toolbar? Where is the documentation for this? How to make it appear top toolbar or bottom toolbar? Thank you! Here is what I have now... .toolbar { ToolbarItem(placement: .destructiveAction) { Button { showConfirm = true } label: { Image(systemName: "trash") .foregroundColor(.red) } } } .confirmationDialog( "Are you sure?", isPresented: $showConfirm, titleVisibility: .visible ) { Button("Delete Item", role: .destructive) { print("Deleted") } Button("Archive", role: .none) { print("Archived") } Button("Cancel", role: .cancel) { } } }

Currently i am trying really hard to create experience like the Apple fitness app. So the main view is a single day and the user can swipe between days. The week would be displayed in the toolbar and provide a shortcut to scroll to the right day. I had many attempts at solving this and it can work. You can create such an interface with SwiftUI. However, changing the data on every scroll makes limiting view updates hard and additionally the updates are not related to my code directly. Instruments show me long updates, but they belong to SwiftUI and all the advice i found does not apply or help. struct ContentView: View { @State var journey = JourneyPrototype(selection: 0) @State var position: Int? = 0 var body: some View { ScrollView(.horizontal) { LazyHStack(spacing: 0) { ForEach(journey.collection, id: \.self) { index in Listing(index: index) .id(index) } } .scrollTargetLayout() } .scrollTargetBehavior(.paging) .scrollPosition(id: $position) .onChange(of: position) { oldValue, newValue in journey.selection = newValue ?? 0 journey.update() } .onScrollPhaseChange { oldPhase, newPhase in if newPhase == .idle { journey.commit() } } } } struct Listing: View { var index: Int var body: some View { List { Section { Text("Title") .font(.largeTitle) .padding() } Section { Text("\(index)") .font(.largeTitle) .padding() } Section { Text("1 ") Text("2 ") Text("3 ") Text("4 ") Text("5 ") Text("6 ") } } .containerRelativeFrame(.horizontal) } } @Observable class JourneyPrototype { var selection: Int var collection: [Int] var nextUp: [Int]? init(selection: Int) { self.selection = selection self.collection = [selection] Task { self.collection = [-2,-1,0,1,2] } } func update() { self.nextUp = [ self.selection - 2, self.selection - 1, selection, self.selection + 1, self.selection + 2 ] } func commit() { self.collection = self.nextUp ?? self.collection self.nextUp = nil } } #Preview { ContentView() } There are some major Problem with this abstracted prototype ScrollView has no good trigger for the update, because if i update on change of the position, it will update much more than once. Thats why i had to split calculation and applying the diff The LazyHStack is not optimal, because there are only 5 View in the example, but using HStack breaks the scrollPosition Each scroll updates all List, despite changing only 2 numbers in the array. AI recommended to append and remove, which does nothing about the updates. In my actual Code i do this with Identifiable data and the Problem is the same. So the data itself is not the problem? Please consider, this is just the rough prototype to explain the problem, i am aware that an array of Ints is not ideal here, but the problem is the same in Instruments and much shorter to post. Why am i posting this? Scrolling through dynamic data is required for many apps, but there is no proper solution to this online. Github and Blogs are fine with showing a progress indicator and letting the user wait, some probably perform worse than this prototype. Other solutions require UIKit like using a UIPageViewController. But even using this i run in small hitches related to layout. Important consideration, my data for the scrollview is too big to be calculated upfront. 100 years of days that are calculated for my domain logic take too long, so i have no network request, but the need to only act on a smaller window of data. Instruments shows long update for one scroll action tested on a iPhone SE 2nd generation ListRepresentable has 7 updates and takes 17ms LazySubViewPlacements has 2 updates and takes 8ms Other long updates are too verbose to include I would be very grateful for any help.

Hi all, I’m running into a “double update” effect in SwiftUI when using the @Observable with @State. I’m trying to understand whether this is expected behavior, a misuse on my side, or a potential bug. Setup I have an observable store using the Observation macro: @Observable class AlbumStore { var albums: [Album] = [ Album(id: "1", title: "Album 1", author: "user1"), Album(id: "2", title: "Album 2", author: "user1"), Album(id: "3", title: "Album 3", author: "user1"), Album(id: "4", title: "Album 4", author: "user1"), Album(id: "5", title: "Album 5", author: "user1"), Album(id: "6", title: "Album 6", author: "user1") ] func addAlbum(_ album: Album) { albums.insert(album, at: 0) } func removeAlbum(_ album: Album) { albums.removeAll(where: { $0 == album }) } } In my view, I inject it via @Environment and also keep some local state: @Environment(AlbumStore.self) var albumStore @State private var albumToAdd: Album? I derive a computed array that depends on both the environment store and local state: private var filteredAlbums: [Album] { let albums = albumStore.albums.filter { album in if let albumToAdd { return album.id != albumToAdd.id } else { return true } } return albums } View usage Inside a horizontal ScrollView / LazyHStack, I observe changes to filteredAlbums: @ViewBuilder private func carousel() -> some View { GeometryReader { proxy in let itemWidth: CGFloat = proxy.size.width / 3 let sideMargin = (proxy.size.width - itemWidth) / 2 ScrollView(.horizontal, showsIndicators: false) { LazyHStack(spacing: 20) { ForEach(filteredAlbums, id: \.id) { album in albumItem(album: album) .frame(width: itemWidth) .scrollTransition(.interactive, axis: .horizontal) { content, phase in content .scaleEffect(phase.isIdentity ? 1.0 : 0.8) } } } .scrollTargetLayout() } .scrollTargetBehavior(.viewAligned(limitBehavior: .always)) .scrollPosition(id: $carouselScrollID, anchor: .center) .contentMargins(.horizontal, sideMargin, for: .scrollContent) .onChange(of: filteredAlbums) { old, new in print("filteredAlbums id: \(new.map { $0.id })") } } } Triggering the update When I add a new album, I do: albumToAdd = newAlbum albumStore.addAlbum(newAlbum) Expected behavior Since filteredAlbums explicitly filters out albumToAdd, I expect the result to remain unchanged. Actual behavior I consistently get two onChange callbacks, in this order: filteredAlbums id: ["E852E42A-AAEC-4360-A6A6-A95752805E2E", "1", "2", "3", "4", "5", "6"] filteredAlbums id: ["1", "2", "3", "4", "5", "6"] This suggests: The AlbumStore update (albums.insert) is observed first. The @State update (albumToAdd) is applied later. As a result, filteredAlbums is recomputed twice with different dependency snapshots. On a real iPad device, this also causes a visible scroll position jump. In the simulator, the jump is not visually observable; however, the onChange(of: filteredAlbums) callback still fires twice with the same sequence of values, indicating that the underlying state update behavior is identical. Strange observations This does not happen with ObservableObject If I replace @Observable with a classic ObservableObject + @Published: class OBAlbumStore: ObservableObject { @Published var albums: [Album] = [ Album(id: "1", title: "Album 1", author: "user1"), Album(id: "2", title: "Album 2", author: "user1"), Album(id: "3", title: "Album 3", author: "user1"), Album(id: "4", title: "Album 4", author: "user1"), Album(id: "5", title: "Album 5", author: "user1"), Album(id: "6", title: "Album 6", author: "user1") ] func addAlbum(_ album: Album) { albums.insert(album, at: 0) } func removeAlbum(_ album: Album) { albums.removeAll(where: { $0 == album }) } } …and inject it with @EnvironmentObject, the double update disappears. Removing GeometryReader also avoids the issue If I remove the surrounding GeometryReader and hardcode sizes: @ViewBuilder private func carousel() -> some View { // GeometryReader { proxy in let itemWidth: CGFloat = 400 let sideMargin: CGFloat = 410 ScrollView(.horizontal, showsIndicators: false) { LazyHStack(spacing: 20) { ForEach(filteredAlbums, id: \.id) { album in albumItem(album: album) .frame(width: itemWidth) .scrollTransition(.interactive, axis: .horizontal) { content, phase in content .scaleEffect(phase.isIdentity ? 1.0 : 0.8) } } } .scrollTargetLayout() } .scrollTargetBehavior(.viewAligned(limitBehavior: .always)) .scrollPosition(id: $carouselScrollID, anchor: .center) .contentMargins(.horizontal, sideMargin, for: .scrollContent) .onChange(of: filteredAlbums) { old, new in print("filteredAlbums id: \(new.map { $0.id })") } // } } …the double onChange no longer occurs. Questions Is this update ordering expected when using @Observable and @State? Does Observation intentionally propagate environment changes before local state updates? Is GeometryReader forcing an additional evaluation pass that exposes this ordering? Is this a known limitation / bug compared to ObservableObject? I want to understand why this behaves differently under Observation. Thanks in advance for any insights 🙏 Full Project Link

When using an image in a List item, you sometimes want to tint that image, but only if the item isn’t selected. When it’s selected, you usually want the contents of the list item to be all-white, for contrast. The backgroundProminence Environment value ostensibly exists for this purpose, but in my tests, it never seems to change. Am I doing something wrong? Is there an alternative solution? For instance, this code: import SwiftUI struct ProminentBackgroundInList: View { var body: some View { List(selection: .constant(0)) { ListItem().tag(0) ListItem().tag(1) } } } struct ListItem: View { @Environment(\.backgroundProminence) var backgroundProminence var body: some View { HStack { Image(systemName: "person.fill") .foregroundStyle(backgroundProminence == .standard ? .orange : .primary) Text("Person") } } } #Preview { ProminentBackgroundInList() } Produces this result:

Hi all - i'm encountering a strange issue since updating to Xcode 26.0.1. It seems that any SwiftUI Views that have an :ObservedObject property that contains @Published properties, and use those properties inside the View, no longer update when those properties are updated when the view also has an @Environment property. If I remove the @Environment property and any usage of it, the view updates correctly. The specific environment property i'm using is .safeAreaInsets, like so: @Environment(\.safeAreaInsets) private var safeAreaInsets Is this a recognised bug in the latest iOS 26 SDK? Thanks

Opened feedback item FB21877364. Context I have the following Metal shader, which replaces one color with another. [[ stitchable ]] half4 recolor( float2 position, half4 currentColor, half4 from, half4 to ) { if (all(currentColor == from)) return to; return currentColor; } Given this SwiftUI view: let shader = ShaderLibrary.recolor(.color(.red), .color(.green)) Color.red .colorEffect(shader) I get a red rectangle instead of the expected green one. Note that this works on both dynamic and non-dynamic colors. Note that this sometimes works with some colors, which is very inconvenient when trying to figure out what's going on. Did I miss something? I would've expected the shader to work with colors the same way. Issue To really highlight the issue, here's another test case. I'll define #94877E in an Asset Catalog as example and check the RGB values using the Digital Color Meter app in "Display native values" mode. We'll use the following shader to determine how colorEffect receives colors: [[ stitchable ]] half4 test( float2 position, half4 currentColor, half4 color ) { return color; } The following view yields "R: 0.572, G: 0.531, B: 0.498". Color.example While this one yields "R: 0.572, G: 0.531, B: 0.499". let shader = ShaderLibrary.test(.color(Color.example)) Color.white.colorEffect(shader) I would expect them to match.

When using the Password AutoFill feature, after entering a password and navigating to another page, a system prompt appears asking whether to save the password to the keychain (as shown in the figure). If this prompt is not dismissed and the app is moved to the background, then brought back to the foreground, the prompt automatically disappears. However, after this occurs, all input fields within the app become unresponsive to keyboard input—no keyboard will appear when tapping any text field. The only way to restore keyboard functionality is to force-quit the app and relaunch it. How can this issue be resolved?