Introduction

In UIKit, hiding the back button is easy mechanically but should be done carefully because it changes how users leave a screen. The standard approach is to set navigationItem.hidesBackButton, but the right design depends on whether you only want to hide the visible button or also control swipe-back behavior and custom exit actions.

Basic way to hide the back button

For a view controller inside a UINavigationController, the most direct solution is:

1import UIKit
2
3final class CheckoutViewController: UIViewController {
4    override func viewDidLoad() {
5        super.viewDidLoad()
6        navigationItem.hidesBackButton = true
7    }
8}

This removes the standard back button from the navigation bar for that controller.

If the screen is created from code before being shown, you can also set it earlier:

let vc = CheckoutViewController()
vc.navigationItem.hidesBackButton = true
navigationController?.pushViewController(vc, animated: true)

Add your own exit control when needed

Hiding the back button is usually not enough on its own. If the user still needs a way out, add a custom bar button item.

1import UIKit
2
3final class CheckoutViewController: UIViewController {
4    override func viewDidLoad() {
5        super.viewDidLoad()
6        navigationItem.hidesBackButton = true
7        navigationItem.leftBarButtonItem = UIBarButtonItem(
8            title: "Cancel",
9            style: .plain,
10            target: self,
11            action: #selector(cancelTapped)
12        )
13    }
14
15    @objc private func cancelTapped() {
16        navigationController?.popViewController(animated: true)
17    }
18}

This is common in flows such as checkout, onboarding, or form entry where you want a clearer label than a generic back arrow.

Hiding the button does not always disable swipe-back

A subtle point is that hiding the visible back button does not necessarily stop the interactive edge-swipe gesture. Depending on the navigation controller setup, the user may still be able to go back with the swipe gesture.

If you must fully block backward navigation, you may need to manage the gesture recognizer too:

1override func viewDidAppear(_ animated: Bool) {
2    super.viewDidAppear(animated)
3    navigationController?.interactivePopGestureRecognizer?.isEnabled = false
4}
5
6override func viewWillDisappear(_ animated: Bool) {
7    super.viewWillDisappear(animated)
8    navigationController?.interactivePopGestureRecognizer?.isEnabled = true
9}

Use this sparingly. Blocking expected navigation can make the app feel broken if the reason is not clear.

Hide the title on the previous screen instead

Sometimes the real goal is not to remove the back button entirely, but to simplify its appearance. In that case, change the back button display of the previous controller rather than hiding navigation completely.

1override func viewDidLoad() {
2    super.viewDidLoad()
3    navigationItem.backButtonDisplayMode = .minimal
4}

That keeps native navigation behavior while reducing clutter.

Good use cases

Hiding the back button is usually justified when:

• leaving the screen would corrupt an in-progress transaction
• the user must complete or explicitly cancel a flow
• the screen is the root of a custom flow with its own controls

It is usually a bad idea when:

• the screen is part of ordinary content browsing
• there is no replacement exit action
• the only reason is cosmetic preference

In other words, treat it as a navigation decision, not just a styling tweak.

SwiftUI note

If the screen is actually SwiftUI rather than UIKit, the API is different:

.navigationBarBackButtonHidden(true)

But the same product questions still apply. Hiding navigation chrome is easy. Preserving usable navigation is the harder part.

Common Pitfalls

The most common mistake is hiding the back button without providing any alternative way to leave the screen. Another is assuming that hiding the button also disables the interactive swipe-back gesture, which is not always true. Developers also sometimes use back-button hiding to paper over a flawed navigation flow instead of fixing the flow itself. In mixed UIKit and SwiftUI projects, it is easy to apply the wrong API to the wrong stack. Finally, removing expected navigation affordances without user testing often creates confusion, especially for screens that do not clearly explain why backward navigation is blocked.

Summary

• Use navigationItem.hidesBackButton = true to hide the standard back button in UIKit.
• Add a custom left bar button if the user still needs a clear exit path.
• Remember that hiding the button does not always disable swipe-back behavior.
• Consider minimizing the back button instead of removing it if the goal is visual cleanup.
• Hide navigation controls only when the flow genuinely requires it.
• Treat back-button decisions as part of UX design, not just view styling.