Introduction

In Swift 3-era UIKit, the usual way to control status bar appearance is through the view controller, not by setting a global status bar style directly at runtime. The exact behavior depends on whether your app allows per-view-controller control and whether a navigation controller is involved.

Use preferredStatusBarStyle on the view controller

The standard pattern is to override preferredStatusBarStyle:

1import UIKit
2
3final class ProfileViewController: UIViewController {
4    override var preferredStatusBarStyle: UIStatusBarStyle {
5        return .lightContent
6    }
7}

If the view controller is active and status-bar appearance is controlled by view controllers, iOS uses that property to decide whether the status bar content should be light or dark.

In Swift 3, the common choices are:

• '.default'
• '.lightContent'

That is usually enough for screens with light or dark backgrounds.

Make sure view-controller-based appearance is enabled

This part is easy to miss. In Info.plist, the key View controller-based status bar appearance must allow view controllers to control the status bar. If it is disabled, your override may appear to do nothing.

Most apps should leave view-controller-based control enabled. That keeps status-bar decisions close to the screen that actually needs them.

When the style changes dynamically, request an update:

1override func viewDidAppear(_ animated: Bool) {
2    super.viewDidAppear(animated)
3    setNeedsStatusBarAppearanceUpdate()
4}

That tells UIKit to ask the view controller for its preferred style again.

Navigation controllers often control the result

If your screen is inside a UINavigationController, the navigation controller may determine the visible status bar style rather than the child controller unless you forward that responsibility.

One common solution is to subclass UINavigationController:

1import UIKit
2
3final class AppNavigationController: UINavigationController {
4    override var childForStatusBarStyle: UIViewController? {
5        return topViewController
6    }
7}

Now the top view controller gets to decide the status bar style:

1final class DetailsViewController: UIViewController {
2    override var preferredStatusBarStyle: UIStatusBarStyle {
3        return .lightContent
4    }
5}

Without this, developers often set preferredStatusBarStyle correctly and still see no visible change because the navigation controller is effectively in charge.

Avoid the old global style approach

Older tutorials often show global calls such as setting the shared application's status bar style directly. That approach became less suitable once iOS moved toward view-controller-based appearance control.

The view-controller approach is better because:

• different screens can choose different styles
• transitions behave more naturally
• the code lives with the screen that owns the visual design

If the app truly uses one consistent style everywhere, you can still enforce that at the app design level, but the per-screen override is usually the cleanest mechanism.

Example with a dark header screen

Here is a minimal example that combines the important pieces:

1import UIKit
2
3final class WelcomeViewController: UIViewController {
4    override func viewDidLoad() {
5        super.viewDidLoad()
6        view.backgroundColor = .black
7    }
8
9    override var preferredStatusBarStyle: UIStatusBarStyle {
10        return .lightContent
11    }
12}
13
14final class RootNavigationController: UINavigationController {
15    override var childForStatusBarStyle: UIViewController? {
16        return topViewController
17    }
18}

This is enough for a dark screen with light status-bar content, assuming the app allows view-controller-based status-bar appearance.

Common Pitfalls

The biggest mistake is overriding preferredStatusBarStyle while Info.plist is configured so view controllers do not control the status bar. In that case, the override is ignored.

Another common issue is testing inside a navigation controller without forwarding status-bar style control to the top view controller.

People also call setNeedsStatusBarAppearanceUpdate() on the wrong controller. If a container controller actually controls the status bar, that container needs to participate correctly.

Finally, avoid copying outdated tutorials that rely only on app-wide global status-bar APIs. The view-controller pattern is the more reliable design.

Summary

• Override preferredStatusBarStyle on the relevant view controller.
• Ensure Info.plist allows view-controller-based status-bar appearance.
• Use setNeedsStatusBarAppearanceUpdate() when the style changes dynamically.
• If you use a navigation controller, forward status-bar style control to the top view controller.
• Prefer per-screen status-bar control over old global runtime style changes.