Search Bar in a Navigation Item Collapses and Gets Stuck Under Status Bar Upon Navigation Pop, on iOS 11

TableView first cell hidden under search bar when returning to view

Solved, I set searchController.hidesNavigationBarDuringPresentation = false, which caused the bug. See the answer on this post: Search Bar in a Navigation Item collapses and gets stuck under status bar upon navigation pop, on iOS 11.

Thanks for the help!

I can't implement a search bar with this modelView

You could try this approach as shown in this example code:

struct Device: Identifiable {
    let id = UUID()
    var make = ""
    var model = ""
    var type = ""
}

class DevicesViewModel: ObservableObject {
    @Published var devices: [Device] = []
    
    init() {
        getData() // <--- here
    }
    
    func getData() {
        devices = [Device(make: "1", model: "model1", type: "type1"),
                   Device(make: "2", model: "model2", type: "type2"),
                   Device(make: "3", model: "model3", type: "type3")]
    }
}

struct MedicalView: View {
    @StateObject var modelView = DevicesViewModel() // <--- here
    
    @State var searchText = ""
    @State private var showingAlert = false
    
    var searchMake: [Device] { // <--- here
        if searchText.isEmpty {
            return modelView.devices
        } else {
            return modelView.devices.filter{ $0.make.lowercased().localizedCaseInsensitiveContains(searchText.lowercased()) } // <--- here
        }
    }
    
    var body: some View {
        NavigationView {
            VStack {
                List (searchMake) { device in  // <--- here
                    HStack {
                        VStack {
                            Text("\(device.make)")
                                .font(.system(size: 20, weight: .heavy, design: .rounded))
                            Text("\(device.model)")
                                .font(.system(size: 20, weight: .heavy, design: .rounded))
                                .foregroundColor(.white)
                                .shadow(color: .black, radius: 1)
                            Text("\(device.type)")
                                .font(.system(size: 16, weight: .heavy, design: .rounded))
                                .foregroundColor(.blue)
                        }
                    }
                }
            }.listStyle(.plain)
             .searchable(text: $searchText)
        }
    }
}

iOS 11 large-title navigation bar not collapsing

Good news! I've just figured out that if I set "Large Titles" to "Never" on the storyboard, and then set it via code, then it works:

- (void)viewDidLoad {
    [super viewDidLoad];
    self.navigationItem.largeTitleDisplayMode = UINavigationItemLargeTitleDisplayModeAutomatic;
}

Seems like Apple forgot to handle the case when the navigation item has its largeTitleDisplayMode set via the Interface Builder.

So until they fix this issue, leave "Large Titles" as "Never" on storyboards, and set them via code in viewDidLoad.

You just need to do that to the first view controller. Subsequent view controllers honor the value in storyboard.

Navigation bar title bug with interactivePopGestureRecognizer

Remove Red Herrings

First of all, your example can be greatly simplified. You should delete all the viewDidLoad stuff, as it is a complete red herring and just complicates the issue. You should not be playing around with the pop gesture recognizer delegate on every change of view controller; and turning the pop gesture recognizer off and on is irrelevant to the example (it is on by default, and should just be left on for this example). So delete this kind of thing in all three view controllers:

- (void)viewDidLoad {
    [super viewDidLoad];
    if ([self.navigationController respondsToSelector:@selector(interactivePopGestureRecognizer)]) {
        self.navigationController.interactivePopGestureRecognizer.enabled = NO;
        self.navigationController.interactivePopGestureRecognizer.delegate = self;
    }
}

