How to present popover properly in iOS 8
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
In iOS 8, popovers moved to the unified presentation API, so the old iPad-only UIPopoverController pattern stopped being the main answer. To present a popover correctly, you configure the presented controller with .popover, provide an anchor through sourceView and sourceRect or barButtonItem, and handle adaptive presentation if you want true popover behavior outside regular-size environments.
Configure the popover presentation controller
The first rule is simple: a popover must know where it is coming from. If you present a controller as a popover without an anchor, iOS will throw an exception at runtime.
The anchor is the key part. If the popover originates from a bar button item, use popover.barButtonItem = item instead of sourceView and sourceRect.
Understand iOS 8 adaptation behavior
In iOS 8, popovers are adaptive presentations. On compact environments, the system may choose a different style, often full-screen or over-current-context, unless your delegate returns .none from the adaptive presentation callback.
That behavior surprises developers who expect the same visual result on every device. The controller is still presented correctly, but the system may intentionally adapt it. If your design specifically requires a popover look in environments where it is allowed, the delegate hook is where you state that preference.
Present from the right view controller
Another common problem is presenting from a controller that is not currently in the window hierarchy. The popover API itself may be correct, but the presentation fails or logs warnings because the presenting controller is not active.
The practical fix is to present from the controller that owns the visible button or bar button item. In other words, keep the presentation local to the interface that triggers it.
Customize size and interaction thoughtfully
preferredContentSize controls the popover content size. permittedArrowDirections helps the system choose an arrow placement that fits the available space. You can also allow touches to pass through to specific views with passthroughViews, but use that sparingly because it can make the interaction model harder to understand.
The best popovers are small, focused, and anchored to the control that explains why they appeared. If the content is large or workflow-heavy, a modal presentation is often a better fit than forcing it into a popover.
Common Pitfalls
- Forgetting to set
sourceViewandsourceRectorbarButtonItem, which causes a runtime failure. - Expecting identical popover behavior on compact and regular size classes without handling adaptive presentation.
- Presenting from the wrong controller instead of the one that is actually visible.
- Putting too much content into a popover and turning it into an awkward mini-screen.
- Assuming the old pre-iOS 8 popover API is still the preferred approach.
Summary
- In iOS 8, present popovers with
modalPresentationStyle = .popover. - Always provide a valid anchor through
sourceViewandsourceRectorbarButtonItem. - Use the popover presentation controller delegate to control adaptive behavior when needed.
- Present from the currently visible controller, not from a disconnected part of the hierarchy.
- Keep popover content compact and context-specific.

