An edit menu lets people make changes to selected content in the current view, in addition to offering related commands like Copy, Select, Translate, and sometimes Find.
In addition to text, an edit menu’s commands can apply to many types of selectable content, such as images, files, and objects like contact cards, charts, or map locations.
Edit menus can look and behave slightly differently in different platforms.
- In iOS, the edit menu lists commands in a horizontal callout bar horizontal view — similar to a popover — that appears when people touch and hold or double-tap to select content in a view.
- In iPadOS, the edit menu looks different depending on how people reveal it. When people touch and hold or double-tap to select content, the menu uses the same horizontal popover horizontal bar appearance as in iOS. In contrast, when people use a pointing device to reveal the edit menu, it looks similar to a context menu, listing commands in a single column, potentially grouped into logical subsets.
- In macOS, people can access editing commands in a context menu they can reveal while in an editing task, as well as through the app’s Edit menu in the menu bar.
Editing content is rare in tvOS and watchOS experiences, so the system doesn’t provide an edit menu in these platforms.
Prefer the system-provided edit menu. People are familiar with the contents and behavior of the system-provided component, so creating a custom menu that presents the same commands is redundant and likely to be confusing.
Enable commands that are relevant in the current context, removing or dimming commands that don’t apply. For example, if nothing is selected, avoid showing options that require a selection, such as Copy or Cut. Similarly, avoid showing a Select option when people have already selected something. For a list of standard edit menu commands, see UIResponderStandardEditActions.
Avoid overwhelming people with too many custom commands. To maintain the familiar ordering of an edit menu, be sure to list your custom commands after the system-provided ones in the relevant section. For example, if you offer custom formatting commands, list them after the system-provided commands in the format section.
When it makes sense, let people select and copy noneditable text. People appreciate being able to paste static content — such as an image caption or social media status — into a message, note, or web search. In general, let people copy content text, but not control labels.
Support undo and redo when possible. Like all menus, an edit menu doesn’t require confirmation before performing its actions, so people can appreciate using undo and redo to recover a previous state. For guidance, see Undo and redo.
In general, avoid implementing other controls that perform the same functions as edit menu items. People typically expect to choose familiar edit commands in an edit menu, or use standard keyboard shortcuts. Offering redundant controls can crowd your interface, giving you less space for presenting actions that people might not already know about.
Differentiate different types of deletion commands when necessary. For example, a Delete menu item behaves the same as pressing a Delete key, but a Cut menu item copies the selected content to the system pasteboard before deleting it.
Create short labels for custom commands. Use verbs or short verb phrases that succinctly describe the action your command performs. For guidance, see Labels.
Not supported in tvOS or watchOS.
Support both edit menu styles. Be prepared to display the horizontal callout bar when people use Multi-Touch gestures to reveal the menu and the tall context menu style when people use a pointing device to reveal it.
Adjust an edit menu’s placement, if necessary. Depending on available space, the default menu position is above or below the insertion point or selection. The system also displays a visual indicator that points to the targeted content. Although you can’t change the shape of the menu or its pointer, you can change the menu’s position. For example, you might need to move the menu to prevent it from covering important content or parts of your interface.
In your iPadOS app, consider whether Find menu items belong in the Edit menu. When people use a physical keyboard with your iPadOS app, they can view the standard keyboard shortcuts for commands like Find and Find Next in the shortcut interface. If your app lets people search for files or other types of objects — and not for text — it might make more sense to list Find menu items in the File menu. For guidance, see Keyboard shortcuts.
To learn about the order of items in a macOS app’s Edit menu, see Edit menu.