Human Interface Guidelines Extras

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.

Contribute →

Contents

• macOS
• iOS
• watchOS
• tvOS

macOS

Don't remove default menu items

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?

• The Preferences menu item in the app menu.
• All menu items in the File menu except for Close.
• Find and the below menu items in the Edit menu if your app doesn't include text editing.
• The Format menu.
• The toolbar and sidebar menu items in the View menu if your app doesn't need those.

Drag and drop files

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.

“Always on top” functionality

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.

Include an Internet Access Policy

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.

Example policy.

Number text field convenience

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.

1. Place a stepper control on the right side of the text field.
2. When the text field is focused, make it possible to use arrow up/down keys change the number by 1.
3. If the user also holds down the Option key, change the number by 10.
4. If the user reaches a lower or upper limit, shake the text field contents to indicate that.

You can find a real-world example of this in my Gifski app (missing the stepper though) (source).

Read more about text fields.

iOS

Settings sheet dismiss button

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:

• Apple does that in most apps. You cannot go wrong following what Apple does.
• “Done” has a larger tap target.
• Friendlier. An “X” might make people think the settings will not be saved.
• Easier to reach for right-handed people, the majority.
• An informal Twitter poll tells us that most users prefer this.

What you should definitely not do:

• “Done” button on the left side.
• “Cancel” button on either side.
• “Dismiss” button on either side.

struct SettingsView: View {
	@Environment(\.presentationMode) private var presentationMode

	var body: some View {
		NavigationView {
			Form {
				Section(header: Text("Unicorn")) {
					// …
				}
			}
				.navigationTitle("Settings")
				.navigationBarTitleDisplayMode(.inline)
				.toolbar {
					// Note that it's `.confirmationAction` and not `.primaryAction`.
					ToolbarItem(placement: .confirmationAction) {
						Button("Done") {
							presentationMode.wrappedValue.dismiss()
						}
					}
				}
		}
	}
}

Settings sheet title

People seem undecided on whether to use a normal or large navigation bar title for a settings sheet.

Discuss →

watchOS

Nothing yet

tvOS

Nothing yet