Introduction

If you need the status bar height in Swift, the first question is whether you really need the raw status bar height or whether you actually need the top safe area inset. In modern iOS layouts, the safe area is usually the more useful measurement because it already accounts for the status bar and device-specific top insets such as the notch area.

Use the window scene's statusBarManager for raw height

The modern UIKit way to read the status bar frame is through the current UIWindowScene:

1import UIKit
2
3func currentStatusBarHeight(for view: UIView) -> CGFloat {
4    guard let windowScene = view.window?.windowScene else {
5        return 0
6    }
7    return windowScene.statusBarManager?.statusBarFrame.height ?? 0
8}

This gives you the actual current height of the status bar frame. It is better than older global UIApplication.shared.statusBarFrame patterns, which became less appropriate as iOS moved to scene-based APIs.

Use the safe area when laying out UI

For layout, the top safe area inset is often the right value instead:

1import UIKit
2
3func topSafeAreaInset(for view: UIView) -> CGFloat {
4    return view.safeAreaInsets.top
5}

Why is this often better?

• it reflects the usable layout area
• it adapts to notches and system UI changes
• it matches how Auto Layout and UIKit expect you to design modern screens

If your real goal is "keep my content below the system bar area," safe area is almost always the better choice.

Example inside a view controller

Here is a simple example that prints both values after the view has appeared:

1import UIKit
2
3final class DemoViewController: UIViewController {
4    override func viewDidAppear(_ animated: Bool) {
5        super.viewDidAppear(animated)
6
7        let statusBarHeight = view.window?.windowScene?.statusBarManager?.statusBarFrame.height ?? 0
8        let safeAreaTop = view.safeAreaInsets.top
9
10        print("Status bar height:", statusBarHeight)
11        print("Top safe area inset:", safeAreaTop)
12    }
13}

Printing in viewDidAppear or later is important because the view must already be attached to a window for scene and safe-area information to be fully available.

Do not hard-code 20 points

Older tutorials often mention 20 as the status bar height. That used to be a common value on older iPhones in portrait, but it is not a safe assumption now.

The actual top area can vary because of:

• device family
• notch or Dynamic Island style hardware
• call or hotspot status presentation
• orientation and scene context

Hard-coded status bar values usually produce layout bugs eventually.

SwiftUI note

If you are using SwiftUI, you often should not read the status bar height directly at all. Instead, use layout tools that respect safe areas automatically, or explicitly read safe area insets through the hosting environment when necessary.

This is one of those cases where the raw number is less important than using the correct layout system.

Common Pitfalls

The biggest mistake is reading the raw status bar height when the actual problem is content layout. In those cases, use the safe area instead.

Another common issue is trying to read view.window or scene-based information too early, such as before the view is in a window hierarchy.

People also copy old code that relies on deprecated or outdated global status-bar APIs. Scene-based apps should use windowScene.statusBarManager.

Finally, avoid hard-coding a constant height. Modern iOS devices and transient system states make that unreliable.

Summary

• Use windowScene.statusBarManager?.statusBarFrame.height when you truly need the raw status bar height.
• Use view.safeAreaInsets.top when you are solving a layout problem.
• Read these values after the view is attached to a window.
• Do not hard-code 20 or any other fixed status bar height.
• In modern iOS UI code, safe area is usually more important than the raw status bar frame.