초코모찌롤

아이폰 배터리 빨리 닳는 이유 7가지 (+ 바로 해결 방법)

초코모찌롤 — Sun, 12 Apr 2026 14:19:31 +0900

아이폰 배터리 빨리 닳는 이유 7가지 (+ 바로 해결 방법)

최근 들어 아이폰 배터리가 눈에 띄게 빨리 줄어드는 느낌을 받은 적이 있다면, 단순한 기분 탓이 아닐 수 있습니다. 특히 iOS 업데이트 이후나 특정 앱을 설치한 뒤 배터리 소모가 급격히 늘어나는 경우가 많습니다. 이 글에서는 아이폰 배터리가 빨리 닳는 대표적인 원인과, 바로 적용 가능한 해결 방법을 실제 사용 기준으로 정리했습니다.

아이폰 배터리가 빨리 닳는 주요 원인

1. iOS 업데이트 이후 최적화 과정

iOS 업데이트 직후에는 내부적으로 인덱싱, 사진 정리, 백그라운드 작업이 실행되면서 배터리 사용량이 증가할 수 있습니다. 보통 1~3일 정도 지나면 정상화되지만, 그 기간 동안은 평소보다 배터리가 빨리 닳는 것이 자연스러운 현상입니다.

2. 백그라운드 앱 새로고침

사용하지 않는 앱이 백그라운드에서 계속 데이터를 가져오면 배터리가 소모됩니다. 특히 SNS, 뉴스, 쇼핑 앱은 지속적으로 서버와 통신하기 때문에 영향을 크게 줍니다.

3. 위치 서비스 과다 사용

지도, 배달, 날씨 앱 등이 위치 정보를 계속 요청하면 GPS가 활성화되면서 배터리 소모가 증가합니다. 필요하지 않은 앱까지 위치 권한이 허용된 경우가 많습니다.

4. 화면 밝기 및 디스플레이 설정

밝기가 높을수록 배터리 소모는 증가합니다. 특히 자동 밝기가 꺼져 있는 경우 실내에서도 높은 밝기로 유지되어 불필요한 전력 소비가 발생합니다.

5. 배터리 성능 저하

배터리는 소모품이기 때문에 일정 시간이 지나면 성능이 떨어집니다. 설정에서 배터리 성능 상태를 확인했을 때 최대 용량이 80% 이하라면 체감 속도가 크게 달라질 수 있습니다.

6. 특정 앱의 비정상적인 사용

일부 앱은 오류나 업데이트 문제로 배터리를 과도하게 사용하는 경우가 있습니다. 특히 영상 스트리밍, 게임, SNS 앱에서 자주 발생합니다.

7. 네트워크 환경 문제

신호가 약한 지역에서는 아이폰이 계속해서 신호를 잡으려고 하면서 배터리를 더 많이 사용합니다. LTE나 5G 환경이 불안정할수록 소모가 커집니다.

아이폰 배터리 빨리 닳을 때 해결 방법

1. 백그라운드 앱 새로고침 끄기

설정 → 일반 → 백그라운드 앱 새로고침에서 필요 없는 앱을 비활성화하면 즉각적인 효과를 볼 수 있습니다.

2. 위치 서비스 최적화

설정 → 개인정보 보호 → 위치 서비스에서 사용하지 않는 앱은 “사용 안 함” 또는 “앱 사용 중에만 허용”으로 변경하는 것이 좋습니다.

3. 화면 밝기 자동 설정 활성화

설정 → 손쉬운 사용 → 디스플레이 및 텍스트 크기에서 자동 밝기를 켜면 상황에 맞게 밝기가 조절되어 배터리를 절약할 수 있습니다.

4. 배터리 사용량 확인하기

설정 → 배터리에서 어떤 앱이 배터리를 많이 사용하는지 확인할 수 있습니다. 특정 앱이 비정상적으로 높다면 업데이트하거나 삭제를 고려해볼 수 있습니다.

5. 저전력 모드 활용

저전력 모드를 켜면 백그라운드 작업, 시각 효과 등이 제한되면서 배터리 사용량이 줄어듭니다. 급할 때 매우 효과적인 방법입니다.

6. 네트워크 설정 재설정

설정 → 일반 → 전송 또는 iPhone 재설정 → 네트워크 설정 재설정을 통해 불필요한 연결 문제를 해결할 수 있습니다.

7. 필요 없는 위젯 제거

홈 화면에 추가된 위젯도 지속적으로 데이터를 업데이트하기 때문에 배터리에 영향을 줄 수 있습니다.

