A Practical Approach to Presenting UIAlertController Outside View Controllers

Introduction

In iOS app development, UIAlertController, as the modern replacement for UIAlertView and UIActionSheet, requires presentation from a view controller (UIViewController). However, developers often need to display alerts in non-view controller contexts, such as utility class methods or background threads. For example, when a user taps a button in a view controller, invoking a utility method where an error occurs, an alert must be shown immediately without returning to the original view controller. Based on high-scoring answers from Stack Overflow, this article delves into solving this issue by creating custom UIWindow instances, with detailed implementation analysis and code examples.

Design Limitations and Challenges of UIAlertController

UIAlertController is a subclass of UIViewController, designed following the MVC pattern and requiring presentation via presentViewController:animated:completion: from an existing view controller. This ensures integration with the user interface and lifecycle management. But in scenarios like utility methods or global error handling, no view controller instance may be available, leading to runtime errors if presentViewController is called directly. Traditional methods like UIAlertView could bypass this but are deprecated and not aligned with modern iOS best practices.

To address this, developers have proposed various solutions. For instance, accessing the root view controller via UIApplication.shared.keyWindow?.rootViewController to present alerts, but this can be unreliable with complex view hierarchies (e.g., navigation or tab bar controllers) and may not ensure alerts appear above keyboards or other system components. Another common approach uses singletons or global managers, which can introduce complexity and memory leaks. Given these challenges, this article focuses on a more elegant solution: creating a custom UIWindow as an alert container.

UIWindow-Based Solution

The core idea is to create a new UIWindow instance, set it as the key window, and use a plain UIViewController as its root view controller to present the UIAlertController. This mimics system alert behavior, ensuring alerts are independent of the main app window and appear above all interface elements. Key implementation steps include:

1. Create UIWindow Instance: Initialize a UIWindow with the screen bounds. To prevent automatic deallocation, store it in a strong reference, such as via associated objects or class properties.
2. Set Root View Controller: Assign the window's rootViewController to a plain UIViewController instance, providing a base view controller hierarchy for presentation.
3. Configure Window Properties: Set the window's windowLevel above system alerts (e.g., UIWindowLevelAlert + 1) to ensure it appears above keyboards and other components. Inherit the main window's tintColor for consistency.
4. Display Alert: Call makeKeyAndVisible to show the window and present the UIAlertController via the root view controller.
5. Memory Management: After the alert dismisses, hide the window and release resources to prevent memory leaks, e.g., by overriding viewDidDisappear in UIAlertController.

Here is an Objective-C code example extending UIAlertController with a category to add a show method:

#import "UIAlertController+Window.h"
#import <objc/runtime.h>

@interface UIAlertController (Window)
- (void)show;
@end

@interface UIAlertController (Private)
@property (nonatomic, strong) UIWindow *alertWindow;
@end

@implementation UIAlertController (Private)
@dynamic alertWindow;
- (void)setAlertWindow:(UIWindow *)alertWindow {
    objc_setAssociatedObject(self, @selector(alertWindow), alertWindow, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
}
- (UIWindow *)alertWindow {
    return objc_getAssociatedObject(self, @selector(alertWindow));
}
@end

@implementation UIAlertController (Window)
- (void)show {
    self.alertWindow = [[UIWindow alloc] initWithFrame:[UIScreen mainScreen].bounds];
    self.alertWindow.rootViewController = [[UIViewController alloc] init];
    self.alertWindow.windowLevel = UIWindowLevelAlert + 1;
    [self.alertWindow makeKeyAndVisible];
    [self.alertWindow.rootViewController presentViewController:self animated:YES completion:nil];
}
- (void)viewDidDisappear:(BOOL)animated {
    [super viewDidDisappear:animated];
    self.alertWindow.hidden = YES;
    self.alertWindow = nil;
}
@end

In Swift, a similar approach can be used, with attention to syntax and memory management. Here is a simplified Swift 5.0 example:

import UIKit

extension UIAlertController {
    private static var alertWindow: UIWindow?
    
    func show(animated: Bool = true) {
        let window = UIWindow(frame: UIScreen.main.bounds)
        window.rootViewController = UIViewController()
        window.windowLevel = .alert + 1
        window.makeKeyAndVisible()
        UIAlertController.alertWindow = window
        window.rootViewController?.present(self, animated: animated, completion: nil)
    }
    
    override open func viewDidDisappear(_ animated: Bool) {
        super.viewDidDisappear(animated)
        UIAlertController.alertWindow?.isHidden = true
        UIAlertController.alertWindow = nil
    }
}

Considerations and Best Practices

When implementing this solution, consider the following to avoid common pitfalls:

• Avoid Retain Cycles: In UIAlertController action handlers, avoid direct references to the alert or its text fields to prevent retain cycles and memory leaks. For example, use local variables: __block UITextField *localTextField;.
• Handle Complex View Hierarchies: If the app uses navigation or tab bar controllers, ensure alerts appear above the active view controller. This method avoids this by creating an independent window, but alternative solutions may require additional handling.
• Testing and Compatibility: Test alert behavior across iOS versions and devices to ensure window level and presentation logic compatibility, e.g., with multi-window support in iOS 13+.
• Performance Considerations: Frequent window creation and destruction may impact performance; consider lazy loading or shared window instances.

Compared to other methods, the UIWindow-based solution offers advantages: no need to modify existing code (via categories), ensures alerts appear above all interface elements, and avoids dependency on complex view controller hierarchies. However, it may add window management complexity, requiring careful handling of memory and lifecycle.

Conclusion

Presenting UIAlertController outside view controllers is a common challenge in iOS development. By creating custom UIWindow instances as alert containers, developers can implement a reliable and flexible solution that mimics system alert behavior and ensures responsive user interfaces. This article detailed the implementation steps, code examples, and considerations, aiming to assist developers in applying this technique in real projects. As iOS frameworks evolve, more official support may emerge, but currently, this method is widely adopted and validated by the community. Developers should choose appropriate methods based on specific needs and follow best practices for maintainability and performance.