Introduction

If you want to run a function after an iOS interface has finished rotating, the most reliable place in a view controller is the completion block of viewWillTransition(to:with:). That method is called during size-class and orientation transitions, and the transition coordinator lets you run code after the animation finishes.

This is better than guessing with timers or reacting too early in a notification. The key is that "after rotation" usually means after the layout transition is complete, not merely after the device orientation value changed.

The Best Place: viewWillTransition(to:with:)

Override the method on your view controller and use the coordinator completion block:

1import UIKit
2
3final class ViewController: UIViewController {
4    override func viewWillTransition(to size: CGSize,
5                                     with coordinator: UIViewControllerTransitionCoordinator) {
6        super.viewWillTransition(to: size, with: coordinator)
7
8        coordinator.animate(alongsideTransition: nil) { _ in
9            self.didFinishRotation(to: size)
10        }
11    }
12
13    private func didFinishRotation(to size: CGSize) {
14        print("rotation finished, new size: \(size)")
15    }
16}

That completion block runs after the transition animation completes, which is usually what developers mean by "after the device has rotated."

Why This Is Better Than Orientation Notifications

You can observe UIDevice.orientationDidChangeNotification, but that notification is about device orientation, not necessarily the final interface layout state.

That difference matters because:

• the device can rotate even if the interface does not
• the orientation value may change before Auto Layout finishes adjusting views
• multitasking and size changes on iPad are really about view size, not just orientation

For UI updates tied to layout, view-controller transition APIs are usually the better fit.

A Practical Example

Suppose you need to recalculate a collection view layout after rotation:

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    }, completion: { _ in
8        self.reloadVisibleContent()
9    })
10}
11
12private func reloadVisibleContent() {
13    collectionView.reloadData()
14}

Here, layout invalidation happens during the transition, and the expensive or final follow-up work happens after the rotation completes.

If You Only Need Updated Layout Values

Sometimes the simpler solution is not a rotation callback at all. If your goal is just to react to final layout sizes, viewDidLayoutSubviews() may be enough.

That method runs whenever the view lays out its subviews, including after rotation:

1override func viewDidLayoutSubviews() {
2    super.viewDidLayoutSubviews()
3    print(view.bounds.size)
4}

Use this when the real requirement is "after layout changed" rather than specifically "after rotation animation ended."

Avoid Old Orientation APIs for New Layout Logic

Older code often checks UIDevice.current.orientation directly and branches on portrait or landscape values. That can still be useful in some cases, but modern iOS layout logic is usually better expressed through size, traits, or transition callbacks.

For example:

1private func didFinishRotation(to size: CGSize) {
2    if size.width > size.height {
3        print("landscape-style layout")
4    } else {
5        print("portrait-style layout")
6    }
7}

This is often more reliable than reasoning about raw device orientation enums.

Common Pitfalls

The biggest pitfall is running the function too early. viewWillTransition itself is called before the rotation finishes, so put post-rotation work in the coordinator completion block if you truly need the final state.

Another common mistake is using orientation notifications for UI layout work. Those notifications do not always line up with the final interface geometry you care about.

Developers also sometimes forget that iPad size changes and multitasking can trigger similar layout transitions even when the device did not physically rotate. Thinking in terms of size changes is often more robust than thinking only in terms of orientation.

Finally, avoid hardcoded delays. Using DispatchQueue.main.asyncAfter to guess when rotation is done is fragile compared with the transition coordinator.

Summary

• To run code after rotation finishes, use the completion block of viewWillTransition(to:with:).
• This is more reliable than timers and usually better than orientation notifications for UI layout work.
• Use viewDidLayoutSubviews() when the real need is reacting to final layout changes rather than animation completion.
• Prefer working with view size and traits instead of raw orientation values when possible.
• Put truly post-rotation work in the transition coordinator completion block, not directly in viewWillTransition.