절대 하면 안 되는 설정

항상 모든 앱에 위치 서비스 허용
밝기 100% 고정 사용
충전하면서 고사양 게임 실행
불필요한 앱을 계속 백그라운드 실행

배터리 문제 체크리스트

iOS 업데이트 후 2~3일 지났는가
배터리 성능 상태가 80% 이상인가
특정 앱이 과도하게 배터리를 사용하지 않는가
위치 서비스가 과도하게 켜져 있지 않은가
백그라운드 앱 새로고침이 필요한 앱만 켜져 있는가

마무리

아이폰 배터리가 빨리 닳는 문제는 대부분 설정이나 사용 습관에서 비롯됩니다. 위에서 정리한 방법을 하나씩 적용해보면 체감할 수 있을 정도로 배터리 사용 시간이 늘어나는 것을 확인할 수 있습니다.

SwiftUI 전체 앱 구조 설계 (Router + Tab + Navigation 통합 아키텍처)

초코모찌롤 — Fri, 3 Apr 2026 10:10:05 +0900

SwiftUI 전체 앱 구조 설계 (Router + Tab + Navigation 통합 아키텍처)

SwiftUI를 어느 정도 사용하다 보면 단순 View 구현을 넘어 앱 전체 구조 설계가 필요해집니다.

특히 아래 요소들이 동시에 등장하면 구조가 복잡해집니다.

NavigationStack
TabView
딥링크 / 푸시
WebView 연동

이 글에서는 이 모든 것을 통합하는 실무 아키텍처를 정리합니다.

1. 핵심 개념

앱 구조의 핵심은 단 하나입니다.

모든 화면 이동을 "데이터(Route)"로 관리한다

2. Route 정의


enum Route: Hashable {
    case home
    case detail(id: Int)
    case web(url: URL)
    case setting
}

모든 화면을 하나의 enum으로 관리

3. Router 설계


class Router: ObservableObject {
    @Published var path: [Route] = []
    @Published var selectedTab: Tab = .home

    func push(_ route: Route) {
        path.append(route)
    }

    func pop() {
        path.removeLast()
    }

    func popToRoot() {
        path.removeAll()
    }

    func switchTab(_ tab: Tab) {
        selectedTab = tab
        path.removeAll()
    }
}

4. Tab 정의


enum Tab {
    case home
    case profile
    case setting
}

탭도 상태로 관리

5. Root 구조


struct RootView: View {
    @StateObject private var router = Router()

    var body: some View {
        NavigationStack(path: $router.path) {

            TabView(selection: $router.selectedTab) {

                HomeView()
                    .tag(Tab.home)

                ProfileView()
                    .tag(Tab.profile)

                SettingView()
                    .tag(Tab.setting)
            }

            .navigationDestination(for: Route.self) { route in
                switch route {
                case .detail(let id):
                    DetailView(id: id)
                case .web(let url):
                    WebView(url: url)
                default:
                    EmptyView()
                }
            }
        }
    }
}

Navigation + Tab 통합

6. 딥링크 / 푸시 처리


func handleDeepLink(_ url: URL) {
    if url.path.contains("detail") {
        router.push(.detail(id: 1))
    }
}


func handlePush(_ data: [String: Any]) {
    if let urlString = data["url"] as? String,
       let url = URL(string: urlString) {
        router.push(.web(url: url))
    }
}

외부 이벤트 → Route 변환

7. WebView 연동

Web → App 이동도 동일한 구조를 사용합니다.


router.push(.detail(id: 10))

모든 흐름 통일

8. 구조 흐름 정리

사용자 이벤트 발생
Route 생성
Router.push()
NavigationStack 반영

9. 실무에서 자주 하는 실수

Navigation과 Tab을 따로 관리
View에서 직접 navigation 처리
딥링크 로직 분산

10. 실무 추천 구조

Router 단일화
Route enum 기반 설계
모든 이동을 Router로 통제

11. 결론

SwiftUI 앱 구조의 핵심은 다음입니다.

UI가 아니라 상태로 앱을 설계하라

Navigation → 상태
Tab → 상태
딥링크 → 상태

이 구조를 만들면 복잡한 앱도 안정적으로 유지할 수 있습니다.

다음 글에서는 SwiftUI + TCA 구조 설계 (실무 아키텍처 확장)를 다루면 고급 개발자 수준으로 확장할 수 있습니다.

SwiftUI NavigationBar 커스터마이징 완벽 가이드 (iOS 26 Liquid 제거 포함)

