Detecting when the 'back' button is pressed on a navbar
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
In UIKit, there is no dedicated public callback that literally says "the user tapped the navigation bar back button." What you can reliably detect is that the view controller is being popped from its parent navigation controller. That distinction matters, because a pop can be triggered by the back button, the interactive swipe gesture, or code.
Detecting a Pop in viewWillDisappear
The most common pattern is checking isMovingFromParent inside viewWillDisappear.
This works well when your goal is to run cleanup logic, save transient state, cancel work, or notify another object that the screen is being left permanently.
Why viewWillDisappear Alone Is Not Enough
viewWillDisappear is called in more situations than a back navigation. It also runs when another controller is pushed on top, when a modal presentation covers the view, and during some transition flows.
That means this is too broad:
The fix is the isMovingFromParent check. It narrows the event to "this controller is leaving the navigation stack."
Using willMove(toParent:)
Another solid option is overriding willMove(toParent:) and checking whether the new parent is nil.
This is useful when you want to hook into the containment change directly rather than a view lifecycle callback.
Detecting the Exact Back Button Tap
If you truly need to know that the user tapped the default back button, not just that the controller was popped, UIKit does not provide a perfect public callback for that exact event. A pop can also happen through:
- Edge-swipe back navigation
- Programmatic
popViewController - Popping to root or to another controller
If you need behavior tied to the exact tap itself, the usual solution is to replace the default back button with a custom left bar button item and handle the action yourself.
This gives exact control, but it also means you are no longer using the system-provided back button behavior automatically.
Choosing the Right Approach
If you need cleanup when leaving the screen, detect the pop. If you need to intercept navigation before it happens, use a custom back button. If you only need to know that the controller disappeared for any reason, viewDidDisappear may be enough.
That separation is important because many bugs come from mixing up "screen is disappearing" with "user tapped back".
Common Pitfalls
One common mistake is assuming viewWillDisappear means the back button was tapped. It does not. The controller may just be covered by another screen.
Another issue is forgetting the interactive swipe gesture. A user can leave the screen without touching the back button at all, but from a navigation perspective the controller is still being popped.
Developers also sometimes replace the system back button unnecessarily. That can remove built-in behavior, alter visual consistency, and complicate accessibility if the only real need was cleanup on pop.
Finally, if you trigger asynchronous save logic before popping, be careful about user experience. A custom back button may be necessary if you need to delay the navigation until the save completes.
Summary
- UIKit does not expose a perfect public callback for the default back-button tap itself.
- Use
isMovingFromParentinviewWillDisappearto detect that a controller is being popped. - Use
willMove(toParent:)withparent == nilas another reliable pop-detection pattern. - Replace the back button with a custom item only when you truly need tap-level control.
- Distinguish between "screen disappeared" and "user tapped back" to avoid lifecycle bugs.

