Apple’s own macOS onscreen Keyboard Viewer also suffers from the same problem, where simulating the combination of Fn + Control + directional keys behaves incorrectly, further confirming this as a bug in the event handling system. Steps to Reproduce: Open the macOS onscreen Keyboard Viewer. Press the combination Fn (Globe) + Control + C and observe the correct window management behavior (the key window beneath will position to the center). The appropriate menu item Window → Center will flash and highlight. Now try to simulate the key combo Fn + Control + Right Arrow (corresponding to the menu item Window → Move & Resize → Right). The expected behavior is that the key window should move and resize to the right half of the screen, but it doesn’t. Filed under FB15532267

I think I’ve found where the problem is. It looks like .maskSecondaryFn in CGEventFlags corresponds to 0xFF0100000030, but the usage ID from IOHID for real hardware Fn (Globe) key is 0xFF00000003. This mismatch is likely causing the problem during key simulation. The question now is: how can this lower-level hex code be used for the purpose of simulating key presses?

The Xcode 16 Highlights page states: “Swift Assist is coming later this year.” So sometime within the next ~1800 hours.

I’ve reverse engineered the macOS inner rim stroke color used for windows, popovers, menus, etc., and the value appears to be … Color(red: 26 / 255, green: 26 / 255, blue: 26 / 255).blendMode(.plusLighter) … which corresponds to the NSColor.gridColor value in dark mode. In usage: .background(.ultraThinMaterial.materialActiveAppearance(.active)) .overlay { RoundedRectangle(cornerRadius: 16) .strokeBorder(Color(red: 26 / 255, green: 26 / 255, blue: 26 / 255) .blendMode(.plusLighter)) } I hope this will be of use to someone in the future.

All I need is a nudge in the right direction. This problem is a showstopper for the project I’m currently working on.

I made adjustments to the example code since the original had leftover elements from experimentation. import SwiftUI @main struct LittleKeypressDemo: App { var body: some Scene { Window("Keypress Demo", id: "keypress-demo") { ContentView() } .windowStyle(.hiddenTitleBar) .windowResizability(.contentSize) .windowBackgroundDragBehavior(.enabled) } } struct ContentView: View { var body: some View { VStack { KeyPressButton( icon: "arrowtriangle.right.fill", keyCode: 124, eventFlags: [.maskSecondaryFn, .maskControl] ) KeyPressButton( label: "C", keyCode: 8, eventFlags: [.maskSecondaryFn, .maskControl] ) KeyPressButton( icon: "arrow.down.to.line", keyCode: 119, eventFlags: [ /* .maskSecondaryFn, */ .maskControl] ) } .padding() } } struct KeyPressButton: View { let icon: String? let label: String? let keyCode: CGKeyCode let eventFlags: CGEventFlags init( icon: String? = nil, label: String? = nil, keyCode: CGKeyCode, eventFlags: CGEventFlags ) { self.icon = icon self.label = label self.keyCode = keyCode self.eventFlags = eventFlags } var body: some View { Button(action: { simulateKeyPress(keyCode: keyCode, eventFlags: eventFlags) }) { HStack { if eventFlags.contains(.maskSecondaryFn) { Image(systemName: "globe") } if eventFlags.contains(.maskControl) { Image(systemName: "control") } if let icon = icon { Image(systemName: icon) } else if let label = label { Text(label) } } } .controlSize(.large) } } func simulateKeyPress(keyCode: CGKeyCode, eventFlags: CGEventFlags) { guard let eventDown = CGEvent( keyboardEventSource: nil, virtualKey: keyCode, keyDown: true ), let eventUp = CGEvent( keyboardEventSource: nil, virtualKey: keyCode, keyDown: false ) else { print("Error creating CGEvent for keyCode \(keyCode)") return } eventDown.flags = eventFlags eventUp.flags = eventFlags eventDown.post(tap: .cghidEventTap) eventUp.post(tap: .cghidEventTap) }

In essence, I would be grateful if those in the know could provide me with the precise name of the color, material, or blend mode value employed for the border.

Have you by any chance found a solution?

If you attempt to remove all commands using .commandsRemoved(), then add back only the necessary ones using .commandsReplaced { CommandGroup(replacing: .help, addition: {}) }, such as .appInfo, .appVisibility, .appTermination, etc., the AppName menu will still remain empty.

Four years after the introduction of SwiftUI, the framework still lacks a clean, straightforward, idiomatic way to remove the default system CommandMenu top-level containers – specifically, File, Edit, and View. Scenario 1: a utility app is designed to disable the zoom button and full-screen mode, doesn’t use tab bar, toolbar or sidebar – the View menu will be empty upon build. Despite this, the View menu remains visible even though it’s completely empty. This is clearly a bug. Scenario 2: a utility app lacks text entry, and has no need for undo/redo or copy/paste, the Edit menu becomes unnecessary. However, the operating system automatically injects Autofill, Start Dictation, and Emoji & Symbols submenus and commands into the Edit menu. Another clear bug. Scenario 3: when using Window instead of WindowGroup to present a Scene in a single, unique app window, macOS still provides a Minimize All option if you hold the Option key while clicking on the Window menu, even though the app has, and can only ever have a single window. Although the zoom command is intentionally disabled as mentioned above, it becomes re-enabled as Zoom All when the Option key is held while clicking on Window menu. This is not a bug. This is carelessness. Why is there a File menu in the System Settings app, which doesn’t deal with files (saving, exporting, printing, etc.)? More perplexing is the presence of a Close All command when the Option key is held down and the File menu is clicked. A complete lack of attention to detail and quality control on Apple’s part.

Btw, I’m aware of the new .commandsRemoved(), available since macOS 13, but that apparently removes all menus.

Since the state of the above mentioned setting isn’t persistent between macOS restarts, we need to apply it every time at login (as long as user has enabled this preference). Can we have a background daemon that starts at login in order to apply a setting (daemon is immediately terminated afterword)? Or is it necessary for Mac App Store distribution to have the full main app always launch? ⠀ Is that a typo? ‘cause I figured that all the checkboxes in your app were important (-: I think I choose words intentionally ;-)