초코모찌롤 — Fri, 3 Apr 2026 10:08:56 +0900

SwiftUI NavigationBar 커스터마이징 완벽 가이드 (iOS 26 Liquid 제거 포함)

SwiftUI NavigationBar는 기본 제공 기능만으로는 실무 요구사항을 만족시키기 어렵습니다.

특히 최근 iOS 26에서는 Liquid 스타일이 적용되면서 디자인 제어가 더욱 까다로워졌습니다.

이 글에서는 NavigationBar를 완전히 제어하는 방법을 정리합니다.

1. 기본 NavigationStack 구조


NavigationStack {
    Text("Hello")
        .navigationTitle("Title")
}

기본 구조는 간단하지만 커스터마이징 한계 존재

2. NavigationBar 숨기기


.navigationBarHidden(true)

또는 (iOS 16+)


.toolbar(.hidden, for: .navigationBar)

커스텀 네비게이션을 만들기 위한 첫 단계

3. iOS 26 Liquid 효과 제거

iOS 26에서는 NavigationBar가 반투명 / Liquid 스타일로 변경되었습니다.

해결 방법 (UIKit Appearance)


let appearance = UINavigationBarAppearance()
appearance.configureWithOpaqueBackground()
appearance.backgroundColor = .white
appearance.shadowColor = .clear

UINavigationBar.appearance().standardAppearance = appearance
UINavigationBar.appearance().scrollEdgeAppearance = appearance

완전히 불투명 스타일로 변경

4. 커스텀 NavigationBar 만들기

실무에서는 NavigationBar를 직접 구현하는 경우가 많습니다.


VStack(spacing: 0) {

    HStack {
        Button(action: {
        }) {
            Image(systemName: "chevron.left")
        }

        Spacer()

        Text("Title")

        Spacer()

        Image(systemName: "bell")
    }
    .padding()
    .background(Color.white)

    Divider()

    contentView
}

완전한 UI 제어 가능

5. SafeArea 대응


.safeAreaInset(edge: .top) {
    CustomNavigationBar()
}

상단 고정 가능

6. 뒤로가기 버튼 커스터마이징


.toolbar {
    ToolbarItem(placement: .navigationBarLeading) {
        Button(action: {
        }) {
            Image(systemName: "chevron.left")
        }
    }
}

기본 버튼 대체 가능

7. 타이틀 정렬 문제

SwiftUI 기본 NavigationTitle은 중앙 정렬입니다.

해결

커스텀 NavigationBar 사용
HStack으로 직접 구성

8. 실무에서 자주 하는 실수

기본 NavigationBar에 억지 커스터마이징
SafeArea 고려 없이 overlay 사용
NavigationStack과 상태 분리 안됨

9. 실무 추천 구조

NavigationStack + Custom NavigationBar
Router 기반 화면 관리
SafeAreaInset으로 위치 제어

10. 결론

NavigationBar의 핵심은 다음입니다.

기본을 버리고 구조를 가져가라

기본 NavigationBar → 제한적
Custom NavigationBar → 완전 제어

특히 iOS 26 이후에는 커스텀 구조가 사실상 필수입니다.

다음 글에서는 SwiftUI 전체 앱 구조 설계 (Router + Tab + Navigation 통합)를 다루면 실무 아키텍처까지 완성됩니다.

SwiftUI TabView 커스터마이징 완벽 가이드 (높이, 디자인, 상태 유지)

초코모찌롤 — Fri, 3 Apr 2026 10:08:05 +0900

SwiftUI TabView 커스터마이징 완벽 가이드 (높이, 디자인, 상태 유지)

SwiftUI에서 TabView는 간단하게 사용할 수 있지만, 실무에서는 거의 반드시 커스터마이징이 필요합니다.

특히 아래 문제를 많이 겪게 됩니다.

TabBar 높이 변경이 안됨
디자인 커스터마이징 어려움
탭 전환 시 상태 초기화

이 글에서는 TabView를 실무에서 사용하는 방식으로 정리합니다.

1. 기본 TabView 구조


TabView {
    Text("Home")
        .tabItem {
            Label("Home", systemImage: "house")
        }

    Text("Profile")
        .tabItem {
            Label("Profile", systemImage: "person")
        }
}

기본은 간단하지만 커스터마이징 한계가 있음

2. Tab 선택 상태 관리


@State private var selectedTab = 0


TabView(selection: $selectedTab) {
    Text("Home")
        .tag(0)

    Text("Profile")
        .tag(1)
}

