A popover is a view that appears above other content onscreen when you click a control or view. For example, Calendar displays information in a popover when you double-click an event. Typically, a popover includes an arrow pointing to the location from which it emerged. Popovers also support vibrancy.

Screenshot of Calendar, highlighting the popover used to view the details of a calendar event.

A popover can close in response to a user interaction (transient behavior), in response to a user’s interaction with the view or element from which the popover emerged (semitransient behavior), or in an app-defined way. A popover can also be made detachable. A detachable popover becomes a separate window when dragged by the user, allowing it to remain visible onscreen while the user interacts with other content.

Use a popover to expose a small amount of information or functionality. Because a popover disappears after the user interacts with it, limit the amount of functionality in the popover to a few related tasks. For example, a calendar event popover makes it easy for people to change the date or time of an event, or to move it to another calendar. The popover disappears after users make the change, enabling them to continue reviewing the events on their calendar.

Consider using popovers instead of temporary views like sidebars and panels. Popovers can help you streamline your interface, leaving more room for content.

Enable a closure behavior that makes sense based on the popover’s function. A popover should close automatically when its presence is no longer needed. If a popover merely presents a set of choices, consider closing it as soon as the user makes a selection—similar to the way a menu behaves. When multiple selections can be made, a popover should remain open until the user explicitly dismisses it or clicks outside of its bounds.

Provide a Close button for confirmation or guidance only. A Close button, such as Cancel or Done, is worth including only if it provides clarity, such as for exiting with or without saving changes.

Always save work when closing a popover automatically. It’s often easy to dismiss a popover unintentionally by clicking another area onscreen. Discard work only when someone clicks an explicit Cancel button.

Position popovers onscreen with care. A popover’s arrow should point directly to the element that revealed it. A popover also shouldn’t cover the element that was clicked to show the popover.

Screenshot of Calendar, highlighting the detached version of the popover used to view the details of a calendar event.

Consider letting people detach a popover. Users might appreciate being able to convert a popover into a panel if they want to view other information while the popover remains visible.

Make minimal appearance changes to a detached popover. The panel should look similar to the original popover so the user doesn’t lose context.

Display one popover onscreen at a time. Displaying multiple popovers that the user hasn’t explicitly detached clutters the interface and causes confusion. Never show a cascade or hierarchy of popovers, in which one emerges from another. If you need to show a new popover, first close the open popover before opening another.

Don’t show another view over a popover. Except for an alert, nothing should be displayed on top of a popover.

Avoid making a popover too big. A popover shouldn’t take over the entire screen. Make it only big enough to display its contents and point to the place it came from.

In general, retain the standard popover appearance. By default, popovers are light in appearance. A dark appearance is also available, but is generally reserved for immersive, media-centric apps with dark interfaces.

Make sure customized popovers still resemble popovers. Although you can customize many of the visual aspects of a popover, avoid creating a design people might not recognize as a popover. Popovers tend to work best when they contain standard controls and views.

Provide a smooth transition when changing the size of a popover. Some popovers provide both condensed and expanded views of the same information. For example, a Calendar event popover is collapsed when initially opened; it expands to reveal additional options when editing certain attributes. Animate changes in size to avoid giving the impression that a new popover replaced the old one.

Don’t use a popover as an alert. Popovers and alerts are very different interface elements. People choose to see a popover; they never choose to see an alert. If you use popovers and alerts interchangeably, you blur the distinctions between them and cause confusion. If you use a popover to warn users about a serious problem or help them avoid imminent, unintentional data loss, you risk them dismissing the popover without reading it and blaming your app when negative results occur. If you really need to warn users (which should happen only rarely), use an alert. See Alerts.

Avoid using the word popover in user documentation. Instead, refer to a specific task or selection. For example, instead of “Select the Show button at the bottom of the popover,” you might write “Select the Show button.” Don’t refer to a popover as a dialog or window either.

For developer guidance, see NSPopover.