Introduction

Hiding the back button in iOS is straightforward, but the right approach depends on whether you are using UIKit or SwiftUI. The harder part is deciding whether hiding it is the correct UX choice, because removing the standard navigation affordance also removes a predictable escape path for the user.

UIKit: Hide It on the Pushed Screen

In UIKit, the back button belongs to the navigation item of the view controller currently being shown. That means you hide it from the destination screen, not from the previous one.

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

If this controller is pushed inside a UINavigationController, the default back button disappears.

If you want to replace it with your own button, add a custom left bar button item:

1override func viewDidLoad() {
2    super.viewDidLoad()
3    navigationItem.hidesBackButton = true
4    navigationItem.leftBarButtonItem = UIBarButtonItem(
5        title: "Close",
6        style: .plain,
7        target: self,
8        action: #selector(closeTapped)
9    )
10}
11
12@objc private func closeTapped() {
13    navigationController?.popViewController(animated: true)
14}

This is common when you need custom wording or custom flow rules.

SwiftUI: Use .navigationBarBackButtonHidden

In SwiftUI, the equivalent is a view modifier on the destination view.

1import SwiftUI
2
3struct DetailsView: View {
4    var body: some View {
5        Text("Details")
6            .navigationTitle("Details")
7            .navigationBarBackButtonHidden(true)
8    }
9}

If you hide the default button, you normally also add your own toolbar control so navigation is still possible.

1import SwiftUI
2
3struct DetailsView: View {
4    @Environment(\\.dismiss) private var dismiss
5
6    var body: some View {
7        Text("Details")
8            .navigationTitle("Details")
9            .navigationBarBackButtonHidden(true)
10            .toolbar {
11                ToolbarItem(placement: .topBarLeading) {
12                    Button("Close") {
13                        dismiss()
14                    }
15                }
16            }
17    }
18}

This gives you a custom button while keeping navigation behavior explicit.

When Hiding the Back Button Makes Sense

There are valid cases:

• a forced onboarding or login completion step
• a confirmation screen where returning would break state assumptions
• a modal flow that should close rather than pop

Even in those cases, be careful. If the user needs a way out, hiding the system back button without a replacement often creates a dead end.

In many apps, changing the button title or using a modal presentation is better than removing navigation entirely.

Navigation Stack Behavior Still Exists

Hiding the button does not remove the navigation stack itself. The controller or view is still usually inside a stack, and the user may still be able to swipe back unless you explicitly disable interactive navigation behavior in UIKit. That means "hide button" and "prevent backward navigation" are related but not identical tasks.

If you must block the edge-swipe gesture too, you need additional UIKit navigation-controller handling. That is a stronger decision and should be taken carefully.

Common Pitfalls

• Trying to hide the back button from the source controller instead of the destination controller.
• Removing the default button without providing another clear exit path.
• Assuming hiding the button also disables the swipe-back gesture.
• Mixing UIKit and SwiftUI navigation APIs in the same flow without understanding which layer owns the stack.
• Using back-button hiding to patch a navigation design problem that should be fixed structurally.

Summary

• In UIKit, set navigationItem.hidesBackButton = true on the pushed view controller.
• In SwiftUI, use .navigationBarBackButtonHidden(true) on the destination view.
• Add a custom leading toolbar or bar button if users still need a controlled way back.
• Hiding the button does not automatically remove the underlying navigation stack.
• Use this pattern sparingly, because removing standard navigation can easily hurt usability.