상태 기반 제어 가능

3. 탭 전환 시 상태 유지

문제:

탭 이동 시 View 초기화

해결 방법

View를 분리
@StateObject 사용


struct HomeView: View {
    @StateObject private var vm = ViewModel()
}

상태 유지 가능

4. TabBar 디자인 커스터마이징

기본 TabView는 제한이 많기 때문에 실무에서는 커스텀 TabBar를 사용합니다.

구조


VStack(spacing: 0) {
    contentView

    HStack {
        Button("Home") { selectedTab = 0 }
        Button("Profile") { selectedTab = 1 }
    }
}

완전한 커스터마이징 가능

5. 높이 변경 방법

기본 TabView는 높이 변경이 어렵습니다.

해결

커스텀 TabBar 사용
safeAreaInset 활용


.safeAreaInset(edge: .bottom) {
    CustomTabBar()
}

6. 가운데 버튼 (FAB) 구현


ZStack {
    TabView { ... }

    VStack {
        Spacer()
        Button("+") {
        }
        .offset(y: -20)
    }
}

Floating Button 구현

7. UIKit Appearance 커스터마이징


UITabBar.appearance().backgroundColor = UIColor.white

기본 스타일 변경 가능

8. 실무에서 자주 하는 실수

기본 TabView로 모든 것을 해결하려고 함
상태 관리 없이 View 생성
Navigation과 혼합 구조 꼬임

9. 실무 추천 구조

NavigationStack + TabView 분리
Router 기반 관리
Custom TabBar 사용

10. 결론

SwiftUI TabView의 핵심은 다음입니다.

기본은 간단, 실무는 커스텀

상태 관리 필수
디자인은 커스텀
구조는 분리

이 구조를 이해하면 복잡한 탭 UI도 안정적으로 구현할 수 있습니다.

다음 글에서는 SwiftUI NavigationBar 커스터마이징 (iOS 26 대응 포함)을 다루면 UI 구조가 완전히 완성됩니다.

SwiftUI 키보드 대응 완벽 가이드 (입력창 가림, 자동 스크롤 문제 해결)

초코모찌롤 — Fri, 3 Apr 2026 10:07:21 +0900

SwiftUI 키보드 대응 완벽 가이드 (입력창 가림, 자동 스크롤 문제 해결)

SwiftUI에서 폼이나 채팅 UI를 만들다 보면 반드시 겪는 문제가 있습니다.

키보드 올라오면 입력창 가림
ScrollView가 자동으로 안 올라감
SafeArea랑 충돌

이 글에서는 실무에서 바로 쓰는 키보드 대응 방법을 정리합니다.

1. 왜 키보드에 가려질까?

SwiftUI는 기본적으로 키보드를 고려한 레이아웃 조정을 자동으로 해주지 않습니다.

즉, 키보드가 올라와도 View는 그대로 유지됩니다.

2. 기본 해결: safeAreaInset 활용


.safeAreaInset(edge: .bottom) {
    TextField("입력", text: $text)
        .padding()
        .background(Color.white)
}

키보드 위에 입력창을 고정할 수 있습니다.

3. ScrollView 자동 스크롤

입력 시 하단으로 자동 이동하는 구조입니다.


ScrollViewReader { proxy in
    ScrollView {
        LazyVStack {
            ForEach(messages) { message in
                Text(message.text)
                    .id(message.id)
            }
        }
    }
}

특정 위치로 이동 가능


proxy.scrollTo(messages.last?.id)

4. 키보드 높이 감지

UIKit Notification을 활용합니다.


NotificationCenter.default.addObserver(
    forName: UIResponder.keyboardWillShowNotification,
    object: nil,
    queue: .main
) { notification in
    if let frame = notification.userInfo?[UIResponder.keyboardFrameEndUserInfoKey] as? CGRect {
        keyboardHeight = frame.height
    }
}

직접 offset 조정 가능

5. 입력창 위치 고정 전략


VStack {
    ScrollView { ... }

    TextField("입력", text: $text)
        .padding()
}

단순하지만 많이 깨짐

6. dismiss keyboard


@FocusState private var isFocused: Bool


.isFocused($isFocused)


isFocused = false

키보드 내리기

7. 실무에서 자주 하는 실수

ScrollView + TextField 단순 조합
SafeArea 무시
키보드 높이 직접 계산 안함

8. 실무 추천 구조 (채팅 UI 기준)

