A popover is a view that appears above other content onscreen when you click a control or view. For example, Calendar displays event 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.

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 only a small amount of occasionally needed functionality. Since a popover disappears after the user interacts with it, the user can spend more time focusing on content and less time removing clutter from their workspace.

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. In general, 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—the same way a menu behaves. When multiple selections can be made, a popover should remain open until someone 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 exiting with or without saving changes.

Always save work when automatically 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 appropriately onscreen. A popover’s arrow should point as directly as possible to the element that revealed it. A popover also shouldn’t cover the element that was clicked to show the popover.

Let people detach a popover if appropriate. 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 nondetached 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, close the open one first.

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. For one thing, 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 alert 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.