Introduction

If you used didRotateFromInterfaceOrientation in older UIKit code, the modern replacement is not a one-for-one method with the same timing. Apple’s current approach is size-transition driven, with Auto Layout, trait collections, and viewWillTransition(to:with:) handling most of the work that older orientation callbacks used to manage manually.

Why the Old Rotation Methods Were Deprecated

Earlier iOS APIs exposed rotation as a direct orientation event. That matched a simpler world of phones, full-screen apps, and manual frame calculations.

Modern UIKit has to support much more:

• Auto Layout instead of manual frame math
• split view and multitasking on iPad
• size class changes that are not simple portrait-versus-landscape flips
• container view controllers that coordinate transitions

Because of that, UIKit now models the event as a size transition rather than “the device rotated.” In other words, your code should react to the new layout environment, not to a specific orientation callback.

The Main Replacement: viewWillTransition(to:with:)

For most cases, the method you want is viewWillTransition(to:with:).

1import UIKit
2
3final class DemoViewController: UIViewController {
4    override func viewWillTransition(
5        to size: CGSize,
6        with coordinator: UIViewControllerTransitionCoordinator
7    ) {
8        super.viewWillTransition(to: size, with: coordinator)
9
10        coordinator.animate(alongsideTransition: { _ in
11            self.view.layoutIfNeeded()
12        }, completion: { _ in
13            self.updateLayoutAfterTransition(size: size)
14        })
15    }
16
17    private func updateLayoutAfterTransition(size: CGSize) {
18        print("New size: \(size)")
19    }
20}

The important detail is the transition coordinator. If you need code that runs after the rotation or resize animation completes, put it in the completion block. That is the closest modern equivalent to the old “did rotate” timing.

When Auto Layout Is Enough

A large amount of old rotation code no longer needs any direct replacement at all. If your layout is constraint-based and your views adapt correctly, the best solution is often to delete the old rotation logic.

Examples that usually should be handled by constraints instead of manual rotation code:

• resizing a table view to fill the screen
• centering a button after rotation
• moving labels when width changes
• switching stack spacing for compact versus regular layouts

When the layout is described correctly through constraints, the system applies the transition and your code stays smaller.

Use Trait Changes for Environment-Specific Behavior

Some UI changes are really about size classes or interface environment, not about rotation itself. In those cases, checking traits can be more expressive than checking whether the device is in landscape.

1override func traitCollectionDidChange(_ previousTraitCollection: UITraitCollection?) {
2    super.traitCollectionDidChange(previousTraitCollection)
3
4    if traitCollection.horizontalSizeClass != previousTraitCollection?.horizontalSizeClass {
5        configureForCurrentSizeClass()
6    }
7}

This matters because a size-class change can happen without a classic rotation event, especially on iPad.

If You Need the “After Rotation” Moment

A common complaint is that viewWillTransition(to:with:) sounds like a “before” callback, while didRotateFromInterfaceOrientation was clearly “after.” The transition coordinator solves that gap.

Use the coordinator’s completion block for work that depends on the final geometry being settled. For example:

• scrolling to a corrected content offset
• recalculating a custom drawing path
• restarting an animation that depends on final bounds
• invalidating a complex collection view layout

That is the practical replacement pattern, not a separate viewDidTransition API.

Avoid Device Orientation As a Layout Driver

Many legacy codebases ask UIDevice.current.orientation and branch into portrait or landscape logic. That is usually weaker than reacting to the actual view size. Device orientation can be unknown, face-up, or irrelevant when the interface is not full-screen.

If your layout decision is really “is the available width wide enough for a two-column view,” then measure width or size classes directly. That produces more robust UI code than orientation-specific branching.

Common Pitfalls

The most common mistake is searching for a direct replacement with the same semantics as didRotateFromInterfaceOrientation. Modern UIKit expects you to think in terms of transitions and layout, not orientation callbacks.

Another common problem is putting expensive layout code directly into viewWillTransition without using the transition coordinator. If the work depends on the final frame, run it in the completion block.

Developers also often keep manual frame code that fights Auto Layout. If constraints already describe the intended layout, manual adjustments can cause flicker or conflicting results.

Finally, avoid using device orientation as the primary source of truth for interface changes. The actual container size is usually what matters.

Summary

• The modern replacement for old rotation callbacks is usually viewWillTransition(to:with:).
• Use the transition coordinator completion block when you need “after rotation” timing.
• Prefer Auto Layout and trait-based adaptation over manual orientation code.
• React to size and environment changes, not just portrait-versus-landscape assumptions.
• In many cases, the correct replacement is simply removing old rotation code and letting constraints handle the layout.