ScrollView + LazyVStack
ScrollViewReader로 위치 제어
safeAreaInset으로 입력창 고정
FocusState로 키보드 관리

9. 결론

SwiftUI 키보드 대응 핵심은 다음입니다.

레이아웃을 바꾸지 말고 위치를 제어하라

safeAreaInset → 고정
ScrollViewReader → 이동
FocusState → 제어

이 구조를 이해하면 대부분의 입력 UI 문제를 해결할 수 있습니다.

다음 글에서는 SwiftUI TabView 커스터마이징 (높이, 디자인, 상태 유지)를 다루면 앱 구조 설계까지 완성됩니다.

SwiftUI 애니메이션 실무 가이드 (버벅임 없이 자연스럽게 구현하는 방법)

초코모찌롤 — Fri, 3 Apr 2026 10:05:31 +0900

SwiftUI 애니메이션 실무 가이드 (버벅임 없이 자연스럽게 구현하는 방법)

SwiftUI 애니메이션은 간단해 보이지만, 실제로는 버벅임, 끊김, 의도하지 않은 동작이 자주 발생합니다.

특히 아래 문제는 실무에서 많이 겪게 됩니다.

애니메이션이 안 먹는다
전체 View가 같이 움직인다
스크롤과 함께 끊긴다

이 글에서는 실무에서 바로 적용 가능한 애니메이션 전략을 정리합니다.

1. SwiftUI 애니메이션 기본 구조

SwiftUI 애니메이션은 상태 변화에 따라 자동으로 발생합니다.


withAnimation {
    isExpanded.toggle()
}

상태 변경 → 애니메이션 적용

2. withAnimation vs animation modifier

withAnimation


withAnimation {
    state = true
}

명시적 애니메이션
해당 블록에만 적용

animation modifier


.animation(.easeInOut, value: state)

자동 애니메이션
특정 값 변화에 반응

3. 애니메이션이 안 먹는 이유

대표적인 원인:

State 변화 없음
value 설정 누락
Layout이 변경되지 않음

4. transition (View 등장/사라짐)


if isVisible {
    Text("Hello")
        .transition(.opacity)
}


.withAnimation {
    isVisible.toggle()
}

등장/퇴장 애니메이션

5. matchedGeometryEffect

두 View 사이 자연스러운 이동을 구현합니다.


@Namespace private var namespace


RoundedRectangle(cornerRadius: 10)
    .matchedGeometryEffect(id: "box", in: namespace)

카드 이동, 탭 전환 등에 사용

6. 성능 좋은 애니메이션 패턴

애니메이션 성능은 어떤 속성을 바꾸느냐에 따라 달라집니다.

주의

frame 변경
layout 변화

Layout이 바뀌면 비용 증가

7. 버벅임 해결 방법

View 분리
animation 범위 최소화
LazyStack 사용
Heavy View 제거

8. 실무에서 자주 하는 실수

전체 View에 animation 적용
State 과도 사용
ScrollView와 함께 무거운 애니메이션 사용

9. 실무 추천 구조

애니메이션 대상 View 분리
withAnimation 최소 범위 적용
Layout 변경 최소화

10. 결론

SwiftUI 애니메이션의 핵심은 다음입니다.

상태 변화 + 최소한의 Layout 변경

가벼운 속성 사용
불필요한 재렌더링 제거
명확한 animation 범위 설정

이 원칙만 지키면 자연스럽고 부드러운 애니메이션을 구현할 수 있습니다.

다음 글에서는 SwiftUI 키보드 대응 (입력창 가림, 자동 스크롤 문제 해결)을 다루면 실무 UI 완성도가 더욱 올라갑니다.

SwiftUI 성능 문제 실전 케이스 (List, Navigation, WebView 최적화)

초코모찌롤 — Fri, 3 Apr 2026 10:04:28 +0900

SwiftUI 성능 문제 실전 케이스 (List, Navigation, WebView 최적화)

SwiftUI는 생산성이 높지만, 조금만 구조가 복잡해지면 성능 문제가 바로 드러납니다.

특히 실무에서는 다음 3가지에서 문제가 많이 발생합니다.

List / Scroll 성능
NavigationStack 상태 꼬임
WKWebView 렌더링 문제

이 글에서는 실제로 많이 발생하는 케이스와 해결 방법을 정리합니다.

1. Case 1: List 스크롤 끊김

문제

스크롤 시 버벅임
프레임 드랍

원인

Heavy View 포함
이미지 로딩 과다
불필요한 재렌더링

잘못된 코드


