Community additions to Apple's Human Interface Guidelines
CC0-1.0 License
Community additions to Apple's Human Interface Guidelines
Apple's Human Interface Guidelines are amazingly well done. However, there are many details they don't clearly specify. This is an attempt to document the best conventions and patterns in the community.
When you create a new macOS app project in Xcode, it includes a main menu with a lot of items. You might be tempted to remove stuff you don't need. For example, I have seen many apps remove “Undo” and “Redo” because their app doesn't support that. This is usually because they don't realize how the responder chain works. I made this mistake myself.
The reason you should not remove such menu items is that you cannot foresee what will need it. For example, if your app has a way to save a file, the filename text field in the save panel supports undo/redo and the “Undo” menu item works when the text field is key (focused). Another example, my Black Out app has a “Quick Action” extension, and if the user runs it from Finder, the extension is able to use Finder's “Undo” and “Redo” menu items.
So what default menu items can be removed?
Settings
menu item in the app menu.File
menu except for Close
.Find
and the below menu items in the Edit
menu if your app doesn't include text editing.Format
menu.View
menu if your app doesn't need those.Form
with .formStyle(.grouped)
. Group controls with Section
.gearshape
symbol (not gear
).gearshape.2
symbol.If your app has a drag and drop target for files, don't forget to also make it possible to click the drop area to open files through an open panel instead of dragging. Alternatively, add an “Open” button inside the drop target.
You might want to let the user set your app's window to always be on top. You can find this behavior in the Simulator app.
The menu bar item that toggles this functionality should be named “Stay on Top” and should be in the “Window” menu below “Enter Full Screen”, or if it's not there, below “Tile Window to Right of Screen”.
The setting should be persisted in UserDefaults
.
When enabled, the window should be set to window.level = .floating
.
If your app needs to access the internet for any reason, I would strongly recommend including a Internet Access Policy. This lets firewall apps present to the user what and why your app needs access to. It also makes it more likely the user will grant access.
If your app has a text field where the user can set a number, for example, for the width of something, make it convenient to increase/decrease the number.
You can find a real-world example of this in my Gifski app (missing the stepper though) (source).
The most common conventions I have seen for a settings sheet dismissal button is either a “Done” button on the right side (primary position) of the navigation bar or an “X” icon on the left side (navigational position).
There are several benefits to using a “Done” button on the right side:
What you should definitely not do:
struct SettingsScreen: View {
@Environment(\.dismiss) private var dismiss
var body: some View {
NavigationStack {
Form {
Section("Unicorn") {
// …
}
}
.navigationTitle("Settings")
.navigationBarTitleDisplayMode(.inline)
.toolbar {
// Note that it's `.confirmationAction` and not `.primaryAction`.
ToolbarItem(placement: .confirmationAction) {
Button("Done") {
dismiss()
}
}
}
}
}
}
People seem undecided on whether to use a normal or large navigation bar title for a settings sheet.
Nothing yet
Nothing yet