Proposal: Add a System Readable Content Layout to SwiftUI
SwiftUI currently does not provide a native equivalent of UIKit's UIView.readableContentGuide.
For content-heavy applications such as articles, documentation, settings, email, and media descriptions, developers often need to prevent text from becoming excessively wide on iPad, Mac, and other large displays.
UIKit already provides a system-level solution through:
view.readableContentGuide
However, there is currently no equivalent API in SwiftUI.
Current Workarounds
Developers currently have to choose between several approaches, none of which provides the same behavior as UIKit's readableContentGuide.
1. Hard-coded maximum width
content
.frame(maxWidth: 700)
This is simple, but the value is arbitrary and does not adapt to the platform, window size, Dynamic Type, or system layout rules.
2. containerRelativeFrame
A developer can approximate a readable width:
content
.containerRelativeFrame(.horizontal) { length, axis in
length * 0.52
}
However, this is only an approximation. Developers still have to determine the appropriate ratio themselves, and the result does not necessarily match the system's readable content width.
3. Bridging to UIKit
Another workaround is to create a UIKit view/controller and obtain:
view.readableContentGuide.layoutFrame
The resulting width can then be passed back into SwiftUI.
This works for iOS and iPadOS, but introduces UIKit-specific implementation details into an otherwise pure SwiftUI view and does not provide a natural cross-platform solution for macOS, tvOS, and other SwiftUI platforms.
Proposed API
I propose that SwiftUI provide a system-defined readable content layout.
For example:
.contentWidth(.readable)
or a dedicated layout/container:
ReadableContent {
content
}
Another possibility would be a layout guide exposed through the SwiftUI environment:
@Environment(\.readableContentGuide)
private var readableContentGuide
allowing:
content
.frame(
maxWidth: readableContentGuide.width
)
The exact API design is of course up to Apple, but the important part is that the readable width should be determined by the system rather than by application-specific constants.
Expected Behavior
The readable content width should be determined by the current platform and environment, taking into account factors such as:
Available window/container size
Platform-specific layout conventions
Dynamic Type / accessibility text sizes
Layout margins
Safe areas
Orientation
Size classes where applicable
Current window size on macOS
Appropriate platform-specific readable widths
For example, the same SwiftUI view could behave naturally across devices:
iPhone
┌─────────────────────────┐
│ │
│ Readable content │
│ │
└─────────────────────────┘
iPad
┌─────────────────────────────────────────────┐
│ │
│ ┌───────────────────────┐ │
│ │ Readable content │ │
│ └───────────────────────┘ │
│ │
└─────────────────────────────────────────────┘
Mac
┌──────────────────────────────────────────────────────────────┐
│ │
│ ┌───────────────────────┐ │
│ │ Readable content │ │
│ └───────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────┘
The developer should not need to know the exact width used by the system.
Why This Belongs in SwiftUI
SwiftUI already provides many environment-driven layout behaviors that automatically adapt to the current platform and device.
Readable content width is similarly a semantic layout concept, rather than a fixed visual dimension.
For example, developers generally should not need to write:
#if os(iOS)
let maxWidth = 700
#elseif os(macOS)
let maxWidth = 800
#elseif os(tvOS)
let maxWidth = 1000
#endif
A system-provided readable layout would allow the application to express its intent instead:
ReadableContent {
ArticleView()
}
This would also make SwiftUI applications more resilient to future platform changes because Apple could adjust the underlying readable-content rules without requiring developers to update hard-coded constants.
Use Cases
This would be particularly useful for:
Article and reading applications
Documentation viewers
News applications
Email clients
Settings and preference screens
Legal/privacy documents
Markdown viewers
AI/chat applications
Book and EPUB readers
Media descriptions and metadata
Forms containing large amounts of text
Relationship to UIKit
UIKit already establishes a precedent with:
UIView.readableContentGuide
SwiftUI developers should have access to the same semantic concept without needing to bridge through UIKit.
The SwiftUI API does not necessarily need to expose the UIKit implementation. It could instead provide a platform-independent abstraction whose implementation is appropriate for each SwiftUI platform.
Summary
I would like to request a native SwiftUI API for system-defined readable content width.
The ideal solution would allow developers to express:
ReadableContent {
ArticleView()
}
or:
ArticleView()
.contentWidth(.readable)
while SwiftUI automatically determines the appropriate readable width for the current platform, window, Dynamic Type settings, and layout environment.
This would eliminate the need for hard-coded maximum widths and platform-specific UIKit/AppKit workarounds, while bringing SwiftUI closer to the adaptive layout behavior already available in UIKit through readableContentGuide.
1
1
327