List(items) { item in
    HeavyView(item: item)
}

해결 방법


struct ItemRow: View {
    let item: Item

    var body: some View {
        Text(item.title)
    }
}


List(items) { item in
    ItemRow(item: item)
}

View 분리
이미지 캐싱 사용
필요한 부분만 렌더링

2. Case 2: NavigationStack push 지연

문제

화면 전환 시 딜레이
push 시 끊김

원인

Destination View가 무거움
onAppear에서 API 호출

해결 방법


.navigationDestination(for: Route.self) { route in
    switch route {
    case .detail(let id):
        DetailView(id: id)
            .task {
                await loadData()
            }
    }
}

View 생성 최소화
데이터 로딩 지연 처리

3. Case 3: WebView 로딩 지연

문제

WebView 진입 시 느림
깜빡임 발생

원인

매번 새 WKWebView 생성
쿠키 재설정

해결 방법


class WebViewStore: ObservableObject {
    let webView = WKWebView()
}


@StateObject private var store = WebViewStore()

WebView 재사용
쿠키 한 번만 설정

4. Case 4: body 과도 호출

문제

View가 계속 다시 그려짐

원인

State 범위 과다
불필요한 ObservableObject

해결 방법

State 최소화
View 분리
EquatableView 활용

5. Case 5: ScrollView 메모리 증가

문제

메모리 계속 증가

원인

LazyStack 미사용

해결


ScrollView {
    LazyVStack {
        ForEach(items) { item in
            ItemView(item: item)
        }
    }
}

6. 성능 최적화 핵심 정리

문제	해결
List 렉	View 분리
Navigation 지연	lazy 로딩
WebView 느림	재사용
body 호출 과다	State 분리
메모리 증가	LazyStack

7. 실무 체크리스트

LazyStack 사용 여부
State 범위 최소화
WebView 재사용
이미지 캐싱
View 분리

8. 결론

SwiftUI 성능의 핵심은 다음입니다.

불필요한 View 생성과 Layout 계산을 줄이는 것

State → 최소화
View → 분리
Layout → 단순화

이 원칙만 지켜도 대부분의 성능 문제를 해결할 수 있습니다.

다음 글에서는 SwiftUI 애니메이션 실무 (버벅임 없이 구현하는 방법)을 다루면 UI 완성도가 크게 올라갑니다.

SwiftUI Navigation + WebView 연동 완벽 가이드 (딥링크, 푸시, 라우팅까지)

초코모찌롤 — Fri, 3 Apr 2026 10:03:17 +0900

SwiftUI Navigation + WebView 연동 완벽 가이드 (딥링크, 푸시, 라우팅까지)

실무에서 가장 복잡한 구조 중 하나는 Navigation + WebView + 딥링크 조합입니다.

특히 아래 상황에서 문제가 발생합니다.

푸시 클릭 시 특정 WebView 화면 이동
웹에서 특정 앱 화면으로 이동
NavigationStack과 WebView 상태 충돌

이 글에서는 이 구조를 안정적으로 구현하는 방법을 정리합니다.

1. 전체 구조 이해

핵심 구조는 다음과 같습니다.

Router (Navigation 관리)
WebView (웹 화면)
DeepLink Handler

모든 이동은 Router를 통해 처리

2. Route 정의


enum Route: Hashable {
    case home
    case web(url: URL)
    case detail(id: Int)
}

모든 화면을 하나의 enum으로 관리

3. Router 구현


class Router: ObservableObject {
    @Published var path: [Route] = []

    func push(_ route: Route) {
        path.append(route)
    }

    func pop() {
        path.removeLast()
    }

    func reset(_ route: Route) {
        path = [route]
    }
}

Navigation의 단일 진입점

4. NavigationStack 연결


NavigationStack(path: $router.path) {
    HomeView()
        .navigationDestination(for: Route.self) { route in
            switch route {
            case .home:
                HomeView()
            case .web(let url):
                WebView(url: url)
            case .detail(let id):
                DetailView(id: id)
            }
        }
}

5. 푸시 알림 → WebView 이동

푸시 데이터 예시:


{
    "type": "web",
    "url": "https://example.com"
}

처리 코드:


func handlePush(data: [String: Any]) {
    if let urlString = data["url"] as? String,
       let url = URL(string: urlString) {
        router.push(.web(url: url))
    }
}

앱 어디서든 동일한 방식으로 처리

6. 딥링크 처리


func handleDeepLink(url: URL) {
    if url.path.contains("detail") {
        router.push(.detail(id: 1))
    }
}

