Introduction

In SwiftUI, asking for "the screen width" is often really a layout question. Sometimes you truly want the device-wide width in points, but more often you want the width actually available to a specific view after containers, safe areas, and multitasking rules are applied. SwiftUI has APIs for both cases, and choosing the right one prevents brittle layouts.

Use GeometryReader for Real Layout Decisions

If the goal is to size or adapt a SwiftUI view, GeometryReader is usually the correct answer because it reports the size offered by the parent container.

1import SwiftUI
2
3struct ContentView: View {
4    var body: some View {
5        GeometryReader { geo in
6            VStack(spacing: 16) {
7                Text("Available width: \(Int(geo.size.width))")
8                RoundedRectangle(cornerRadius: 12)
9                    .fill(.blue)
10                    .frame(width: geo.size.width * 0.8, height: 80)
11            }
12            .frame(maxWidth: .infinity, maxHeight: .infinity)
13        }
14    }
15}

This is usually better than reading a global screen metric because it works correctly inside sheets, split views, sidebars, and other containers where the full device width is not actually available.

Use UIScreen Only When You Truly Need Device Width

If you really need the current physical screen width in points, you can still read it through UIKit:

1import SwiftUI
2import UIKit
3
4let screenWidth = UIScreen.main.bounds.width
5print(screenWidth)

This gives the screen bounds, not the local layout width. That distinction matters. A child view inside a narrow container may have far less room than UIScreen.main.bounds.width suggests.

Screen Width and Available Width Are Not the Same

These values diverge in several common situations:

• split-screen multitasking on iPad
• sheet or popover presentation
• navigation split layouts
• embedded child views
• safe-area constrained content

If your layout logic depends on the space a view can actually use, container width is the meaningful number, not global screen width.

Environment-Driven Layout Can Be Better Than Manual Width Checks

Sometimes you do not need a numeric width value at all. SwiftUI includes adaptive APIs that often express intent more clearly.

A simple example is size class:

1import SwiftUI
2
3struct AdaptiveView: View {
4    @Environment(\.horizontalSizeClass) private var horizontalSizeClass
5
6    var body: some View {
7        if horizontalSizeClass == .compact {
8            VStack {
9                Text("Compact layout")
10            }
11        } else {
12            HStack {
13                Text("Regular layout")
14            }
15        }
16    }
17}

You can also use tools such as ViewThatFits, flexible frames, LazyVGrid, and Spacer to let SwiftUI adapt automatically instead of branching on hardcoded width thresholds.

Reading Width in a Reusable Way

If several views need container width, wrap the pattern so the layout code stays tidy:

1import SwiftUI
2
3struct WidthReader<Content: View>: View {
4    let content: (CGFloat) -> Content
5
6    var body: some View {
7        GeometryReader { geo in
8            content(geo.size.width)
9        }
10    }
11}

Usage:

WidthReader { width in
    Text("Width: \(Int(width))")
}

This keeps geometry concerns local and avoids repeating the same setup throughout the view tree.

Common Pitfalls

One common mistake is using UIScreen.main.bounds.width for child-view layout inside a sheet or nested container. That often overestimates the real available width and breaks the design.

Another mistake is assuming the width is fixed. Rotation, multitasking, and dynamic window changes can alter available width during runtime.

Developers also sometimes reach for manual width breakpoints when SwiftUI’s adaptive layout tools would express the intent more directly and with less maintenance.

Finally, be clear about whether you need device width or local container width. Those are different measurements and should not be treated as interchangeable.

Summary

• Use GeometryReader when you need the width available to a specific SwiftUI view.
• Use UIScreen.main.bounds.width only when you truly need the global device screen width.
• Container width is usually more useful than raw screen width for layout decisions.
• Size classes and adaptive SwiftUI layout tools often remove the need for manual width checks.
• Most layout bugs come from confusing device metrics with local layout space.