Introduction

The message saying a popover controller is deallocated while still visible usually means object lifetime is wrong. The popover is presented, but no strong reference keeps the controller alive long enough. This was a common issue with UIPopoverController on older iPad codebases and still appears during maintenance of legacy apps.

Why This Warning Appears

UIPopoverController is not retained automatically by the system in all usage patterns. If you create it in a local scope, it can be deallocated immediately after method exit.

1- (void)showMenuFromBarButton:(UIBarButtonItem *)button {
2    UIPopoverController *popover = [[UIPopoverController alloc] initWithContentViewController:self.menuVC];
3    [popover presentPopoverFromBarButtonItem:button
4                    permittedArrowDirections:UIPopoverArrowDirectionAny
5                                    animated:YES];
6    // popover can deallocate here
7}

The fix is to store it in a strong property.

Keep a Strong Property Reference

Declare a retained property and assign the popover before presenting.

1@interface DashboardViewController () <UIPopoverControllerDelegate>
2@property (nonatomic, strong) UIPopoverController *menuPopover;
3@end
4
5@implementation DashboardViewController
6
7- (void)showMenuFromBarButton:(UIBarButtonItem *)button {
8    self.menuPopover = [[UIPopoverController alloc] initWithContentViewController:self.menuVC];
9    self.menuPopover.delegate = self;
10    [self.menuPopover presentPopoverFromBarButtonItem:button
11                             permittedArrowDirections:UIPopoverArrowDirectionAny
12                                             animated:YES];
13}
14
15@end

Now lifetime is tied to the owner controller and the warning should disappear.

Dismiss and Clear at the Right Time

Always dismiss an active popover before owner teardown or navigation transitions.

1- (void)viewWillDisappear:(BOOL)animated {
2    [super viewWillDisappear:animated];
3
4    if (self.menuPopover.popoverVisible) {
5        [self.menuPopover dismissPopoverAnimated:NO];
6    }
7    self.menuPopover = nil;
8}

If you keep multiple popovers, centralize dismissal logic to avoid leaked presentation state.

Modern API Migration Path

UIPopoverController is deprecated. New code should use UIPopoverPresentationController through normal view controller presentation.

1import UIKit
2
3func presentSettings(from sourceView: UIView, in host: UIViewController) {
4    let vc = UIViewController()
5    vc.modalPresentationStyle = .popover
6
7    if let pop = vc.popoverPresentationController {
8        pop.sourceView = sourceView
9        pop.sourceRect = sourceView.bounds
10        pop.permittedArrowDirections = .any
11    }
12
13    host.present(vc, animated: true)
14}

Modern presentation APIs integrate better with adaptive layouts and reduce manual lifetime management.

Debugging Checklist for Legacy Projects

When this bug reappears in old modules, use a focused checklist:

• Confirm popover object is owned by a strong property.
• Confirm owner outlives the presentation window.
• Confirm dismissal runs during navigation and deallocation paths.
• Confirm delegate callbacks are not causing reentrant dismissal bugs.

This approach resolves most cases without invasive refactors.

Adaptation Behavior on Different Devices

Legacy popover code often assumes iPad-only behavior. On compact size classes, presentation may adapt to full-screen or different modal styles, which changes lifecycle timing. If your code relies on popover-specific callbacks, verify behavior on both iPad and iPhone simulation targets.

For modern APIs, use UIPopoverPresentationControllerDelegate adaptation methods to control behavior explicitly.

1func adaptivePresentationStyle(
2    for controller: UIPresentationController,
3    traitCollection: UITraitCollection
4) -> UIModalPresentationStyle {
5    return .none
6}

A clear adaptation policy reduces surprises during rotation, multitasking, and size-class transitions.

Memory Ownership Checklist

When debugging deallocation warnings, inspect ownership graph in Xcode memory tools. Confirm no unintended retain cycles exist between presented controllers and delegates, and confirm owner references are not weak where strong ownership is required.

Capture this behavior in regression tests if the screen is business-critical, because ownership bugs often return after unrelated refactors.

Common Pitfalls

The most common pitfall is allocating the popover in a local method variable. Another issue is setting the property as weak under ARC, which allows early deallocation. Teams also sometimes dismiss popovers only in user actions and forget navigation-driven teardown paths, leading to warnings during back navigation. Finally, partial migration to modern APIs can leave mixed patterns in the same screen. Standardize one presentation approach per module to keep behavior consistent.

Summary

• The warning usually means the popover controller lost strong ownership.
• Store UIPopoverController in a strong property before presenting.
• Dismiss visible popovers during lifecycle transitions.
• Prefer UIPopoverPresentationController for modern code.
• Use a consistent presentation pattern to avoid recurring lifetime bugs.