Introduction

Detecting orientation changes in Swift depends on what you actually need: device orientation, interface orientation, or size-class layout changes. Many legacy implementations use notifications directly, but modern iOS apps often rely on view lifecycle and trait updates for UI adaptation. Choosing the wrong signal can produce incorrect behavior in multitasking, rotation lock scenarios, or split view. A robust solution combines appropriate callbacks with layout-safe update logic.

Core Sections

1. Use viewWillTransition for UI updates

1override func viewWillTransition(to size: CGSize,
2                                 with coordinator: UIViewControllerTransitionCoordinator) {
3    super.viewWillTransition(to: size, with: coordinator)
4
5    coordinator.animate(alongsideTransition: { _ in
6        self.collectionView.collectionViewLayout.invalidateLayout()
7    })
8}

This is the preferred hook for view-controller layout adjustments.

2. Observe device orientation notifications when needed

1NotificationCenter.default.addObserver(
2    self,
3    selector: #selector(orientationDidChange),
4    name: UIDevice.orientationDidChangeNotification,
5    object: nil
6)
7
8@objc private func orientationDidChange() {
9    let o = UIDevice.current.orientation
10    print(o)
11}

Use for sensor-like behavior, not primary layout logic.

3. SwiftUI orientation handling

In SwiftUI, prefer geometry/size class reactions over raw orientation checks.

@Environment(\.horizontalSizeClass) var hSize

This is more resilient across iPad multitasking modes.

4. Avoid deprecated status bar APIs

Do not rely on old statusBarOrientation patterns. Modern apps should use scene/view controller APIs and size transitions.

5. Rotation lock and flat device states

UIDeviceOrientation can be .faceUp, .faceDown, or .unknown. Handle these states to avoid false layout changes.

6. Testing strategy

Test orientation-dependent behavior on iPhone and iPad, including split view and multitasking. Simulators can miss some device-sensor edge cases, so verify on physical hardware for critical flows.

Validation and production readiness

A working snippet is only the first step. To make the solution dependable, validate behavior under representative inputs and operating conditions. Build a small test matrix that includes normal cases, boundary values, and malformed data so failure modes are explicit. If the topic involves time, concurrency, or networking, add at least one test that simulates delayed execution and one test that verifies timeout handling. This catches race conditions and environment-specific bugs that rarely appear in local happy-path runs.

Operational clarity matters as much as correctness. Document assumptions near the implementation: runtime version, required dependencies, expected timezone or locale rules, and platform limitations. Ambiguous assumptions are a major source of production incidents because teammates run the same logic under different defaults. Use structured logs around critical branches and external calls so debugging does not require ad hoc reproduction. Logs should include identifiers and concise context, but avoid sensitive payloads.

For recurring jobs or frequently executed code paths, add observability and guardrails. Define simple success metrics, retry boundaries, and explicit rollback or fallback behavior. Silent retries with no upper limit can hide systemic failures and increase downstream impact. Keep a lightweight pre-deploy checklist in source control so changes remain auditable and repeatable across environments.

1release_checklist:
2  - tests cover edge cases and failure paths
3  - runtime and dependency versions documented
4  - logs/metrics confirm expected execution path
5  - retries and timeouts are bounded
6  - rollback or fallback plan is defined

Teams that treat these checks as part of the default implementation workflow usually spend less time on incident triage and more time shipping stable improvements.

Common Pitfalls

• Using device orientation notifications as the sole layout trigger.
• Ignoring .unknown and flat orientation states.
• Depending on deprecated status-bar orientation APIs.
• Failing to re-run layout invalidation during animated transitions.
• Assuming portrait/landscape logic covers iPad multitasking cases.

Summary

For Swift orientation handling, use viewWillTransition and trait/size-class signals for layout, and device orientation notifications only when truly needed. This separation improves correctness across modern iOS windowing behaviors. With proper edge-case handling and cross-device testing, orientation-driven UI updates remain stable.