iOS 웹뷰 상단 노치 대응하기

 

---

 

iPhone X 이후 출시된 기기들은 모두 노치(Notch) 영역을 가지고 있다.
이 영역은 상태바(Status Bar)와 센서 하우징 때문에 화면의 안전 표시 영역(SafeArea)이 달라졌음을 의미한다.

앱을 웹뷰 기반으로 구성했다면,
이 차이를 명확히 처리하지 않으면 웹 콘텐츠가 노치에 가려지거나 상단이 잘리는 문제가 발생할 수 있다.

이번 글에서는 WKWebView 기반 앱에서 상단 노치 안전영역을 올바르게 처리하는 방법을 정리하려고 한다.

 

---

 
 

문제 상황 - 웹뷰를 전체 화면으로 채우기

webView.snp.makeConstraints {
    $0.edges.equalToSuperview()
}

이렇게 하면 iPhone 15 Pro와 같은 기기에서 웹 콘텐츠가 노치 영역 밑으로 들어가 버린다.
결과적으로 HTML의 <header>요소가 잘리거나, 상단 버튼이 눌리지 않는 문제가 생긴다.
 
 

올바른 SafeArea 적용

가장 간단한 방법은 SafeAreaLayoutGuide를 기준으로 제약을 설정하는 것이다.

webView.snp.makeConstraints {
    $0.top.equalTo(view.safeAreaLayoutGuide)
    $0.horizontalEdges.equalToSuperview()
    $0.bottom.equalToSuperview()
}

이렇게 하면 상단 노치, 하단 홈 인디케이터를 모두 피해서 웹뷰가 안전 영역 안에 배치된다.
하지만, 웹앱이 자체적으로 safeArea를 처리하는 구조라면,
이 설정은 오히려 이중 여백을 만들어 레이아웃이 어색해질 수 있다.
 
 

웹앱이 SafeArea를 직접 처리하는 경우

요즘 SPA(React, Next.js 기반) 구조의 웹앱들은 CSS 환경에서 이미 safeArea 대응이 되어있다.
예를 들어, 웹 CSS에 다음과 같이 정의되어 있다면!

padding-top: env(safe-area-inset-top);
padding-bottom: env(safe-area-inset-bottom);

이 경우 네이티브 쪽에서 굳이 safeArea를 고려할 필요가 없다.
오히려 safeAreaLayoutGuide를 적용하면 상단 여백이 두 배로 증가하게 된다.
따라서 이런 경우에는 아래와 같이 전체 화면을 웹뷰가 덮도록 구성하는게 맞다.

webView.snp.makeConstraints {
    $0.edges.equalToSuperview()
}

즉, 웹앱이 SafeArea를 담당할 때는 네이티브가 간섭하지 않는다는 원칙을 지켜야 한다.
 
+ 웹에서 하는 iOS 노치 대응 가이드
1) 필수 전제: viewport-fit=cover

iOS Safari에서 노치∙홈 인디케이터까지 전체 화면을 웹이 차지하려면 뷰포트 선언이 필요하다.

<meta name="viewport"
      content="width=device-width, initial-scale=1, viewport-fit=cover" />

이 설정이 없으면 env(safe-area-inset-*)가 기대한대로 동작하지 않거나,
상단/하단이 브라우저 UI에 의해 잘릴 수 있다.
WKWebView에서도 동일하게 넣어두는 편이 안전하다.


2) CSS 기본 패턴 (권장)

기본적으로 상∙하 안전영역을 패딩으로 흡수한다.
노치 없는 기기는 0이 반환되므로 동일 CSS를 공용으로 써도 무방하다.

/* iOS 11.x 구버전(WebKit 프리픽스)까지 호환 */
:root {
  /* 선택: 커스텀 변수로 재노출해두면 재사용이 편함 */
  --sat: env(safe-area-inset-top);
  --sab: env(safe-area-inset-bottom);
  --sal: env(safe-area-inset-left);
  --sar: env(safe-area-inset-right);
}

/* 페이지 전체를 감싸는 최상위 래퍼(또는 body)에 적용 */
.safe-area {
  padding-top: env(safe-area-inset-top);
  padding-right: env(safe-area-inset-right);
  padding-bottom: env(safe-area-inset-bottom);
  padding-left: env(safe-area-inset-left);

  /* 구형 iOS 대비용(있어도 무해) */
  padding-top: constant(safe-area-inset-top);
  padding-right: constant(safe-area-inset-right);
  padding-bottom: constant(safe-area-inset-bottom);
  padding-left: constant(safe-area-inset-left);
}

어디에 붙여야하느냐?