URL → Route 변환

7. Web → App 이동 (JS 브릿지)

웹에서 메시지 전달:


window.webkit.messageHandlers.callback.postMessage({
    type: "detail",
    id: 10
});

앱에서 처리:


func userContentController(_ userContentController: WKUserContentController,
                           didReceive message: WKScriptMessage) {

    if let data = message.body as? [String: Any],
       let type = data["type"] as? String {

        if type == "detail" {
            router.push(.detail(id: 10))
        }
    }
}

Web → Native 라우팅 연결

8. 상태 충돌 방지

자주 발생하는 문제:

중복 push
NavigationStack 꼬임
WebView reload 문제

해결 전략

Route 중복 체크
Router 단일화
WebView 상태 분리

9. 실무 추천 구조

모든 이동 → Router
WebView는 화면 역할만 수행
딥링크 / 푸시 → Route 변환 후 처리

10. 전체 흐름 정리

푸시 / 딥링크 수신
Route 변환
Router.push()
NavigationStack 반영

11. 결론

Navigation + WebView의 핵심은 다음입니다.

모든 이동을 "데이터(Route)"로 통제한다

푸시 → Route
딥링크 → Route
웹 이벤트 → Route

이 구조를 만들면 복잡한 앱에서도 안정적인 네비게이션이 가능합니다.

다음 글에서는 SwiftUI 성능 문제 실전 케이스 (List, Navigation, WebView)를 다루면 전체 구조가 완성됩니다.

SwiftUI WKWebView 완전 정리 (쿠키, 로그인 유지, JS 통신까지)

초코모찌롤 — Fri, 3 Apr 2026 10:01:52 +0900

SwiftUI WKWebView 완전 정리 (쿠키, 로그인 유지, JS 통신까지)

SwiftUI에서 WebView를 붙이는 순간 난이도가 급격히 올라갑니다.

특히 아래 문제는 거의 반드시 겪게 됩니다.

쿠키가 안 붙음
로그인이 유지되지 않음
웹 ↔ 앱 통신이 안됨

이 글에서는 WKWebView를 SwiftUI에서 제대로 사용하는 방법을 실무 기준으로 정리합니다.

1. SwiftUI에서 WKWebView 사용하는 기본 구조

SwiftUI는 UIKit을 직접 사용할 수 없기 때문에 UIViewRepresentable을 사용해야 합니다.


import SwiftUI
import WebKit

struct WebView: UIViewRepresentable {

    let url: URL

    func makeUIView(context: Context) -> WKWebView {
        return WKWebView()
    }

    func updateUIView(_ webView: WKWebView, context: Context) {
        let request = URLRequest(url: url)
        webView.load(request)
    }
}

기본 구조는 간단하지만 실무에서는 이것만으로 부족합니다.

2. 쿠키가 안 붙는 이유

WKWebView는 앱의 쿠키 저장소와 분리되어 있습니다.

URLSession → HTTPCookieStorage
WKWebView → WKHTTPCookieStore

서로 다른 공간을 사용합니다.

3. 쿠키 동기화 방법


func setCookie() {
    let cookie = HTTPCookie(properties: [
        .domain: ".example.com",
        .path: "/",
        .name: "token",
        .value: "1234",
        .secure: "TRUE"
    ])!

    let store = WKWebsiteDataStore.default().httpCookieStore
    store.setCookie(cookie)
}

반드시 WebView 로드 전에 설정해야 합니다.

4. 로그인 유지 전략

실무에서는 다음 방식으로 처리합니다.

앱 로그인 → 토큰 저장
WebView 진입 시 쿠키 주입
웹에서 세션 유지

핵심은 WebView 생성 전에 쿠키 세팅

5. WKWebView 설정 (중요)


let config = WKWebViewConfiguration()
config.websiteDataStore = .default()
let webView = WKWebView(frame: .zero, configuration: config)

데이터 저장소 설정이 중요합니다.

6. JavaScript ↔ Native 통신

JS → Native


config.userContentController.add(context.coordinator, name: "callback")


func userContentController(_ userContentController: WKUserContentController,
                           didReceive message: WKScriptMessage) {
    print(message.body)
}

Native → JS


webView.evaluateJavaScript("alert('Hello')")

Web ↔ App 연동의 핵심

7. Coordinator 활용


class Coordinator: NSObject, WKScriptMessageHandler {
    func userContentController(_ userContentController: WKUserContentController,
                               didReceive message: WKScriptMessage) {
        print(message.body)
    }
}


