iOS 11에서 UISearchBar의 높이가 기존 44에서 56으로 변경되었습니다. 대부분의 경우 큰 문제는 없지만 네비게이션바와 함께 사용하는 경우 높이 변경으로 인해 문제가 발생했습니다.

네비게이션바의 titleView에 UISearchBar를 사용하는 경우 네비게이션바의 높이인 44를 넘어가게 되어 검색이후의 화면에서 네비게이션바 하단에 검정색 공백이 생기는 문제가 있었는데요.

현상

아래 개발화면의 스샷은 왼쪽의 첫번째 화면의 네비게이션바에 UISearchBar가 있고 두번째 화면이 검색결과를 눌렀을때 이동하는 화면입니다.

첫번째 화면과 두번째 화면의 네비게이션 바의 높이가 달라진것을 볼 수 있고 이로 인해 두번째 화면의 네비게이션바 하단에 검정색 공백이 추가됩니다.

이는 앞서 이야기 했던 UISearchBar의 높이가 44에서 56으로 변경된것에 따른 영향으로 첫번째 화면에서는 네비게이션바의 높이가 UISearchBar의 높이에 맞게 56으로 늘어났고 두번째 화면에서는 이전화면의 높이인 56픽셀보다 적은 44픽셀의 네비게이션바를 보여주면서 12픽셀 만큼의 검정색 공백이 생기는 문제입니다. iOS에서 똑똑하게 변경해주면 되는데 이게 처리가 안되더라구요.

해결

우선 첫번째 실패한 해결방법은 SearchBar의 높이를 44로 강제 설정하는것입니다. frame 정보를 변경하는것으로는 안되고 heightAnchor 값을 설정해줘야합니다. 아래 코드를 적용합니다.

if #available(iOS 11.0, *) {
    searchBar.heightAnchor.constraint(equalToConstant: 44).isActive = true
}

이렇게 하면 높이가 44로 잘 변경되지만 UISearchBar에 글자를 입력하기위해 포커스를 가져가면 UISearchBar가 살짝 내려오는 문제가 생깁니다. 이 문제는 어떻게 해결할 방법이 없더라구요 ㅜㅜ

살짝 내려오니까 내가 뭔가를 수정하면 되겠구나 싶어서 삽질을 계속해서 해봤지만 무슨수를 써도 안되더라구요 ㅜㅜ

최종적으로 해결한 방법은 UISearchBar를 감싸는 UIView를 하나 만들고 이 뷰의 frame 값을 강제로 지정하는 것입니다.

class SearchBarContainerView: UIView {
    let searchBar: UISearchBar
    init(customSearchBar: UISearchBar) {
        searchBar = customSearchBar
        super.init(frame: CGRect.zero)
        addSubview(searchBar)
    }

    override convenience init(frame: CGRect) {
        self.init(customSearchBar: UISearchBar())
        self.frame = frame
    }

    required init?(coder aDecoder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }

    override func layoutSubviews() {
        super.layoutSubviews()
        searchBar.frame = bounds
    }
}

let searchBarWrapper = SearchBarContainerView(customSearchBar: searchBar)
searchBarWrapper.frame = CGRect(x: 0, y: 0, width: view.frame.width, height: 44)
navigationItem.titleView = searchBarWrapper

이렇게 하면 해결! 첫번째 방법이 깔끔하고 정석대로 해결하는것 같은데 제대로 동작하지 않으니 두번째 방법을 사용할 수 밖에 없었습니다. iOS 개발하다 보면 이런식으로 해결해야 하는 경우가 있더라구요.

삽질지수

이번 삽질의 삽질 지수는 1입니다. (삽질지수 범위 1 5 단계) 처음부터 원인을 알고 있었고 해결방법만 찾으면 되는데 인터넷에 있는 방법중에 되는게 있어서 다행이었죠.

이거 때문에 하루가 그냥 사라졌네요 ㅜㅜ 첫번째 방법으로 깔끔하게 해결하려고 계속 삽질 했던게 원인이었어요. 그래도 해결할 수 있어서 다행이었어요. 해결하지 못하면 네비바 아래에 검색바를 위치시켜야되서 내키지 않았거든요.

참고자료

• UISearchBar increases navigation bar height in iOS 11 – Stack Overflow
• Set search bar as a navigation title view – Apple Developer Forums

게시글의 아마존, iTunes 링크들을 통해 구매를 하시면 제휴(Affiliate) 프로그램에 의해 저에게 일정 금액이 적립될 수 있습니다. ^_____^

Swift 컴파일러가 느린건 잘 알려진 사실입니다. 조금이나마 개발속도를 빠르게 하기 위해 여러가지 꼼수들이 공유되고 있죠. 하지만 더 비싼 맥을 사면 다 해결될것 같지 않나요? 여기 그렇지 않다는 정보를 드리려고합니다.

링크드인에서 게시한 The best hardware to build with Swift is not what you might think 글에서는 맥프로, 아이맥, 맥미니, 맥북프로를 이용해 빌드 속도가 얼마나 차이가 나는지 확인한 결과를 공유했습니다.

결과는 충격적이게도… 맥프로가 제일 느립니다!

링크드인에서는 2015년 중반쯤 테스트를 통해 CPU 코어와 스레드 갯수가 빌드 타임에 많은 영향을 미치는것을 보고 모바일 개발자의 빠른 개발을 위해 기존의 4코어 맥북프로 대신 12코어 맥프로를 제공해 2-3배 정도의 속도 향상 효과를 얻었다고 합니다. 12코어 맥프로는 한대에 9백만원!!!(메모리와 그래픽카드 업그레이드까지 했다면 1천 2백만원!)

그러다가 최근 모바일 개발자들이 그 비싼 12코어 맥프로 대신 맥북프로를 사용하고 있는것을 보고 왜 맥프로 안쓰냐고 했더니 맥북프로가 더 빠르다고 했다네요.

2015년의 결과를 뒤로 하고 다시 테스트 해봤더니 충격적이게도 12코어 맥프로는 Swift 빌드 하는데 있어서 맥미니보다도 느린 성능을 발휘하고 있었습니다. (자세한 그래프는 링크드인 블로그를 참고하세요.)

빌드가 빠른 순서대로 나열하면 다음과 같습니다. “4코어 아이맥 27인치” > “4코어 맥북프로” > “2코어 맥미니” > “12코어 맥프로” 🙁

이런 문제가 발생한 이유는 Swift 컴파일러의 버그때문인것으로 보입니다. Compilation gets slower when allowed more concurrent jobs 요 이슈가 해결되면 맥프로도 빠르게 빌드 할 수 있겠네요 ~

게시글의 아마존, iTunes 링크들을 통해 구매를 하시면 제휴(Affiliate) 프로그램에 의해 저에게 일정 금액이 적립될 수 있습니다. ^_____^