(Don't delete the code that sets self.title, though you could have made things even simpler by doing that in the xib file for each view controller.)

You can also get rid of other unused methods throughout, such as the init... methods and memory alert methods.

Another issue, by the way, is that you have forgotten to call super in your implementations of viewWillAppear:. It is required that you do this. I don't think that affects the bug, but it is well to obey all the rules before you start trying to track these things down.

Now the bug still happens but we have much simpler code, so we can start to isolate the issue.

How The Pop Gesture Works

So what's the cause of the problem? I think the most obvious way to understand it is to realize how the pop gesture works. This is an interactive view controller transition animation. That's right - it's an animation. The way it works is that the pop animation (slide from the left) is attached to the superview layer, but with a speed of 0 so that it doesn't actually run. As the gesture proceeds, the timeOffset of the layer is constantly being updated, so that the corresponding "frame" of the animation appears. Thus it looks like you are dragging the view, but you are not; you are just making a gesture, and animation is proceeding at the same rate and to the same degree. I have explained this mechanism in this answer: https://stackoverflow.com/a/22677298/341994

Most important (pay attention to this part), if the gesture is abandoned in the middle (which it almost certainly will be), a decision is made as to whether the gesture is more than half-way completed, and based on this, either the animation is rapidly played to the end (i.e. the speed is set to something like 3) or the animation is run backwards to the start (i.e. the speed is set to something like -3).

Solutions And Why They Work

Now let's talk about the bug. There are two complications here that you've accidentally banged into:

• As the pop animation and pop gesture begin, viewWillAppear: is called for the previous view controller even though the view may not ultimately appear (because this is an interactive gesture and the gesture may be cancelled). This can be a serious issue if you are used to the assumption that viewWillAppear: is always followed by the view actually taking over the screen (and viewDidAppear: being called), because this is a situation in which those things might not happen. (As Apple says in the WWDC 2013 videos, "view will appear" actually means "view might appear".)

• There is a secondary set of animations, namely, everything connected with the navigation bar - the change of title (it is supposed to fade into view) and, in this case, the change between not hidden and hidden. The runtime is trying to coordinate the secondary set of animations with the sliding view animation. But you have made that difficult by calling for no animation when the bar is hidden or shown.

Thus, as you've already been told, one solution is to change animated:NO to animated:YES throughout your code. This way, the showing and hiding of the navigation bar is ordered up as part of the animation. Therefore, when the gesture is cancelled and the animation is run backwards to the start, the showing/hiding of the navigation is also run backwards to the start - the two things are now staying coordinated.

But what if you really don't want to make that change? Well, another solution is to change viewWillAppear: to viewDidAppear: throughout. As I've already said, viewWillAppear: is called at the start of the animation, even if the gesture won't be completed, which is causing things to get out of whack. But viewDidAppear: is called only if the gesture is completed (not canceled) and when the animation is already over.

Which of those two solutions do I prefer? Neither of them! They both force you to make changes you don't want to make. The real solution, it seems to me, is to use the transition coordinator.

The Transition Coordinator

The transition coordinator is an object supplied by the system for this very purpose, i.e., to detect that we're involved in an interactive transition and to behave differently depending on whether it is canceled or not.

Concentrate just on the OneViewController implementation of viewWillAppear:. This is where things are getting messed up. When you're in TwoViewController and you start the pan gesture from the left, OneViewController's viewWillAppear: is being called. But then you cancel, letting go of the gesture without completing it. In just that one case, you want not to do what you were doing in OneViewController's viewWillAppear:. And that is exactly what the transition coordinator allows you to do.

Here, then, is a rewrite of OneViewController's viewWillAppear:. This fixes the problem without your having to make any other changes:

-(void)viewWillAppear:(BOOL)animated{
    [super viewWillAppear:animated];
    id<UIViewControllerTransitionCoordinator> tc = self.transitionCoordinator;
    if (tc && [tc initiallyInteractive]) {
        [tc notifyWhenInteractionEndsUsingBlock:
         ^(id<UIViewControllerTransitionCoordinatorContext> context) {
             if ([context isCancelled]) {
                 // do nothing!
             } else { // not cancelled, do it
                 [self.navigationController setNavigationBarHidden:YES animated:NO];
             }
         }];
    } else { // not interactive, do it
        [self.navigationController setNavigationBarHidden:YES animated:NO];
    }
}

---

Related Topics