웹이 전체화면을 직접 담당하는 구조라면,
body 또는 최상위 레이아웃 컴포넌트(ex. #root, <App/>래퍼)에 .safe-area를 부여한다.

상단 고정 바(AppBar)∙하단 탭바가 웹 내부에 있다면,
해당 컴포넌트에만 선택적으로 padding-top/bottom을 적용해도 된다.
(ex. .app-bar { padding-top: var(--sat); }, .tabbar {  padding-bottom: var(--sab); }



3) 상단/하단 고정 요소(position: fixed)처리

노치∙홈 인디케이터와 겹치지 않도록 고정 바에 inset을 더한다.

.app-bar {
  position: sticky;
  top: 0;
  padding-top: var(--sat);
  height: calc(56px + var(--sat));
}

.bottom-tab {
  position: sticky;
  bottom: 0;
  padding-bottom: var(--sab);
  height: calc(64px + var(--sab));
}

fixed를 써야 한다면?

.app-bar {
  position: fixed; top: 0; left: 0; right: 0;
  padding-top: var(--sat);
  height: calc(56px + var(--sat));
}

 
4) 배경색∙스크롤 바운스 대비

iOS에서 오버스크롤(바운스) 시 안전영역 밖까지 배경이 비쳐보일 수 있다.
body와 루트 컨테이너에 동일한 배경색을 지정해 틈이 보이지 않게 해야한다.

html, body, #root {
  background: #fff;      /* 앱 배경색과 동일 */
  min-height: 100%;
}

 
5) vh 이슈: 모바일 Safari 툴바 높이 변화
iOS Safari는 상∙하단 툴바 노출에 따라 100vh가 흔들릴 수 있다.
iOS 15+부터는 svh/dvh/lvh 단위를 활용하면 안정적이다.

/* 권장: 100dvh 또는 100svh */
.main-full {
  min-height: 100dvh; /* 동적 뷰포트, 툴바 변화에 반응 */
}

/* 구버전 폴백 */
@supports not (height: 100dvh) {
  .main-full { min-height: 100vh; }
}

 

6)  React/SPA 레이아웃 예시

웹이 SafeArea를 책임지는 케이스(네이티브에서는 전체화면으로만)

// AppLayout.tsx
export function AppLayout({ children }: { children: React.ReactNode }) {
  return (
    <div className="safe-area app-shell">
      <header className="app-bar">
        {/* 좌/우 노치 고려 필요 시 padding-left/right 도 가능 */}
        <h1>Title</h1>
      </header>

      <main className="content">
        {children}
      </main>

      <nav className="bottom-tab">
        {/* 탭 아이템 */}
      </nav>
    </div>
  );
}

.app-shell {
  min-height: 100dvh;
  display: grid;
  grid-template-rows: auto 1fr auto;
}

.app-bar {
  padding-top: var(--sat);
  height: calc(56px + var(--sat));
  display: flex; align-items: center;
  border-bottom: 1px solid #eee;
  background: #fff;
}

.bottom-tab {
  padding-bottom: var(--sab);
  height: calc(64px + var(--sab));
  border-top: 1px solid #eee;
  background: #fff;
}

.content {
  /* 좌우 노치 대응 필요하다면 아래 주석 해제
  padding-left: var(--sal);
  padding-right: var(--sar);
  */
  overflow: auto;
}

7) 동영상∙가로모드 특정 화면
전체화면(Fullscreen) 비디오는 브라우저/OS가 별도 레이어로 처리하므로 대개 추가로 SafeArea 보정이 불필요하다.
가로모드로 전환되는 전용 화면이라면, 좌/우 inset(--sal, --sar)까지 고려해 조작 버튼이 노치와 겹치지 않게 한다.

@media (orientation: landscape) {
  .player-controls {
    padding-left: var(--sal);
    padding-right: var(--sar);
  }
}

 

상단 네이티브 UI가 있는 경우

상단에 백버튼, 제목바, 탭바 등의 네이티브 UI가 존재한다면,
해당 UI를 기준으로 웹뷰의 top을 맞춰야 한다.

webView.snp.makeConstraints {
    $0.top.equalTo(backButtonSuperView.snp.bottom)
    $0.horizontalEdges.equalToSuperview()
    $0.bottom.equalToSuperview()
}

이렇게 하면 노치 영역은 backButtonSuperView가 차지하고,
웹뷰는 그 아래부터 콘텐츠를 표시하게 된다.
 
 

안전영역 높이 직접 계산하기 (특수 케이스)

기기별 상단 안전영역 높이를 직접 계산해야 하는 경우도 있다.
예를 들어, 백버튼 영역을 safeArea 높이 + 50pt로 맞춰야 한다면 아래와 같이 구현할 수 있다.

let window = UIApplication.shared.windows.first
let topInset = window?.safeAreaInsets.top ?? 0
let backBarHeight = topInset + 50

이 값을 제약 조건에 반영하면, 기기별 노치 차이에 따라 유연하게 대응할 수 있다.
 
 

---

 
핵심은 하나다.
'웹뷰의 safeArea처리는 "웹이 하느냐, 앱이 하느냐"를 먼저 결정하는 것.'
이 원칙만 명확히 해두면, iPhone X 이후 모든 기기에서 안정적인 레이아웃을 유지할 수 있다.
 

---