Why viewWillAppear Is Not Called When an iOS App Returns from Background and How to Handle It

Problem Context and Core Conflict

In iOS app development, a common scenario arises: when an app enters the background due to a phone call or switching to another app, and later returns to the foreground, developers expect the viewWillAppear: method to automatically update the interface layout, but it is not called. This stems from a misunderstanding of the triggering mechanism of viewWillAppear:. viewWillAppear: is part of the UIViewController lifecycle, and its invocation is solely related to whether the view controller's view is about to appear on screen. When the app enters the background, if the current view controller's view never disappears (e.g., not covered or popped by another view), the system considers it as never having disappeared upon returning to the foreground, so viewWillAppear: is not triggered.

Root Cause Analysis

The design intent of viewWillAppear: is to handle display logic at the view controller hierarchy level, not global application state changes. The transition from background to foreground is a UIApplication-level state change and should be monitored via system notifications like UIApplicationWillEnterForegroundNotification. Directly calling viewWillAppear: not only risks breaking its semantic consistency (e.g., incorrectly triggering other lifecycle methods of the view controller) but may also lead to hard-to-track layout errors.

Recommended Solution

The best practice is to abstract layout logic into a separate method and call it from both viewWillAppear: and appropriate application state notifications. Below is an Objective-C example:

- (void)viewWillAppear:(BOOL)animated {
    [super viewWillAppear:animated];
    [self updateLayout]; // Call the unified layout method
}

- (void)updateLayout {
    // Implement specific layout adjustment logic, e.g.:
    _sv.frame = CGRectMake(0.0, 0.0, 320.0, self.view.bounds.size.height);
}

- (void)viewDidLoad {
    [super viewDidLoad];
    // Observe notification for app returning to foreground
    [[NSNotificationCenter defaultCenter] addObserver:self
                                             selector:@selector(updateLayout)
                                                 name:UIApplicationWillEnterForegroundNotification
                                               object:nil];
}

- (void)dealloc {
    // For iOS 9 and above, removing observer is optional; but recommended for compatibility
    [[NSNotificationCenter defaultCenter] removeObserver:self];
}

This approach ensures centralized management of layout code while responding to both view display and application state change events.

Swift Implementation Example

In Swift, similar logic can be implemented using NotificationCenter with more concise code:

import UIKit

class ViewController: UIViewController {
    
    override func viewDidLoad() {
        super.viewDidLoad()
        // Add observer for app returning to foreground
        NotificationCenter.default.addObserver(self,
                                               selector: #selector(updateLayout),
                                               name: UIApplication.willEnterForegroundNotification,
                                               object: nil)
    }
    
    override func viewWillAppear(_ animated: Bool) {
        super.viewWillAppear(animated)
        updateLayout()
    }
    
    @objc func updateLayout() {
        // Perform layout updates, e.g., adjust subview frames
        print("Layout updated in response to view appearance or app foreground event.")
    }
    
    deinit {
        // Not required in iOS 9+, but explicitly removing is recommended to avoid potential issues
        NotificationCenter.default.removeObserver(self)
    }
}

Considerations and Extended Discussion

1. Notification Selection: Besides UIApplicationWillEnterForegroundNotification, consider UIApplicationDidBecomeActiveNotification based on needs; note the timing difference (former before foreground transition, latter after).

2. View Controller Tracking: For complex apps, determining the "current" view controller to trigger layout updates may be necessary. This can be achieved via UINavigationController delegate methods or custom state management, but avoid over-engineering.

3. Auto Layout and Adaptation: In modern iOS development, prioritize using Auto Layout or SwiftUI's declarative layout, which can automatically handle some size changes, reducing manual layout code.

4. Performance and Memory Management: Ensure removal of notification observers upon view controller deallocation to prevent memory leaks. Although automatic in iOS 9+, explicit removal improves code maintainability.

Conclusion

Handling interface updates when an app returns from the background requires distinguishing between view controller lifecycle and application state machine. By extracting layout logic into a separate method and calling it from both viewWillAppear: and UIApplicationWillEnterForegroundNotification, a clear and maintainable solution can be achieved. Avoid directly calling viewWillAppear: to preserve code semantic correctness and framework consistency.