Hello,
My goal is to have a NavigationStack whose root view is determined based on its height and width. To do so, I'm using ViewThatFits, which should choose the right view to display. It is working fine, but unexpectedly both views trigger onAppear, whereas only the appropriate one should. This causes the logic in both closures to be executed, which is not intended.
The code below demonstrates the problem:
struct NavigationStackContentView: View {
var body: some View {
NavigationStack {
ViewThatFits(in: .vertical) {
Color.yellow
.onAppear { print("|-> on appear: yellow") }
.onDisappear { print("|-> on disappear: yellow") }
Color.red
.frame(width: 1500, height: 1500)
.onAppear { print("|-> on appear: red") }
.onDisappear { print("|-> on disappear: red") }
}
}
}
}
this produces:
|-> on appear: red
|-> on disappear: red
|-> on appear: yellow
When ViewThatFits is not nested within NavigationStack, the problem does not occur — only the yellow view (in this sample) triggers onAppear, which is the expected behavior. I also checked the macOS version, and the problem does not occur at all, whether within NavigationStack or not.
This example is simple and demonstrates that the larger view is the second one. When I switch their places, the problem does not occur because it recognizes that the first view would not fit at this point. However, in my case I will have these views without knowing which one will not fit, so switching their order is not a viable solution if this works without NavigationStack.
Am I doing something wrong, or is this a bug?
//
iOS: 18.3.1
Xcode: 16.2
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
This sample code exhibits two issues:
struct ContentView: View
{
@State private var myColor = Color.red
var body: some View {
VStack() {
List() {
Text("Object")
Text("Object")
Text("Object")
.listRowSeparatorTint(myColor)
Text("Object")
}
Button(action:{myColor = Color.green})
{Text("Change color")}
}
.foregroundColor(myColor)
}
}
the row separator isn't redraws when the @State property change
listRowSeparatorTint apply to two lines
The first point is really disappointing. Is there anyone which know if this is a bug or there is a more correct way to use listRowSeparatorTint with changing parameter?
To get menubar size, we can call.
let menuBarHeight = NSStatusBar.system.thickness
That is returning 24 and it is the same as my external screen. I did command + shift + 5 and use the screen capture tool to rougly measure the size of menubar. It is roughly 24px.
However, for my macbook pro 14 inches m2 pro. The menubar seem thicker because of the webcam. Is there a way to find out the size in Swift?
I just put the TextField on UI and call the NSTextField setString,
but it is memory usage is increasing.
StoryBoard
Objective C
put TextField and button to UI
set TextField variable to "ABC" in ViewController.h
@property (weak) IBOutlet NSTextView* ABC;
on button event function
//dispatch_sync(dispatch_get_main_queue(), ^{
[_ABC setString:str];
//});
How to block the memory usage increase?
Also I was check on Instruments app, and there are many malloc 48bytes, its count is almost same with setString count.
Thank you!
I am trying to implement the NSTextViewDelegate function textViewDidChangeSelection(_ notification: Notification). My text view's delegate is the Coordinator of my NSViewRepresentable. I've found that this delegate function never fires, but any other delegate function that I implement, as long as it doesn't take a Notification as an argument, does fire (e.g., textView(:willChangeSelectionFromCharacterRange:toCharacterRange:), fires and is called on the delegate exactly when it should be).
For context, I've verified all of the below:
textView.isSelectable = true
textView.isEditable = true
textView.delegate === my coordinator
I can call textViewDidChangeSelection(:) directly on the delegate without issue.
I can select and edit text without issues. I.e., the selections are being set correctly. But the delegate method is never called when they are.
I am able to add the intended delegate as an observer for the selector textViewDidChangeSelection via NotificationCenter. If I do this, the function executes when it should, but fires for every text view in my view hierarchy, which can number in the hundreds. I'm using an NSLayoutManager, so I figure this should only fire once. I've added a check within my code:
func textViewDidChangeSelection(_ notification: Notification) {
guard let textView = notification.object as? NSTextView,
textView === layoutManager.firstTextView else { return }
// Any code I want to execute...
}
But the above guard check lets through every notification, so, no matter what, my closure executes hundreds of times if I have hundreds of text views, all of them being sent by textView === layoutManager.firstTextView, but once for each and every text view managed by that layoutManager.
Does anyone know why this method isn't ever called on the delegate, while seemingly all other delegate methods are? I could go the NotificationCenter route, but I'd love to know why this won't execute as a delegate method when documentation says that it should, and I don't want to have to implement a counter to make sure my code only executes once per selection update. And for more reasons than that, implementing via delegate method is preferable to using notifications for my use case.
Thanks for any help!
How can I achieve the result of buttons glass effect like sample videos that was show at de WWDC25? I tried a lot of approaches and I still far a way from the video.
I would like something like the pictures attached. Could send a sample code the get the same result?
Thanks
Hi,
I was wondering if it's possible (and advisable) to use the new glass effects available in iOS 26 in Swift Charts?
For example, in a chart like the one in the image I've attached to this post, I was looking to try adding a .glassEffect modifier to the BarMarks to see how that would look and feel.
However, it seems it's not available directly on the BarMark (ChartContent) type, and I'm having trouble adding it in other ways too, such as using in on the types I supply to modifiers like foregroundStyle or clipShape.
Am I missing anything? Maybe it's just not advisable or necessary to use glass effects within Charts?
When using a .zoom navigation transition, where .matchedTransitionSource is applied to a button in a toolbar and the destination view is a sheet which is presented with PresentationDetent.medium, the transition works initially, but shortly after it completes, the sheet's background is dimmed and the text of the source button reappears abruptly.
Code and a screenshot are below, though the effect is best observed when interacting with the view.
//
// ContentView.swift
// ZoomNavigationTransitionSample
//
// Created by Matthew DuBois on 6/15/25.
//
import SwiftUI
struct ContentView: View {
@State private var isPresentingSheet = false
@Namespace private var namespace
var body: some View {
NavigationStack {
List {
Text("Some content")
}
.navigationTitle("Sample")
.toolbar {
ToolbarItem(placement: .topBarTrailing) {
Button("Button") {
isPresentingSheet = true
}
.matchedTransitionSource(id: "button", in: namespace)
}
}
.sheet(isPresented: $isPresentingSheet) {
Text("Some sheet content")
.navigationTransition(.zoom(sourceID: "button", in: namespace))
.presentationDetents([.medium])
}
}
}
}
#Preview {
ContentView()
}
I have a memory leak for SVG image that located in Assets.xcassets file when using SwiftUI Image, but when I use UIImage then convert it to SwiftUI Image the issue is not found.
import SwiftUI
struct ContentView: View {
var body: some View {
NavigationStack {
VStack {
NavigationLink("Show", destination: SecondView())
}
.padding()
}
}
}
struct SecondView: View {
@Environment(\.dismiss) var dismiss
var body: some View {
NavigationStack {
VStack {
IM.svgImage
.resizable()
.scaledToFit()
.frame(width: 200, height: 200)
Button("Dismiss") {
dismiss()
}
}
}
}
}
enum IM {
static let testImage: Image = "test_image".image
static let svgImage: Image = "svgImage".image
}
extension String {
var image: Image {
Image(self) // Memory leak
}
var imageFromUIImage: Image {
guard let uiImage = UIImage(named: self) else {
return Image(self)
}
return Image(uiImage: uiImage) // No Memory leak
}
}
Environment that produces the issue:
Xcode: 16.2
Simulator: iPhone 15 Pro (iOS 17.5)
Overview
Starting with macOS 26 beta 1, a new NSGlassContainerView is added inside NSToolbarView.
This view intercepts mouse events, so any SwiftUI Button (or other interactive view) overlaid on the title‑bar / toolbar area no longer receives clicks.
(The same code works fine on macOS 15 and earlier.)
Filed as FB18201935 via Feedback Assistant.
Reproduction (minimal project)
macOS 15 or earlier → button is clickable
macOS 26 beta → button cannot be clicked (no highlight, no action call)
@main
struct Test_macOS26App: App {
init() {
// Uncomment to work around the issue (see next section)
// enableToolbarClickThrough()
}
var body: some Scene {
WindowGroup {
ContentView()
}
.windowStyle(.hiddenTitleBar) // ⭐️ hide the title bar
}
}
struct ContentView: View {
var body: some View {
NavigationSplitView {
List { Text("sidebar") }
} detail: {
HSplitView {
listWithOverlay
listWithOverlay
}
}
}
private var listWithOverlay: some View {
List(0..<30) { Text("item: \($0)") }
.overlay(alignment: .topTrailing) { // ⭐️ overlay in the toolbar area
Button("test") { print("test") }
.glassEffect()
.ignoresSafeArea()
}
}
}
Investigation
In Xcode View Hierarchy Debugger, a layer chain
NSToolbarView > NSGlassContainerView sits in front of the button.
-[NSView hitTest:] on NSGlassContainerView returns itself, so the event never reaches the SwiftUI layer.
Swizzling hitTest: to return nil when the result is the view itself makes the click go through:
func enableToolbarClickThrough() {
guard let cls = NSClassFromString("NSGlassContainerView"),
let m = class_getInstanceMethod(cls, #selector(NSView.hitTest(_:))) else { return }
typealias Fn = @convention(c)(AnyObject, Selector, NSPoint) -> Unmanaged<NSView>?
let origIMP = unsafeBitCast(method_getImplementation(m), to: Fn.self)
let block: @convention(block)(AnyObject, NSPoint) -> NSView? = { obj, pt in
guard let v = origIMP(obj, #selector(NSView.hitTest(_:)), pt)?.takeUnretainedValue()
else { return nil }
return v === (obj as AnyObject) ? nil : v // ★ make the container transparent
}
method_setImplementation(m, imp_implementationWithBlock(block))
}
Questions / Call for Feedback
Is this an intentional behavioral change?
If so, what is the recommended public API or pattern for allowing clicks to reach views overlaid behind the toolbar?
Any additional data points or confirmations are welcome—please reply if you can reproduce the issue or know of an official workaround.
Thanks in advance!