func makeCoordinator() -> Coordinator {
    Coordinator()
}

delegate 처리를 위해 필요합니다.

8. WKUserScript (초기 스크립트 주입)


let script = WKUserScript(
    source: "document.body.style.background = 'red';",
    injectionTime: .atDocumentStart,
    forMainFrameOnly: true
)

옵션:

.atDocumentStart
.atDocumentEnd

로그인, 쿠키, JS 초기화에 활용

9. 실무에서 자주 하는 실수

쿠키 설정 후 WebView 생성
updateUIView에서 계속 load 호출
JS handler 중복 등록

10. 실무 추천 구조

WebView 생성 전에 쿠키 세팅
Coordinator로 이벤트 처리
Router와 연결해서 네비게이션 관리

11. 결론

SwiftUI에서 WebView의 핵심은 다음입니다.

쿠키는 별도 저장소
생성 전에 설정해야 함
JS 브릿지로 연동

이 구조를 이해하면 대부분의 WebView 문제를 해결할 수 있습니다.

다음 글에서는 SwiftUI Navigation + WebView 연동 (딥링크, 푸시 포함)을 다루면 실무 구조가 완성됩니다.

SwiftUI SafeArea 완벽 이해 (layout 깨짐, NavigationBar 겹침 해결)

초코모찌롤 — Fri, 3 Apr 2026 10:00:41 +0900

SwiftUI SafeArea 완벽 이해 (layout 깨짐, NavigationBar 겹침 해결)

SwiftUI에서 UI를 만들다 보면 반드시 마주치는 문제가 있습니다.

NavigationBar랑 겹침
상단/하단 여백 이상
전체 화면인데 일부만 채워짐

이 문제의 핵심 원인은 SafeArea입니다.

이 글에서는 SafeArea의 개념부터 실무 해결 방법까지 정리합니다.

1. SafeArea란 무엇인가?

SafeArea는 시스템 UI를 침범하지 않는 안전한 영역입니다.

상단: 상태바, 노치
하단: 홈 인디케이터

SwiftUI는 기본적으로 SafeArea 안에서만 View를 배치합니다.

2. 왜 layout이 깨질까?

문제는 다음 상황에서 발생합니다.

전체 화면을 쓰고 싶은 경우
NavigationStack과 함께 사용하는 경우
background를 설정할 때

3. ignoresSafeArea

SafeArea를 무시하고 전체 화면을 사용합니다.


Color.blue
    .ignoresSafeArea()

화면 전체를 덮음

4. 특정 방향만 무시하기


.ignoresSafeArea(edges: .top)

옵션:

.top
.bottom
.horizontal
.all

5. NavigationBar와 겹치는 문제

가장 많이 발생하는 문제입니다.


NavigationStack {
    Color.red
        .ignoresSafeArea()
}

NavigationBar 아래로 침범

해결 방법


.safeAreaInset(edge: .top) {
    Color.clear.frame(height: 0)
}

또는 NavigationBar 숨김 처리

6. safeAreaInset 활용

SafeArea 안쪽에 UI를 추가할 수 있습니다.


.safeAreaInset(edge: .bottom) {
    Button("확인") {
    }
    .frame(maxWidth: .infinity)
    .padding()
    .background(Color.blue)
}

하단 고정 버튼 구현 가능

7. background가 안 채워지는 문제


VStack {
    Text("Hello")
}
.background(Color.yellow)

SafeArea 밖은 채워지지 않음

해결


.background(Color.yellow.ignoresSafeArea())

8. ScrollView와 SafeArea

ScrollView는 SafeArea를 자동으로 적용합니다.

문제:

상단 여백 이상
content offset 문제

해결


.scrollContentBackground(.hidden)

9. 실무에서 자주 하는 실수

ignoresSafeArea 남용
NavigationStack과 함께 무조건 전체화면 사용
background 위치 잘못 설정

10. 실무 추천 전략

기본은 SafeArea 유지
필요한 부분만 선택적으로 무시
safeAreaInset 적극 활용

11. 결론

SafeArea의 핵심은 다음입니다.

기본은 보호, 필요할 때만 해제

전체화면 → ignoresSafeArea
부분 제어 → edges 옵션
추가 UI → safeAreaInset

이 구조를 이해하면 대부분의 layout 문제를 해결할 수 있습니다.

다음 글에서는 SwiftUI WebView (WKWebView) 연동 및 쿠키 처리를 다루면 실무 활용도가 크게 올라갑니다.