title: Unavoidable retain cycle using UISearchBar as UITableView's header view?
body: <p>I ran into this issue as I was building out a basic UI that makes use of a <code>UISearchController</code> and it's <code>UISearchBar</code> member. My tableView is a weak IBOutlet, and like the Apple Docs demonstrate, I set its tableHeaderView property to be the search bar member.</p>
  
  <pre><code>//Snippet from viewDidLoad
  UISearchController* searchController = [self createSearchController];
  UISearchBar* searchBar = searchController.searchBar;
  searchBar.userInteractionEnabled = NO;
  
  self.tableView.tableHeaderView = searchBar; //The assignment in question
  
  [NetworkStuff makeCall:^(Response *response) {
      //handle success
      searchBar.userInteractionEnabled = YES; //local variables
      searchController.active = YES;
      ...
  } failure:^(Response *response) {
      //handle failure
      ...
  }];
  </code></pre>
  
  <p>When I pop the view off of the stack, its dealloc method never gets called, even if I set the tableHeaderView to nil in <code>viewWillDisappear:</code>. The only line I need to comment out to see dealloc called is that initial assignment. </p>
  
  <p>Anyone have any insight as to why this might be happening?</p>
  
  <p>EDIT: </p>
  
  <p>Found some interesting behavior. Also per the Apple Docs I set the controller's <code>definesPresentationContext</code> variable to <code>YES</code>. Commenting that out while leaving the tableViewHeader assignment in fixed the retain cycle, even if I didn't nil out the tableViewHeader. However, setting <code>definesPresentationContext</code> in <code>viewDidLoad</code> and clearing it in <code>viewWillDisappear</code> re-introduces the retain cycle.</p>