name thatuiuser interface
MenuBarExtraSwiftUI
=
NSStatusItemAppKit

Same pixel on screen, two real names — which one you say depends on the project

AppKit vs SwiftUI

/ NSButton · Button /

AppKit is the Mac’s original toolbox — a workshop where you pick up each part (a window, a button, a menu) and tell it exactly what to do. Its names start with NS: NSWindow, NSMenu, NSStatusItem.

SwiftUI is Apple’s newer way: instead of assembling parts, you describe the finished room — “a sidebar, then a list, then this button” — and the system builds and updates it. Same elements on screen, plainer names: Button, Menu, MenuBarExtra.

They’re not two kinds of app — one Mac app can (and usually does) mix both. Which means the thing you’re pointing at almost always has two valid names, and using the right one makes your agent dramatically more precise.

Which name do I say? — three rules

  1. 1

    Match the project. Files say import SwiftUI and views are structs? Use SwiftUI names. NS-classes and import AppKit? Use AppKit names.

  2. 2

    In a mixed app, name the layer. “The SwiftUI view inside the AppKit window”, “the NSPanel presented from my SwiftUI app.” The boundary is where agents get lost.

  3. 3

    When unsure, give both. “The menu bar extra (SwiftUI: MenuBarExtra / AppKit: NSStatusItem)” — the agent inspects the project and picks the right one.

Worked prompts — paste into your agent

SwiftUI project

In this macOS SwiftUI app, make the MenuBarExtra open a popover-style window, and keep the menu bar extra visible when the main window closes.

AppKit project

In this AppKit macOS app, update the NSStatusItem in NSStatusBar.system: its button should use a template image and show an NSMenu when clicked.

Not sure which

Fix the little app icon beside the Mac clock — the menu bar extra (SwiftUI: MenuBarExtra, AppKit: NSStatusItem). Inspect the project and change the existing implementation, don't add a second one.

Don’t confuse them with

UIKitApple's framework for iPhone and iPad — UIButton, not NSButton. Not for Mac-only apps.
Mac CatalystAn iPad app wearing a Mac coat. It runs UIKit on the Mac; it isn't AppKit or SwiftUI.
ElectronA web page in a desktop wrapper (Chromium + Node). Its UI vocabulary is the Web tab of this site.

The questions everyone asks

Is SwiftUI replacing AppKit?

Slowly, and not yet. Apple recommends SwiftUI for new apps but still ships and documents new AppKit APIs. Practical rule: new screens in SwiftUI; reach for AppKit when the Mac-specific behavior you need isn't exposed in SwiftUI.

Can one app use both?

Yes, and most serious Mac apps do. NSViewRepresentable puts an AppKit view inside SwiftUI; NSHostingView does the reverse. That's why naming the layer you want changed matters.

Is every SwiftUI control secretly an AppKit control?

Don't assume so. Some are bridged, many aren't, and Apple treats it as an implementation detail. Treat Button and NSButton as different APIs that happen to look alike.

Are AppKit and UIKit the same thing?

No — AppKit is Mac, UIKit is iPhone/iPad. The prefix gives it away: NSButton is Mac, UIButton is iOS. Mac Catalyst is a third thing: an iPad app wearing a Mac coat.

Every macOS entry on NameThat lists both names in its IN CODE table, and the Translation Table holds all 60+ mappings in one place — start from the thing you can see, take whichever name your project needs.

Search

Describe the UI element you're thinking of