Construct and manage a graphical, event-driven user interface for your macOS app using AppKit.

Posts under AppKit tag

200 Posts

Post

Replies

Boosts

Views

Activity

NSTrackingSeparatorToolbarItem causes white bar over top of content in macOS 27 developer beta 5
macOS 27 developer beta 5 introduces a bug where an NSTrackingSeparatorToolbarItem in a toolbar causes a bar to appear under the toolbar, overlaying the content. I have a blog post about this at: https://www.virtualsanity.com/202608/nstrackingseparatortoolbaritem-causes-white-bar-over-top-of-content-in-macos-27-developer-beta-5/ I reported this as FB24266969. A sample project and a screenshot are included in both the blog post and the feedback report.
Topic: UI Frameworks SubTopic: AppKit Tags:
7
1
588
9h
Bug or Feature: Changes to Window Reopen Behavior in macOS 26
Since macOS 26 Beta 1, I notice that the window reopening behavior had changed. Say there are two desktops (spaces), one might: open an app window in desktop 1 close that window switch to desktop 2 reopen the app window (by click on dock tile, spotlight search...) Prior to macOS 26, that window will always reopen in current desktop. This is IMO the right behavior because these windows are most likely transient (message app, chat app, utilities app or note app). In macOS 26, however, will switch to desktop 1 (where the window is closed) and reopen the window in desktop 1. This is weird to me because: Window is "closed", hence it should not be attached to desktop 1 anymore, unlike minimize. Switching desktop interrupts user's current workflow. It's annoying to switch back specially when there're many desktops. This behavior is inconsistent. Some reopen in current desktop, some reopen in previous desktop. Apps like Music, Notes and Calendar reopened in previous desktop, while Mail, Messages, and Freeform reopened in current desktop. I did a little bit of experiment, and find out that apps that reopened in current desktop are most likely because they take an extra step to release the window when it's closed. I believe this is a bug, so I fire a feedback (FB18016497) back in beta 1. But I did not get any response or similar report from others, to a point that I kinda wonder if this is intended. I can easily force my app to reopen in current desktop by nullifying my window controller in windowWillClose, but this behavior essentially change how one can use the Spaces feature that I think I should bring this up to the community and see what other developers or engineers thinks about it.
Topic: UI Frameworks SubTopic: AppKit Tags:
5
1
559
1d
# SwiftUI `Document` app hangs on macOS 27 when another process changes its file
On macOS 27.0 (26A428) with Xcode 27.0, Apple's unmodified sample Building a document-based app with SwiftUI stops responding permanently when another process replaces an open document's file through NSFileCoordinator. AppKit reverts the document on the main thread, which then blocks in a semaphore wait inside SwiftUI: -[NSDocument relinquishPresentedItemToWriter:]_block_invoke_8 (in AppKit) -[NSDocument _revertToVersion:preservingFirst:error:] (in AppKit) -[NSDocument revertToContentsOfURL:ofType:error:] (in AppKit) URLPlatformDocument.read(from:ofType:) (in SwiftUI) _dispatch_semaphore_wait_slow (in libdispatch.dylib) No other thread is reading the document. In another app using Document, its DocumentReader was never called, and a document with unsaved changes hung the same way in URLPlatformDocument.write(to:ofType:for:originalContentsURL:). Reproduction (the sample plus a short script): https://github.com/DePasqualeOrg/swiftui-document-revert-hang Feedback report: FB24792850
0
0
128
2d
Spotlight Shows "Helper Apps" That Are Inside Main App Bundle That Are Not Intended to Be Launched By The User
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.
8
0
760
2d
Title bar double-click / Fill on macOS 27
I’m seeing a reproducible title-bar interaction issue on macOS 27 RC (26A428). This issue has been present since at least macOS 27 build 26A5416b (Developer Beta 6 / Public Beta 4) and is still reproducible on the Release Candidate, build 26A428. My System Settings → Desktop & Dock → Window title bar double-click action is configured to Fill. In several system apps with sidebars, including: Finder System Settings Reminders Feedback Assistant the right side of the title bar shows a visible rectangular region when the pointer hovers over it. The more important problem is that the middle portion of this region appears to intercept the title-bar double-click. Double-clicking there does nothing, while double-clicking very close to the top or bottom edge of the same region correctly triggers Fill. This makes the normal title-bar gesture surprisingly difficult to use because the center of the title bar is naturally where I would double-click. Interestingly, the sidebar area does not have this problem: double-clicking the top, middle, or bottom portions of the sidebar title-bar area all works normally. Feedback Assistant makes the behavior particularly easy to see because its left sidebar and rightmost pane behave normally, while the title-bar region above the middle pane exhibits the problem. Steps to reproduce: Set “Double-click a window’s title bar” to Fill in Desktop & Dock settings. Open Finder, System Settings, Reminders, or Feedback Assistant. Move the pointer over the right/content portion of the title bar until the rectangular hover region appears. Double-click around the center of that region. The Fill action does not occur. Double-click very close to the upper or lower edge of the same region. Fill works normally. I have reproduced this on macOS 27 RC build 26A428, including: a newly created macOS user account Safe Mode so it does not appear to be caused by migrated preferences, caches, login items, or third-party software. A screen recording demonstrating the exact hit-testing behavior was submitted through Feedback Assistant. Feedback: FB24462749 Is anyone else able to reproduce this? It looks as though some view or overlay in the new title-bar/toolbar area may be intercepting mouse events.
1
0
159
1w
NSColorSampler can leave ColorSampler.xpc capturing all mouse clicks after the host app quits
I encountered a severe NSColorSampler failure on macOS 27.0 (26A5425a). After invoking: NSColorSampler().show { selectedColor in // Handle selected colour } the system colour sampler became stuck. The pointer disappeared and all mouse clicks were captured across macOS. Pressing Escape did not recover it. Quitting the host application also did not restore clicking. The Apple-owned process remained active after the application exited: /System/Library/Frameworks/AppKit.framework/Versions/C/XPCServices/ColorSampler.xpc/Contents/MacOS/ColorSampler Sending SIGTERM to that process had no effect. Force-terminating it with SIGKILL immediately restored mouse clicking. Environment: macOS 27.0, build 26A5425a MacBook Pro Mac16,8 Apple M4 Pro SwiftUI content hosted inside a borderless AppKit window Expected behaviour: selecting a colour, pressing Escape, or terminating the host application should cancel sampling and release all captured input. Actual behaviour: ColorSampler.xpc survives the host application and continues preventing all mouse clicks system-wide. Feedback Assistant report: FB24722293 Has anyone else reproduced this with NSColorSampler, particularly from a borderless AppKit window?
0
0
306
1w
crash when trying to show NSAlert with Mac 27 beta with European and russian languages
Feedback Assistant Submission ID Reference : FB24634485 Attached is a sample code where after setting setlocale() to any of European languages or Russian language results in crash when calling NSAlert. Here is code snippet and crash log for reference. #import <Cocoa/Cocoa.h> int main(int argc, const char * argv[]) { @autoreleasepool { NSString* locale = @“fr_FR.UTF8"; setlocale(LC_ALL, locale.UTF8String); return NSApplicationMain(argc, argv); } } (IBAction)showAlertButtonTapped:(id)sender { NSAlert *alert = [[NSAlert alloc] init]; alert.messageText = NSLocalizedString(@"alert_title", nil); alert.informativeText = NSLocalizedString(@"alert_message", nil); alert.alertStyle = NSAlertStyleInformational; [alert addButtonWithTitle:NSLocalizedString(@"alert_ok_button", nil)]; [alert runModal]; } Crashlog
0
0
99
1w
Where’s the path of Objective-C runtime
Hi systems programming guys. I’m exploring the macOS as a low-level itself, so when I use the otool(1) utility to inspect a tiny objc helloworld program, it told me that there is a shared library like /usr/lib/libobjc.A.dylib (not identical) but I didn’t find that in path /usr/lib/. Also the docs sucked (see below). I want to know more details about the objc runtime on macOS (beta 27.6 +) and be seeking for help here because there are few materials online and not even to say the sucked AI. The prima motivation is the runtime itself and how it works. Of course I would love to read disassembled code and manpages or using utilities that Apple offered to understand those things . But I really don’t know where is the runtime if both docs and otool output lied. The latest documentation about Objective-C Runtime is outdate and it said “Objective-C runtime library support functions are implemented in the shared library found at /usr/lib/libobjc.A.dylib.”
7
0
795
2w
NSTextView Weird Selection Behavior with NSTextAttachmentCells
I have an NSTextView that displays several NSTextAttachmentCells. I notice this weird behavior. Sometimes if I just click in an empty area of the text view the entire text content selects. So I implemented the delegate method to catch it: - (NSRange)textView:(NSTextView *)textView willChangeSelectionFromCharacterRange:(NSRange)oldSelectedCharRange toCharacterRange:(NSRange)newSelectedCharRange { if (newSelectedCharRange.length > 1 && newSelectedCharRange.length > oldSelectedCharRange.length) { NSEvent *currentEvent = NSApp.currentEvent; NSLog(@"Selection expanded from %@ to %@. Event type: %ld, click count: %ld, modifier flags: %lu, current selected ranges: %@", NSStringFromRange(oldSelectedCharRange), NSStringFromRange(newSelectedCharRange), (long)currentEvent.type, (long)currentEvent.clickCount, (unsigned long)currentEvent.modifierFlags, self.selectedRanges); // put a break point here. } return newSelectedCharRange; } And I reproduced the issue and this logs out: Selection expanded from {0, 0} to {0, 6}. Event type: 2, click count: 1, modifier flags: 0, current selected ranges: ( "NSRange: {0, 6} Click count is only 1 so I didn't accidentally triple click. I know on Golden Gate use of NSEvent.currentEvent isn't the way (but I'm not there yet). A simple workaround would be to block the selection right here in the delegate method when clickCount != 3 (but again I know NSEvent.currentEvent in Golden Gate won't be reliable). Anyone run into this and have any ideas? It seems to happen after I did a triple click in the text view at some point previously (but not this click). So I got the feeling that maybe the text view isn't resetting some private properties and is treating this single click as a triple click. But I really don't know. Edit: Hmm maybe it has nothing to do with a previous triple click. May have to do with text selection not accounting for the geometry of the NSTextAttachmentCells. Not sure. But I still have to figure out a way to workaround this because a random select all is really annoying! Call stack looks like: ** -[MyTextView textView:willChangeSelectionFromCharacterRange:toCharacterRange:] at MyTextView.m -[NSTextView(NSSharing) setSelectedRanges:affinity:stillSelecting:] () -[MyTextView setSelectedRanges:affinity:stillSelecting:] MyTextView.m +[NSInputAnalytics(TrackedActionsManager) allowActionTrackingAnalyticsWithName:forAction:] () n -[NSTextView mouseDown:] () -[MyTextView mouseDown:] ** If you're wondering what my -mouseDown: override does it just calls super. I realize this is not a whole lot to go on but any help would be appreciated.
5
0
582
3w
SFAuthorizationPluginView UI changes in macOS Golden Gate Beta – Unable to access the child elements and button controls using NSAccessibilityProtocol
We have observed significant UI changes to the SFAuthorizationPluginView login experience in the latest macOS Golden Gate Beta 5. After entering the account password at the SFAuthorizationPluginView screen, we were previously able to access the buttons and other child elements present in the SFAuthorizationPluginView using "accessibilityChildrenInNavigationOrder" . Currently the method returns that there are no child elements eventhough there are clearly child elements presents including apple's native Ok and Cancel buttons.This behaviour is consistently reproducible in our testing. Steps to Reproduce Configure and launch an unlock authorization plug-in using SFAuthorizationPluginView. Display the authorization UI in unlock. Enter the account password. Wait for the authorization UI to finish transitioning to the authenticated state. Query the SFAuthorizationPluginView accessibility hierarchy. Specifically query accessibilityChildrenInNavigationOrder. Observe that the method returns no child accessibility elements. Inspect the UI visually or using Accessibility Inspector and observe that child controls are still present, including the native OK and Cancel buttons. We would like to understand: 1.Is this a known issue with the current macOS Golden Gate Beta? 2.Is this expected behaviour due to the UI redesign, or is it considered a bug? 3.If it is a known issue, is there a fix planned for an upcoming beta or the final release? Any information or guidance would be appreciated. Thank you.
5
1
435
4w
Vertically Off-Center Components in NSSearchToolbarItem in macOS 27 Developer Beta 5
In macOS 27 developer beta 5, search fields in toolbars (NSSearchToolbarItem instances) have their placeholder text, search strings, and magnifying glass icons vertically off-center. I reported this as FB24286690. You can see this in the Feedback Assistant app. The “Search” placeholder text, the magnifying glass, and the search string are all closer to the top of the toolbar item than the bottom. My feedback has a sample project demonstrating this, along with screenshots. I have a more detailed writeup at: https://www.virtualsanity.com/202608/vertically-off-center-components-in-nssearchtoolbaritem-in-macos-27-developer-beta-5/
Topic: UI Frameworks SubTopic: AppKit Tags:
0
0
207
Aug ’26
Various menu bar NSStatusItem issues with macOS 27
It seems like macOS 27 beta 2 has some issues with NSStatusItem buttons added to the menu bar - this creates difficulties for some menu bar extra apps. NSStatusItem buttons does not receive mouse hover/movement events - FB23329983 On macOS 27, views inside an NSStatusItem button no longer receive hover or mouse-movement events. The same code works correctly on macOS 26. What I tried: An NSTrackingArea attached to a subview of NSStatusBarButton An NSTrackingArea attached directly to the status-bar button Replacing NSStatusItem.view with a custom view Embedding an NSHostingView and using SwiftUI onHover/onContinuousHover NSStatusItem button highlight cannot be set programmatically. - FB23330269 The following code no longer has any effect (does not provide the highlight capsule): NSStatusItem.button?.highlight(true) NSStatusItem window occlusionState no longer reflects hidden menu bar visibility - FB23349447 The following no longer works: statusItem.button?.window?.occlusionState.contains(.visible) These changes may be related to some of the touch related changes or maybe it's about how menu items are now seemingly more "managed" in a way that their position, visibility may change in a way that is transparent/undetectable to the app.
6
2
985
Aug ’26
NSSearchToolbarItem cancel button triggers action before clearing text and before the ending search notification
I am trying to use an NSSearchToolbarItem using AppKit directly in Objective-C. If I perform a search and then click the cancel icon, my target/action is called while the NSSearchField still contains the search text (not yet cleared) and the delegate has not yet received the ending search invocation. In other words, it looks exactly the same as if the user had submitted the same search twice. Google's AI suggested using the controlTextDidChange method, but that was deprecated long ago. My current solution is to ignore searches that appear redundant (although they may not be, if the data being searched changes). This is on macOS 26.6.
Topic: UI Frameworks SubTopic: AppKit Tags:
0
0
432
Aug ’26
Guideline 4 rejection — Unity macOS app: missing App Menu, title bar buttons, and Dock icon
I'm distributing a Unity-built game on the Mac App Store and I've been rejected twice under Guideline 4 (Design) with the same wording: "We still noticed that the app presents a window that does not contain the necessary title bar buttons and includes an interface window but is missing the required App Menu and Dock Icon or Menu Bar Extra." I'd like to hear from anyone who has hit this with a Unity (or otherwise non-native) macOS app and got it resolved. What I'm seeing: When the game runs, the macOS menu bar is displayed, but it only shows the app name and a single "Window" menu. The standard menus Apple expects (App menu with About/Quit, Edit, Window, Help) are not there. Unity does not populate the native macOS menu bar on its own, and there's no Player Setting that generates these menus. What I've already tried: Switched the app from borderless window to a standard windowed mode, so the window has its title bar and close/minimize/zoom buttons. Confirmed the Dock icon appears with the running indicator in standard windowed mode. Verified there is no LSUIElement key forcing the app into accessory mode in Info.plist. Despite this, the rejection came back identical. My questions: For those who passed review, did you populate the full native menu bar (App / Edit / Window / Help), or did Apple accept the app another way? Is a complete standard menu bar strictly required, or does shipping the app in fullscreen — where macOS hides the menu bar by design, as with most Mac games — satisfy the reviewer on this point? For the "title bar buttons" and "Dock icon" part of the rejection specifically: what exactly does the reviewer expect to see, and does fullscreen change how they evaluate it? If you resolved this, did you mention the change in the App Review notes, and did that help? Any concrete experience — especially with games that launch fullscreen — would be very helpful. Thanks.
0
0
172
Aug ’26
Using AppKit and Core Graphics within a CUPS filter context on macOS
Hello, I am currently developing a printed data security feature for a cross-platform DLP system. On other platforms, this functionality relies on a cross-platform third-party library. On macOS, this library depends on the Core Graphics and AppKit frameworks. So, such dependency makes it impossible to use the code within a launch daemon, which is where this mechanism needs to run. As an alternative approach, I am considering implementing the necessary functionality inside a CUPS filter. However, I have some doubts regarding the execution context of the CUPS filter process. Is it safe to use AppKit within a CUPS filter? Thank you in advance.
0
0
465
Aug ’26
window:willUseFullScreenPresentationOptions: with NSApplicationPresentationHideDock causes other windows to be unminimizable
In the below code, I create two windows, and use a window delegate to make sure that whenever the first is fullscreened, its menubar and dock are hidden properly. However, when I fullscreen the first window and go back to the desktop to see my second window, the second window's minimize button is grayed out and using miniaturize on it will not work either. I've tried various things; it seems like if I fullscreen the second window and the unfullscreen it, it then becomes minimizable without additional side effects. Is there any reason why this is happening? This seems like a bug in AppKit... so how do I work around it programmatically? #import <Cocoa/Cocoa.h> @interface AppDelegate : NSObject <NSApplicationDelegate, NSWindowDelegate> @property (strong) NSWindow *mainWindow; @property (strong) NSWindow *secondaryWindow; @end @implementation AppDelegate - (void)applicationDidFinishLaunching:(NSNotification *)aNotification { NSRect mainRect = NSMakeRect(100, 300, 400, 300); self.mainWindow = [[NSWindow alloc] initWithContentRect:mainRect styleMask:(NSWindowStyleMaskTitled | NSWindowStyleMaskClosable | NSWindowStyleMaskMiniaturizable | NSWindowStyleMaskResizable) backing:NSBackingStoreBuffered defer:NO]; [self.mainWindow setTitle:@"Main Window (Go Fullscreen Here)"]; [self.mainWindow setDelegate:self]; NSTextField *mainLabel = [NSTextField labelWithString:@"1. Click the green zoom/fullscreen button on THIS window.\n\n2. Look at the other window's yellow minimize button."]; [mainLabel setFrame:NSMakeRect(20, 100, 360, 100)]; [[self.mainWindow contentView] addSubview:mainLabel]; [self.mainWindow makeKeyAndOrderFront:nil]; NSRect secondaryRect = NSMakeRect(550, 300, 400, 300); self.secondaryWindow = [[NSWindow alloc] initWithContentRect:secondaryRect styleMask:(NSWindowStyleMaskTitled | NSWindowStyleMaskClosable | NSWindowStyleMaskMiniaturizable | NSWindowStyleMaskResizable) backing:NSBackingStoreBuffered defer:NO]; [self.secondaryWindow setTitle:@"Secondary Window (The Victim)"]; NSButton *testButton = [NSButton buttonWithTitle:@"Try code [window miniaturize:]" target:self action:@selector(attemptProgrammaticMinimize:)]; [testButton setFrame:NSMakeRect(80, 130, 240, 40)]; [[self.secondaryWindow contentView] addSubview:testButton]; [self.secondaryWindow makeKeyAndOrderFront:nil]; } - (NSApplicationPresentationOptions)window:(NSWindow *)window willUseFullScreenPresentationOptions:(NSApplicationPresentationOptions)proposedOptions { return NSApplicationPresentationFullScreen | NSApplicationPresentationHideMenuBar | NSApplicationPresentationHideDock; } - (void)attemptProgrammaticMinimize:(id)sender { [self.secondaryWindow miniaturize:nil]; NSLog(@"[Repro] Minimize attempted"); } - (BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication *)sender { return YES; } @end int main(int argc, const char * argv[]) { @autoreleasepool { NSApplication *app = [NSApplication sharedApplication]; [app setActivationPolicy:NSApplicationActivationPolicyRegular]; AppDelegate *delegate = [[AppDelegate alloc] init]; [app setDelegate:delegate]; [app activateIgnoringOtherApps:YES]; [app run]; } return 0; }
3
0
829
Aug ’26
Full keyboard access blocks NSTextField from being the initial first responder in NSPopover
I'm working on this UI where I present a popover and user fills in some brief information. There are various buttons and a single editable text field in the UI. When 'Full Keyboard access' is disabled in System Settings and the popover is presented the editable NSTextField is the initial first responder and the user can begin typing immediately. This is the behavior that I expect and want. Now when full keyboard access is enabled the text field does not become the immediate first responder (and none of the buttons in the popover have 'focus' state either) so initially hitting a key does nothing. To me this feels unnatural and is not the expected behavior. To interact with the text field with full keyboard access I have to do one of the following: Use the mouse to click the text field (which is an extra step). Or Press tab several times to move 'Focus' (initially no button has it) all the way down to the textfield. Both requirements slow down the user. Is this expected behavior? Shouldn't the initial key view follow the natural first responder (in this case an editable text field) and the user can tab away from that starting location? instead nobody has key focus when the popover is first presented until tabbing is initiated. I can currently 'workaround' this it seems by manually setting the text field as first responder in viewDidAppear [self.view.window makeFirstResponder:self.theTextField]; Then the text field accepts keyboard input immediately. But when 'Full keyboard access' is disabled (which I assume is the more typical configuration) this is not required, the text field just gets first responder by default. If this is not the expected behavior let me know and I may file a feedback.
0
0
312
Aug ’26
NSSplitViewController-like inspector in custom view
From the currently available information, it seems like the only way to get the new-in-Tahoe sidebar inspector effect is to use a NSSplitView in conjunction with NSSplitviewController & inspectorWithViewController:. I'm currently trying to get the same inspector effect - which also affects the looks of controls inside the inspector, like text fields, which switch to a gray-ish background - in a totally custom splitter-like view hierarchy that is way more complex than NSSplitView and thus cannot inherit or take advantage of it. Is there a way to integrate this effect in a custom view? Maybe using NSVisualEffectView or NSGlassEffectView?
1
0
475
Jul ’26
SwiftUI animation is laggy in NSStatusItem since macOS 26 Tahoe
My app is a bit of a special case and relies on a custom view in a NSStatusItem. I use a NSHostingView and add it as a subview to my NSStatusItem's .button property. Since macOS 26 Tahoe, even simple animations like a .frame change of a Circle won't animate smoothly even though the same SwiftUI animates normally in a WindowGroup. class AppDelegate: NSObject, NSApplicationDelegate { private let statusItem: NSStatusItem = NSStatusBar.system.statusItem(withLength: NSStatusItem.variableLength) func applicationDidFinishLaunching(_ aNotification: Notification) { let subview = NSHostingView(rootView: AnimationView()) let view = self.statusItem.button view?.addSubview(subview) subview.translatesAutoresizingMaskIntoConstraints = false guard let view = view else { return } NSLayoutConstraint.activate([ subview.centerXAnchor.constraint(equalTo: view.centerXAnchor), subview.centerYAnchor.constraint(equalTo: view.centerYAnchor), subview.widthAnchor.constraint(equalToConstant: 22), subview.heightAnchor.constraint(equalToConstant: 22) ]) } } struct AnimationView: View { @State private var isTapped = false @State private var size: CGSize = .init(width: 4, height: 4) var body: some View { Circle() .fill(.pink) .frame(width: size.width, height: size.height) .frame(width: 20, height: 20) // .frame(maxHeight: .infinity) // .padding(.horizontal, 9) // .frame(height: 22) .contentShape(Rectangle()) // .background(Color.blue.opacity(0.5)) .onTapGesture { withAnimation(.interactiveSpring(response: 0.85, dampingFraction: 0.26, blendDuration: 0.45)) { // withAnimation(.spring()) { if isTapped { size = .init(width: 4, height: 4) } else { size = .init(width: 16, height: 16) } } isTapped.toggle() }} } Example project: https://app.box.com/s/q28upunrgkxyyd97ovslgud9yitqaxfk
1
0
504
Jul ’26
NSTrackingSeparatorToolbarItem causes white bar over top of content in macOS 27 developer beta 5
macOS 27 developer beta 5 introduces a bug where an NSTrackingSeparatorToolbarItem in a toolbar causes a bar to appear under the toolbar, overlaying the content. I have a blog post about this at: https://www.virtualsanity.com/202608/nstrackingseparatortoolbaritem-causes-white-bar-over-top-of-content-in-macos-27-developer-beta-5/ I reported this as FB24266969. A sample project and a screenshot are included in both the blog post and the feedback report.
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
7
Boosts
1
Views
588
Activity
9h
Bug or Feature: Changes to Window Reopen Behavior in macOS 26
Since macOS 26 Beta 1, I notice that the window reopening behavior had changed. Say there are two desktops (spaces), one might: open an app window in desktop 1 close that window switch to desktop 2 reopen the app window (by click on dock tile, spotlight search...) Prior to macOS 26, that window will always reopen in current desktop. This is IMO the right behavior because these windows are most likely transient (message app, chat app, utilities app or note app). In macOS 26, however, will switch to desktop 1 (where the window is closed) and reopen the window in desktop 1. This is weird to me because: Window is "closed", hence it should not be attached to desktop 1 anymore, unlike minimize. Switching desktop interrupts user's current workflow. It's annoying to switch back specially when there're many desktops. This behavior is inconsistent. Some reopen in current desktop, some reopen in previous desktop. Apps like Music, Notes and Calendar reopened in previous desktop, while Mail, Messages, and Freeform reopened in current desktop. I did a little bit of experiment, and find out that apps that reopened in current desktop are most likely because they take an extra step to release the window when it's closed. I believe this is a bug, so I fire a feedback (FB18016497) back in beta 1. But I did not get any response or similar report from others, to a point that I kinda wonder if this is intended. I can easily force my app to reopen in current desktop by nullifying my window controller in windowWillClose, but this behavior essentially change how one can use the Spaces feature that I think I should bring this up to the community and see what other developers or engineers thinks about it.
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
5
Boosts
1
Views
559
Activity
1d
# SwiftUI `Document` app hangs on macOS 27 when another process changes its file
On macOS 27.0 (26A428) with Xcode 27.0, Apple's unmodified sample Building a document-based app with SwiftUI stops responding permanently when another process replaces an open document's file through NSFileCoordinator. AppKit reverts the document on the main thread, which then blocks in a semaphore wait inside SwiftUI: -[NSDocument relinquishPresentedItemToWriter:]_block_invoke_8 (in AppKit) -[NSDocument _revertToVersion:preservingFirst:error:] (in AppKit) -[NSDocument revertToContentsOfURL:ofType:error:] (in AppKit) URLPlatformDocument.read(from:ofType:) (in SwiftUI) _dispatch_semaphore_wait_slow (in libdispatch.dylib) No other thread is reading the document. In another app using Document, its DocumentReader was never called, and a document with unsaved changes hung the same way in URLPlatformDocument.write(to:ofType:for:originalContentsURL:). Reproduction (the sample plus a short script): https://github.com/DePasqualeOrg/swiftui-document-revert-hang Feedback report: FB24792850
Replies
0
Boosts
0
Views
128
Activity
2d
Spotlight Shows "Helper Apps" That Are Inside Main App Bundle That Are Not Intended to Be Launched By The User
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.
Replies
8
Boosts
0
Views
760
Activity
2d
Title bar double-click / Fill on macOS 27
I’m seeing a reproducible title-bar interaction issue on macOS 27 RC (26A428). This issue has been present since at least macOS 27 build 26A5416b (Developer Beta 6 / Public Beta 4) and is still reproducible on the Release Candidate, build 26A428. My System Settings → Desktop & Dock → Window title bar double-click action is configured to Fill. In several system apps with sidebars, including: Finder System Settings Reminders Feedback Assistant the right side of the title bar shows a visible rectangular region when the pointer hovers over it. The more important problem is that the middle portion of this region appears to intercept the title-bar double-click. Double-clicking there does nothing, while double-clicking very close to the top or bottom edge of the same region correctly triggers Fill. This makes the normal title-bar gesture surprisingly difficult to use because the center of the title bar is naturally where I would double-click. Interestingly, the sidebar area does not have this problem: double-clicking the top, middle, or bottom portions of the sidebar title-bar area all works normally. Feedback Assistant makes the behavior particularly easy to see because its left sidebar and rightmost pane behave normally, while the title-bar region above the middle pane exhibits the problem. Steps to reproduce: Set “Double-click a window’s title bar” to Fill in Desktop & Dock settings. Open Finder, System Settings, Reminders, or Feedback Assistant. Move the pointer over the right/content portion of the title bar until the rectangular hover region appears. Double-click around the center of that region. The Fill action does not occur. Double-click very close to the upper or lower edge of the same region. Fill works normally. I have reproduced this on macOS 27 RC build 26A428, including: a newly created macOS user account Safe Mode so it does not appear to be caused by migrated preferences, caches, login items, or third-party software. A screen recording demonstrating the exact hit-testing behavior was submitted through Feedback Assistant. Feedback: FB24462749 Is anyone else able to reproduce this? It looks as though some view or overlay in the new title-bar/toolbar area may be intercepting mouse events.
Replies
1
Boosts
0
Views
159
Activity
1w
NSColorSampler can leave ColorSampler.xpc capturing all mouse clicks after the host app quits
I encountered a severe NSColorSampler failure on macOS 27.0 (26A5425a). After invoking: NSColorSampler().show { selectedColor in // Handle selected colour } the system colour sampler became stuck. The pointer disappeared and all mouse clicks were captured across macOS. Pressing Escape did not recover it. Quitting the host application also did not restore clicking. The Apple-owned process remained active after the application exited: /System/Library/Frameworks/AppKit.framework/Versions/C/XPCServices/ColorSampler.xpc/Contents/MacOS/ColorSampler Sending SIGTERM to that process had no effect. Force-terminating it with SIGKILL immediately restored mouse clicking. Environment: macOS 27.0, build 26A5425a MacBook Pro Mac16,8 Apple M4 Pro SwiftUI content hosted inside a borderless AppKit window Expected behaviour: selecting a colour, pressing Escape, or terminating the host application should cancel sampling and release all captured input. Actual behaviour: ColorSampler.xpc survives the host application and continues preventing all mouse clicks system-wide. Feedback Assistant report: FB24722293 Has anyone else reproduced this with NSColorSampler, particularly from a borderless AppKit window?
Replies
0
Boosts
0
Views
306
Activity
1w
crash when trying to show NSAlert with Mac 27 beta with European and russian languages
Feedback Assistant Submission ID Reference : FB24634485 Attached is a sample code where after setting setlocale() to any of European languages or Russian language results in crash when calling NSAlert. Here is code snippet and crash log for reference. #import <Cocoa/Cocoa.h> int main(int argc, const char * argv[]) { @autoreleasepool { NSString* locale = @“fr_FR.UTF8"; setlocale(LC_ALL, locale.UTF8String); return NSApplicationMain(argc, argv); } } (IBAction)showAlertButtonTapped:(id)sender { NSAlert *alert = [[NSAlert alloc] init]; alert.messageText = NSLocalizedString(@"alert_title", nil); alert.informativeText = NSLocalizedString(@"alert_message", nil); alert.alertStyle = NSAlertStyleInformational; [alert addButtonWithTitle:NSLocalizedString(@"alert_ok_button", nil)]; [alert runModal]; } Crashlog
Replies
0
Boosts
0
Views
99
Activity
1w
Where’s the path of Objective-C runtime
Hi systems programming guys. I’m exploring the macOS as a low-level itself, so when I use the otool(1) utility to inspect a tiny objc helloworld program, it told me that there is a shared library like /usr/lib/libobjc.A.dylib (not identical) but I didn’t find that in path /usr/lib/. Also the docs sucked (see below). I want to know more details about the objc runtime on macOS (beta 27.6 +) and be seeking for help here because there are few materials online and not even to say the sucked AI. The prima motivation is the runtime itself and how it works. Of course I would love to read disassembled code and manpages or using utilities that Apple offered to understand those things . But I really don’t know where is the runtime if both docs and otool output lied. The latest documentation about Objective-C Runtime is outdate and it said “Objective-C runtime library support functions are implemented in the shared library found at /usr/lib/libobjc.A.dylib.”
Replies
7
Boosts
0
Views
795
Activity
2w
NSTextView Weird Selection Behavior with NSTextAttachmentCells
I have an NSTextView that displays several NSTextAttachmentCells. I notice this weird behavior. Sometimes if I just click in an empty area of the text view the entire text content selects. So I implemented the delegate method to catch it: - (NSRange)textView:(NSTextView *)textView willChangeSelectionFromCharacterRange:(NSRange)oldSelectedCharRange toCharacterRange:(NSRange)newSelectedCharRange { if (newSelectedCharRange.length > 1 && newSelectedCharRange.length > oldSelectedCharRange.length) { NSEvent *currentEvent = NSApp.currentEvent; NSLog(@"Selection expanded from %@ to %@. Event type: %ld, click count: %ld, modifier flags: %lu, current selected ranges: %@", NSStringFromRange(oldSelectedCharRange), NSStringFromRange(newSelectedCharRange), (long)currentEvent.type, (long)currentEvent.clickCount, (unsigned long)currentEvent.modifierFlags, self.selectedRanges); // put a break point here. } return newSelectedCharRange; } And I reproduced the issue and this logs out: Selection expanded from {0, 0} to {0, 6}. Event type: 2, click count: 1, modifier flags: 0, current selected ranges: ( "NSRange: {0, 6} Click count is only 1 so I didn't accidentally triple click. I know on Golden Gate use of NSEvent.currentEvent isn't the way (but I'm not there yet). A simple workaround would be to block the selection right here in the delegate method when clickCount != 3 (but again I know NSEvent.currentEvent in Golden Gate won't be reliable). Anyone run into this and have any ideas? It seems to happen after I did a triple click in the text view at some point previously (but not this click). So I got the feeling that maybe the text view isn't resetting some private properties and is treating this single click as a triple click. But I really don't know. Edit: Hmm maybe it has nothing to do with a previous triple click. May have to do with text selection not accounting for the geometry of the NSTextAttachmentCells. Not sure. But I still have to figure out a way to workaround this because a random select all is really annoying! Call stack looks like: ** -[MyTextView textView:willChangeSelectionFromCharacterRange:toCharacterRange:] at MyTextView.m -[NSTextView(NSSharing) setSelectedRanges:affinity:stillSelecting:] () -[MyTextView setSelectedRanges:affinity:stillSelecting:] MyTextView.m +[NSInputAnalytics(TrackedActionsManager) allowActionTrackingAnalyticsWithName:forAction:] () n -[NSTextView mouseDown:] () -[MyTextView mouseDown:] ** If you're wondering what my -mouseDown: override does it just calls super. I realize this is not a whole lot to go on but any help would be appreciated.
Replies
5
Boosts
0
Views
582
Activity
3w
SFAuthorizationPluginView UI changes in macOS Golden Gate Beta – Unable to access the child elements and button controls using NSAccessibilityProtocol
We have observed significant UI changes to the SFAuthorizationPluginView login experience in the latest macOS Golden Gate Beta 5. After entering the account password at the SFAuthorizationPluginView screen, we were previously able to access the buttons and other child elements present in the SFAuthorizationPluginView using "accessibilityChildrenInNavigationOrder" . Currently the method returns that there are no child elements eventhough there are clearly child elements presents including apple's native Ok and Cancel buttons.This behaviour is consistently reproducible in our testing. Steps to Reproduce Configure and launch an unlock authorization plug-in using SFAuthorizationPluginView. Display the authorization UI in unlock. Enter the account password. Wait for the authorization UI to finish transitioning to the authenticated state. Query the SFAuthorizationPluginView accessibility hierarchy. Specifically query accessibilityChildrenInNavigationOrder. Observe that the method returns no child accessibility elements. Inspect the UI visually or using Accessibility Inspector and observe that child controls are still present, including the native OK and Cancel buttons. We would like to understand: 1.Is this a known issue with the current macOS Golden Gate Beta? 2.Is this expected behaviour due to the UI redesign, or is it considered a bug? 3.If it is a known issue, is there a fix planned for an upcoming beta or the final release? Any information or guidance would be appreciated. Thank you.
Replies
5
Boosts
1
Views
435
Activity
4w
Vertically Off-Center Components in NSSearchToolbarItem in macOS 27 Developer Beta 5
In macOS 27 developer beta 5, search fields in toolbars (NSSearchToolbarItem instances) have their placeholder text, search strings, and magnifying glass icons vertically off-center. I reported this as FB24286690. You can see this in the Feedback Assistant app. The “Search” placeholder text, the magnifying glass, and the search string are all closer to the top of the toolbar item than the bottom. My feedback has a sample project demonstrating this, along with screenshots. I have a more detailed writeup at: https://www.virtualsanity.com/202608/vertically-off-center-components-in-nssearchtoolbaritem-in-macos-27-developer-beta-5/
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
0
Boosts
0
Views
207
Activity
Aug ’26
Various menu bar NSStatusItem issues with macOS 27
It seems like macOS 27 beta 2 has some issues with NSStatusItem buttons added to the menu bar - this creates difficulties for some menu bar extra apps. NSStatusItem buttons does not receive mouse hover/movement events - FB23329983 On macOS 27, views inside an NSStatusItem button no longer receive hover or mouse-movement events. The same code works correctly on macOS 26. What I tried: An NSTrackingArea attached to a subview of NSStatusBarButton An NSTrackingArea attached directly to the status-bar button Replacing NSStatusItem.view with a custom view Embedding an NSHostingView and using SwiftUI onHover/onContinuousHover NSStatusItem button highlight cannot be set programmatically. - FB23330269 The following code no longer has any effect (does not provide the highlight capsule): NSStatusItem.button?.highlight(true) NSStatusItem window occlusionState no longer reflects hidden menu bar visibility - FB23349447 The following no longer works: statusItem.button?.window?.occlusionState.contains(.visible) These changes may be related to some of the touch related changes or maybe it's about how menu items are now seemingly more "managed" in a way that their position, visibility may change in a way that is transparent/undetectable to the app.
Replies
6
Boosts
2
Views
985
Activity
Aug ’26
NSSearchToolbarItem cancel button triggers action before clearing text and before the ending search notification
I am trying to use an NSSearchToolbarItem using AppKit directly in Objective-C. If I perform a search and then click the cancel icon, my target/action is called while the NSSearchField still contains the search text (not yet cleared) and the delegate has not yet received the ending search invocation. In other words, it looks exactly the same as if the user had submitted the same search twice. Google's AI suggested using the controlTextDidChange method, but that was deprecated long ago. My current solution is to ignore searches that appear redundant (although they may not be, if the data being searched changes). This is on macOS 26.6.
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
0
Boosts
0
Views
432
Activity
Aug ’26
Guideline 4 rejection — Unity macOS app: missing App Menu, title bar buttons, and Dock icon
I'm distributing a Unity-built game on the Mac App Store and I've been rejected twice under Guideline 4 (Design) with the same wording: "We still noticed that the app presents a window that does not contain the necessary title bar buttons and includes an interface window but is missing the required App Menu and Dock Icon or Menu Bar Extra." I'd like to hear from anyone who has hit this with a Unity (or otherwise non-native) macOS app and got it resolved. What I'm seeing: When the game runs, the macOS menu bar is displayed, but it only shows the app name and a single "Window" menu. The standard menus Apple expects (App menu with About/Quit, Edit, Window, Help) are not there. Unity does not populate the native macOS menu bar on its own, and there's no Player Setting that generates these menus. What I've already tried: Switched the app from borderless window to a standard windowed mode, so the window has its title bar and close/minimize/zoom buttons. Confirmed the Dock icon appears with the running indicator in standard windowed mode. Verified there is no LSUIElement key forcing the app into accessory mode in Info.plist. Despite this, the rejection came back identical. My questions: For those who passed review, did you populate the full native menu bar (App / Edit / Window / Help), or did Apple accept the app another way? Is a complete standard menu bar strictly required, or does shipping the app in fullscreen — where macOS hides the menu bar by design, as with most Mac games — satisfy the reviewer on this point? For the "title bar buttons" and "Dock icon" part of the rejection specifically: what exactly does the reviewer expect to see, and does fullscreen change how they evaluate it? If you resolved this, did you mention the change in the App Review notes, and did that help? Any concrete experience — especially with games that launch fullscreen — would be very helpful. Thanks.
Replies
0
Boosts
0
Views
172
Activity
Aug ’26
Using AppKit and Core Graphics within a CUPS filter context on macOS
Hello, I am currently developing a printed data security feature for a cross-platform DLP system. On other platforms, this functionality relies on a cross-platform third-party library. On macOS, this library depends on the Core Graphics and AppKit frameworks. So, such dependency makes it impossible to use the code within a launch daemon, which is where this mechanism needs to run. As an alternative approach, I am considering implementing the necessary functionality inside a CUPS filter. However, I have some doubts regarding the execution context of the CUPS filter process. Is it safe to use AppKit within a CUPS filter? Thank you in advance.
Replies
0
Boosts
0
Views
465
Activity
Aug ’26
window:willUseFullScreenPresentationOptions: with NSApplicationPresentationHideDock causes other windows to be unminimizable
In the below code, I create two windows, and use a window delegate to make sure that whenever the first is fullscreened, its menubar and dock are hidden properly. However, when I fullscreen the first window and go back to the desktop to see my second window, the second window's minimize button is grayed out and using miniaturize on it will not work either. I've tried various things; it seems like if I fullscreen the second window and the unfullscreen it, it then becomes minimizable without additional side effects. Is there any reason why this is happening? This seems like a bug in AppKit... so how do I work around it programmatically? #import <Cocoa/Cocoa.h> @interface AppDelegate : NSObject <NSApplicationDelegate, NSWindowDelegate> @property (strong) NSWindow *mainWindow; @property (strong) NSWindow *secondaryWindow; @end @implementation AppDelegate - (void)applicationDidFinishLaunching:(NSNotification *)aNotification { NSRect mainRect = NSMakeRect(100, 300, 400, 300); self.mainWindow = [[NSWindow alloc] initWithContentRect:mainRect styleMask:(NSWindowStyleMaskTitled | NSWindowStyleMaskClosable | NSWindowStyleMaskMiniaturizable | NSWindowStyleMaskResizable) backing:NSBackingStoreBuffered defer:NO]; [self.mainWindow setTitle:@"Main Window (Go Fullscreen Here)"]; [self.mainWindow setDelegate:self]; NSTextField *mainLabel = [NSTextField labelWithString:@"1. Click the green zoom/fullscreen button on THIS window.\n\n2. Look at the other window's yellow minimize button."]; [mainLabel setFrame:NSMakeRect(20, 100, 360, 100)]; [[self.mainWindow contentView] addSubview:mainLabel]; [self.mainWindow makeKeyAndOrderFront:nil]; NSRect secondaryRect = NSMakeRect(550, 300, 400, 300); self.secondaryWindow = [[NSWindow alloc] initWithContentRect:secondaryRect styleMask:(NSWindowStyleMaskTitled | NSWindowStyleMaskClosable | NSWindowStyleMaskMiniaturizable | NSWindowStyleMaskResizable) backing:NSBackingStoreBuffered defer:NO]; [self.secondaryWindow setTitle:@"Secondary Window (The Victim)"]; NSButton *testButton = [NSButton buttonWithTitle:@"Try code [window miniaturize:]" target:self action:@selector(attemptProgrammaticMinimize:)]; [testButton setFrame:NSMakeRect(80, 130, 240, 40)]; [[self.secondaryWindow contentView] addSubview:testButton]; [self.secondaryWindow makeKeyAndOrderFront:nil]; } - (NSApplicationPresentationOptions)window:(NSWindow *)window willUseFullScreenPresentationOptions:(NSApplicationPresentationOptions)proposedOptions { return NSApplicationPresentationFullScreen | NSApplicationPresentationHideMenuBar | NSApplicationPresentationHideDock; } - (void)attemptProgrammaticMinimize:(id)sender { [self.secondaryWindow miniaturize:nil]; NSLog(@"[Repro] Minimize attempted"); } - (BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication *)sender { return YES; } @end int main(int argc, const char * argv[]) { @autoreleasepool { NSApplication *app = [NSApplication sharedApplication]; [app setActivationPolicy:NSApplicationActivationPolicyRegular]; AppDelegate *delegate = [[AppDelegate alloc] init]; [app setDelegate:delegate]; [app activateIgnoringOtherApps:YES]; [app run]; } return 0; }
Replies
3
Boosts
0
Views
829
Activity
Aug ’26
Full keyboard access blocks NSTextField from being the initial first responder in NSPopover
I'm working on this UI where I present a popover and user fills in some brief information. There are various buttons and a single editable text field in the UI. When 'Full Keyboard access' is disabled in System Settings and the popover is presented the editable NSTextField is the initial first responder and the user can begin typing immediately. This is the behavior that I expect and want. Now when full keyboard access is enabled the text field does not become the immediate first responder (and none of the buttons in the popover have 'focus' state either) so initially hitting a key does nothing. To me this feels unnatural and is not the expected behavior. To interact with the text field with full keyboard access I have to do one of the following: Use the mouse to click the text field (which is an extra step). Or Press tab several times to move 'Focus' (initially no button has it) all the way down to the textfield. Both requirements slow down the user. Is this expected behavior? Shouldn't the initial key view follow the natural first responder (in this case an editable text field) and the user can tab away from that starting location? instead nobody has key focus when the popover is first presented until tabbing is initiated. I can currently 'workaround' this it seems by manually setting the text field as first responder in viewDidAppear [self.view.window makeFirstResponder:self.theTextField]; Then the text field accepts keyboard input immediately. But when 'Full keyboard access' is disabled (which I assume is the more typical configuration) this is not required, the text field just gets first responder by default. If this is not the expected behavior let me know and I may file a feedback.
Replies
0
Boosts
0
Views
312
Activity
Aug ’26
NSSplitViewController-like inspector in custom view
From the currently available information, it seems like the only way to get the new-in-Tahoe sidebar inspector effect is to use a NSSplitView in conjunction with NSSplitviewController & inspectorWithViewController:. I'm currently trying to get the same inspector effect - which also affects the looks of controls inside the inspector, like text fields, which switch to a gray-ish background - in a totally custom splitter-like view hierarchy that is way more complex than NSSplitView and thus cannot inherit or take advantage of it. Is there a way to integrate this effect in a custom view? Maybe using NSVisualEffectView or NSGlassEffectView?
Replies
1
Boosts
0
Views
475
Activity
Jul ’26
SwiftUI animation is laggy in NSStatusItem since macOS 26 Tahoe
My app is a bit of a special case and relies on a custom view in a NSStatusItem. I use a NSHostingView and add it as a subview to my NSStatusItem's .button property. Since macOS 26 Tahoe, even simple animations like a .frame change of a Circle won't animate smoothly even though the same SwiftUI animates normally in a WindowGroup. class AppDelegate: NSObject, NSApplicationDelegate { private let statusItem: NSStatusItem = NSStatusBar.system.statusItem(withLength: NSStatusItem.variableLength) func applicationDidFinishLaunching(_ aNotification: Notification) { let subview = NSHostingView(rootView: AnimationView()) let view = self.statusItem.button view?.addSubview(subview) subview.translatesAutoresizingMaskIntoConstraints = false guard let view = view else { return } NSLayoutConstraint.activate([ subview.centerXAnchor.constraint(equalTo: view.centerXAnchor), subview.centerYAnchor.constraint(equalTo: view.centerYAnchor), subview.widthAnchor.constraint(equalToConstant: 22), subview.heightAnchor.constraint(equalToConstant: 22) ]) } } struct AnimationView: View { @State private var isTapped = false @State private var size: CGSize = .init(width: 4, height: 4) var body: some View { Circle() .fill(.pink) .frame(width: size.width, height: size.height) .frame(width: 20, height: 20) // .frame(maxHeight: .infinity) // .padding(.horizontal, 9) // .frame(height: 22) .contentShape(Rectangle()) // .background(Color.blue.opacity(0.5)) .onTapGesture { withAnimation(.interactiveSpring(response: 0.85, dampingFraction: 0.26, blendDuration: 0.45)) { // withAnimation(.spring()) { if isTapped { size = .init(width: 4, height: 4) } else { size = .init(width: 16, height: 16) } } isTapped.toggle() }} } Example project: https://app.box.com/s/q28upunrgkxyyd97ovslgud9yitqaxfk
Replies
1
Boosts
0
Views
504
Activity
Jul ’26