Here’s some checklist for you to fix this situation.

Giving external agentic coding tools access to Xcode | Apple Developer Documentation

Minimum Requirements

Before you start, Here’s requirements to use Xcode MCP (which is same with requirements of Xcode Agentic Coding)

1. Apple Silicon (Not Intel Mac 😢)
2. Xcode 26.3
3. MacOS 26

1. Settings in Xcode

This is setting that enables Xcode mcp. The toggle switch should be on.

⭐ 2.️ Check default Xcode version

If you installed Xcode from Xcode Releases or Apple Developer, your default Xcode version might be older one.

Default Xcode version should be 26.3 or above
Use xcode-select command to change default setting to your latest Xcode

sudo xcode-select -s <path/to/xcode>

3. Allow Claude & Codex to access Xcode

Every time Claude & Codex launches, Claude and Codex should get permission from Xcode.

Make sure press “Allow” from this popup.
Accidentally dismissed this? Just reopen Claude or Codex.

4. Make sure Xcode is running

Xcode should be running to use this MCP.
But You don’t have to open project’ s window alive. Just not quitting (⌘ + q) is enough.

⭐ 5. Check current directory

If you run Xcode MCP setting command on terminal, it’s available only at current directory.

You should run claude mcp add or codex mcp add if you are using xcode mcp on that directory for the first time.

WWDC25가 반년정도 지났고, 슬슬 Xcode 26으로 프로젝트를 마이그레이션 마쳐야 할 시기가 다가오고 있습니다. (항상 그렇듯, 이번에도 4월까지 마쳐야 합니다.)

Submitting - App Store - Apple Developer

신규 SDK 대응은 필요하지만, WWDC 영상들을 여럿 보기에는 시간이 좀 걸리죠

새로운 변경사항에 대응하기 위해 개인적으로 정리한 내용과, Xcode 26 SDK로 마이그레이션 하면서 신경썻던 부분에 대해 공유하려고 합니다.

늦게라도 마이그레이션을 시작하시는 분들께 도움이 되었으면 좋겠네요 😀

‼️ UIkit 베이스의 iOS 프로젝트를 운영하고 있어, SwiftUI와 타 OS에 특화된 내용은 생략되어 있습니다. 양해 부탁드립니다 🙇

1. 바로 확인해야 할 부분

1.1. Liquid Glass

WWDC25 — 새로운 디자인으로 UIKit 앱 빌드하기

이번 업데이트의 가장 큰 부분은 단연 Liquid Glass 입니다.
Liquid Glass가 적용되면 외형이나 레이아웃이 바뀌거나, 원하지 않는 Liquid Glass 효과가 추가되기 때문에 확인이 필요합니다.

‼️ Navigation Bar, Tab bar, Toggle Switch는 꼭 체크해 보시는 것을 추천드립니다.

UIDesignRequiresCompatibility
info.plist에서 UIDesignRequiresCompatibility를 추가해 Liquid Glass 디자인을 비활성화 할 수 있습니다.

• YES → Liquid glass 기존 디자인으로 빌드
• NO → Liquid glass 디자인으로 빌드

‼️ 해당 옵션은 임시로 지원되는 기능이기 때문에, Liquid Glass 활성화 상태에서도 문제가 없도록 조치가 필요합니다.

되도록이면 iOS 27이 출시되기 전에 하는게 안전하겠죠?

참고 자료:

• UIDesignRequiresCompatibility | Apple Developer Documentation
• How to Disable Liquid Glass When Building for iOS 26
• How to Temporarily Disable the New Liquid Glass UI in Xcode 26

2. Swift Explicit Module

Xcode 26.2에서는 지난 WWDC24에서 소개된 Explicit Modules 기능이 기본으로 활성화 되게 변경되었습니다.

Explicit Modules 기능이 활성화되면, 기존에 암시적으로 프레임워크를 참조하는 모듈에서 빌드 에러가 발생할 수 있습니다.
(제 경우에는, 암시적 참조중인 프레임워크들에 대해 ‘Unable to find module dependency…’ 라는 에러가 발생되었습니다.)

아래 링크를 참조하셔서 수정하실 수 있습니다만, 장기적으로는 모듈 의존성 개선을 고려해 봐야겠습니다.

1. 후이수님 블로그 포스트 — [Xcode26] Unable to find module dependency 빌드 에러 해결
2. Xcode 26 Release Notes

1.3. Accent

Liquid Glass와 함께 새로운 강조 모드가 추가되면서, 강조 모드에서 위젯이 어떻게 보이는지 확인할 필요가 있습니다.

제 포스트에 사진과 함께 정리되어 있으니, 확인해 보세요

WWDC25 — 위젯의 새로운 기능

2. 추후 검토해 봐야 할 부분

2.1. UIScene으로의 변화

WWDC25 — UIKit의 새로운 기능

많은 분들이 UIApplication를 기반으로 프로젝트가 구성되어 계실텐데요 애플이 UIScene 라이프사이클을 사용하도록 변경을 예고했습니다.

• UIApplicaiton 중심 API deprecated 예정
  (UIWindow 용 init(windowScene:) 생성자만 남을 것)
• iOS 26이후 릴리즈에서, 최신 SDK로 구축된 UIKit 앱은 전부 UIScene 라이프사이클을 사용해야만 실행 가능

2.2. Swift 6 vs. Swift 6.2

Swift 6를 도입하면 수많은 컴파일 에러를 마주하게 됩니다. Actor를 명시해주느라 너무 많은 작업이 필요했죠.

Swift 6.2 부터는 Actor가 명시적으로 지정되어 있지 않으면, 암시적으로 @MainActor로 간주하도록 바뀌었습니다.

아직 Swift 5 버전을 사용중이시라면, Swift 6이 아닌 Swift 6.2로 마이그레이션 하는 것을 고려해볼 만 할 것 같네요.

3. 번외: Xcode 추가 기능

WWDC25 — Xcode 26의 새로운 기능

Xcode에 Intelligence도입과 더불어, 쉽게 사용해 볼 수 있는 기능들이 추가되었습니다.디버그 관련 기능도 대폭 개선되었네요.

개인적으로는 Multiple word search와 #Playground를 요긴하게 쓸 것 같네요

Xcode 26의 새로운 기능 - WWDC25 - 비디오 - Apple Developer

Optimizations

• 용량 24% 감소
• 타이핑 지연 시간 50% 개선
• 워크스페이스 로딩 시간 40% 개선

Workspace and editing

Intuitive editor tabs

• 시작 페이지 (검색창, 최근 연 파일)
• ⭐️ 상단 탭 고정 기능

⭐️ Multiple word search

단어가 여러 줄에 나뉘어 있어도 검색하는 기능

Coding by voice

• 입코딩 가능
• 접근성 기능에 더 가깝고, 신기하지만 실제로 사용할 일을 없을 것 같네요.

⭐️ #Playground

• 빌드 안해보고도 코드 실행, 결과 확인해 볼 수 있는 기능 (Playground 우측 탭 기능)
• breakpoint 찍어서 po 명령어 사용하는것과 비슷하게 사용 가능

Icon Composer

OS, 테마별 아이콘 생성 기능

String Catalogs

• 타입 안정성 추가
• 온디바이스 모델로 자동 주석

⭐️ Intelligence

• gpt에 직접 물어보는 기본 기능
• 프로젝트에 연결되어 있기 때문에, 기존 코드 분석 & 수정까지 가능
• 프로젝트 맥락에 맞춰 답변할지에 관한 기능 on/off
• gpt가 변경한 히스토리 백업 → 특정 시점으로 롤백, 비교
• Error 발생시 자동 솔루션 제공

• 원하는 모델 임포트 가능
• 로컬 모델도 임포트 가능

Debugging and performance

• Swift Concurrency 디버깅 개선
• Task의 ID 조회 가능
• Task, TaskGroups, Actor 정보 표시

• 비공개 리소스 접근(i.e. 카메라) 설명 없이 오류가 발생하는 경우
• 이제는 에러에 자세한 설명, 문서까지 제공

Instruments

Processor Trace

• 기존에는 주기적 샘플링 (비교적 정확도 떨어짐) → 측정 방법 변경으로 거의 모든 부분을 캡쳐할 수 있음
• Xcode 16.3+
• iPhone 16 or M4

CPU Counters

• CPU 성능 최적화 도구
• 병목 체크나, 더 자세한 CPU 사용량 체크

SwiftUI Percormance

• 이번 SwiftUI 업데이트로 성능 상당히 개선됨
• SwiftUI 전용 Instruments 지원
• 뷰 업데이트 시점 같은 정보 제공, 그래프화까지

Power Profiler

• 전력 사용량 체크

Trending Insights

• Xcode 16에서 지원되었던 기능 개선

Metrics

• 배터리 사용량, Disk Write, Launch Time, Memory 등의 지표 체크
• 비슷한 앱들의 수치 제공

Building

Explicit Modules for Swift

Demystify explicitly built modules - WWDC24 - Videos - Apple Developer

• 빌드 파이프라인 분리됨
• 모듈 공유로 빌드 효율성 / 신뢰성 강화
• 코드 디버깅 속도 향상 (빌드된 모듈 재사용성 향상)

Swift Build+

• 스위프트 빌드 엔진개선

Enhance Security

• Xcode의 Signing & Capabilities에서 지원하는 정보 보호 기능

Testing

UI Test Recording

• 시뮬레이터에서 유저 인터렉션 녹화
• 녹화된 내용으로 UI 테스트 코드 자동 생성

Test Report

XCTHitchMetric

UI테스트에서 발견되는 끊김 현상 기록

// XCTHitchMetric
func testScrollingAnimationPerformance() throws {
    // Custom performance test measure options.
    let measureOptions = XCTMeasureOptions()
    measureOptions.invocationOptions = .manuallyStop
    // App being tested.
    let app = XCUIApplication()
    // Launch app and get reference to scroll view.
    app.launch()
    let scrollView = app.scrollViews.firstMatch
    measure(metrics: [XCTHitchMetric(application: app)], options: measureOptions) {
        scrollView.swipeUp(velocity: .fast)
        stopMeasuring()
        scrollView.swipeDown(velocity: .fast)
    }
}

위젯의 새로운 기능 - WWDC25 - 비디오 - Apple Developer

Widgets in new places

Accented Rendering mode

• Liquid Glass 스타일 위젯
• 투명 스타일 위젯
• 투명 + tint color가 들어간 스타일 위젯
• 랜더링 방식
  1. 위젯 컨텐츠가 강조 모드로 변경, tint color가 흰색으로 강제 지정
  2. 뒷배경 삭제
  3. 뒷배경을 유리 또는 tint color 효과로 변경
• 특정 위젯의 경우에는, 해당 랜더링에 대응하는 처리 필요

강조 모드 대응

struct MostFrequentBeverageWidgetView: View {
    @Environment(\.widgetRenderingMode) var renderingMode

    var entry: Entry

    var body: some View {
        ZStack {
            if renderingMode == .fullColor {
                Image(entry.beverageImage)
                    .resizable()
                    .aspectRatio(contentMode: .fill)
                LinearGradient(gradient: Gradient(colors: [.clear, .clear, .black.opacity(0.8)]), startPoint: .top, endPoint: .bottom)
            }
            VStack {
                if renderingMode == .accented {
                    Image(entry.beverageImage)
                        .resizable()
                        .widgetAccentedRenderingMode(.desaturated)
                        .aspectRatio(contentMode: .fill)
                }
                BeverageTextView()
            }
        }
    }
}

• ./widgetRenderingMode 환경 변수를 사용해 랜더링 모드 판단
• widgetAccentedRenderingMode modifier에서 강조 모드에서 보여질 방식 설정

widgetAccentedRenderingMode

1. nil

• 기본 tint color가 이미지에 적용
• iOS와 macOS는 tint color가 흰색으로 변경된 후 적용

2. accented

• 이미지가 accentColor로 변경
• iOS와 macOS는 흰색 / WatchOS의 경우는 와치페이스의 색상이 accentColor

3. desaturated

• 이미지 색상 채도가 낮아지는 옵션
• iOS, WatchOS 동일하게 표출

4. accentedDesaturated

• .desaturated + tint color 적용

5. fullColor

• 이미지 풀컬러로 그대로 표출
• WatchOS에서는 와치페이스와 어울리도록 이 옵션이 무시됨

Relevance widgets

• WatchOS에서 필요할 때만 Widget이 Smart Stack에 표출되게 하는 기능

Widget push updates

여러 플랫폼에서 위젯을 최신 상태로 업데이트 하는 방법

TimelineReloadPolicy

일정 간격으로 업데이트 할 때 사용

• WidgetKit이 Widget에 타임라인 요청
• Widget은 TimelineReloadPolicy를 포함한 타임라인 정보 반환
• WidgetKit에서 위젯을 업데이트할 적절한 시간 결정

Widget Center API → reloadAllTimelines

주로 앱 내에서 컨텐츠가 변경되는 경우

• 위젯 컨텐츠가 오래되어 업데이트가 필요함을 WidgetKit에 알림
• WidgetKit이 위젯에 타임라인 요청
• Widget에서 타임라인 갱신

Widget push update

서버나 다른 기기에서 데이터가 변경되는 경우

• APNs를 통해서 WidgetKit에 업데이트 요청을 전달하는 방식
• 여러 기기에 있는 모든 위젯 최신화할 때 사용

Adding push notification support

1. WidgetPushHandler 를 Widget Configuraion에 추가

// pushTokenDidChange 메서드로 서버에 푸시 토큰 & 위젯 정보 전송
struct CaffeineTrackerPushHandler: WidgetPushHandler {
    func pushTokenDidChange(_ pushInfo: WidgetPushInfo, widgets: [WidgetInfo]) {
        // Send push token and subscription info to server
    }
}

// pushHandler 를 사용해 푸시 알림에 대한 지원 등록
struct CaffeineTrackerWidget: Widget {
    var body: some WidgetConfiguration {
        StaticConfiguration(
            kind: Constants.widgetKind,
            provider: Provider()
        ) { entry in
            CaffeineTrackerWidgetView(entry: entry)
        }
        .configurationDisplayName("Caffeine Tracker")
        .pushHandler(CaffeineTrackerPushHandler.self)
    }
}

2. Push Notification entitlement 추가

• 푸시를 사용하는 기능이니, entitlement 작업이 필요합니다.

3. Widget update 푸시 요청 구성

:method = POST
:scheme = https
:path = /3/device/<DEVICE_TOKEN>

// Headers
host = api.sandbox.puth.apple.com
apns-push-type = widgets
apns-topic = com.example.myApp.push-type.widgets   // 앱 번들 ID
{
    "aps": {
        "content-changed": true
    }
}

UIKit의 새로운 기능 - WWDC25 - 비디오 - Apple Developer

New design system

Liquid Glass 디자인에 맞게 변경되었습니다

Containers and adaptivity

iPadOS와 MacOS에서 반응형 UI 관련 부분이 변경되었습니다.

The menu bar

• iPad에 macOS의 메뉴 막대가 등장합니다.
• 기존 Storyboard로 지원하던 menubar 미지원이기 때문에 직접 구현해야 합니다.

Architectural improvements

Automatic observation tracking

UIKit에서 Swift Observable 지원 기능 추가

• layoutSubViews() 처럼 update 메서드에 연결 → 수동 setNeedsLayout 없어도 된다!
• Info.plist의 UIObservationTrackingEnabled 추가해 재배포하면 iOS 18 에서도 지원 가능 (iOS 26에선 default)

// Using an Observable object and automatic observation tracking
@Observable class UnreadMessagesModel {
    var showStatus: Bool
    var statusText: String
}
class MessageListViewController: UIViewController {
    var unreadMessagesModel: UnreadMessagesModel
    var statusLabel: UILabel
    override func viewWillLayoutSubviews() {
        super.viewWillLayoutSubviews()
        statusLabel.alpha = unreadMessagesModel.showStatus ? 1.0 : 0.0
        statusLabel.text = unreadMessagesModel.statusText
    }
}

• @Observable 객체인 UnreadMessagesModel 가 변경
  → viewWillLayoutSubviews() 가 동작하면서 자동으로 화면 업데이트

// Configuring a UICollectionView cell with automatic observation tracking
@Observable class ListItemModel {
    var icon: UIImage
    var title: String
    var subtitle: String
}
func collectionView(
    _ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath
) -> UICollectionViewCell {
    let cell = collectionView.dequeueReusableCell(withReuseIdentifier: "Cell", for: indexPath)
    let listItemModel = listItemModel(for: indexPath)
    cell.configurationUpdateHandler = { cell, state in
        var content = UIListContentConfiguration.subtitleCell()
        content.image = listItemModel.icon
        content.text = listItemModel.title
        content.secondaryText = listItemModel.subtitle
        cell.contentConfiguration = content
    }
    return cell
}

• cell에 관찰 추적을 지원하는 configurationUpdateHandler 사용
• 해당 메서드 내부의 handler closure에서 @Observable 사용 → 모델 handler를 재실행해 cell 업데이트

New UI update Method → updateProperties()

• UIView 와 UIViewController 에 추가된 메서드
• layoutSubviews() 직전에 실행 But 독립적이기 때문에 레이아웃 강제 없이 속성 무효화 / 세밀한 업데이트 가능
• layoutSubviews() 대체가 아닌 보완 (콘텐츠 추가, 스타일 적용 등)
• setNeedsUpdateProperties() 를 호출해 수동으로 트리거 가능

// Using automatic observation tracking and updateProperties()
@Observable class BadgeModel {
   var badgeCount: Int?
}
class MyViewController: UIViewController {
   var model: BadgeModel
   let folderButton: UIBarButtonItem
    override func updateProperties() {
        super.updateProperties()
        if let badgeCount = model.badgeCount {
            folderButton.badge = .count(badgeCount)
        } else {
            folderButton.badge = nil
        }
   }
}

• BadgeModel 이 변경될 떄 마다 updateProperties() 가 실행되어 badge 업데이트
• layoutSubviews() 대신 updateProperties() 를 사용하면, 크기 설정 같은 코드는 동작하지 않음 → 불필요한 작업을 줄이고 성능 개선

Update passes

기존 Update passes

1. layout pass가 먼저 실행
   - 최상위 계층에서 부터 각 뷰의 traits 업데이트 & layoutSubViews() 실행
2. 레이아웃이 자리를 잡으면 display pass 실행
   - 각 뷰에서 draw() 실행
   - 더이상 어떤 뷰에도 display pass가 필요 없을 때 까지 반복
3. 두 pass가 모두 끝나면 다음 프레임 랜더링, 화면에 UI 표시

신규 Update passes

• layout pass 중간에 updateProperties() 추가
• trait 업데이트 직후에 실행되기 때문에, trait을 안전하게 read 가능
• layoutSubViews() 직전에 실행되기 때문에 미리 레이아웃 무효화 가능

Automatically flush updates with animations

기존 Animation 동작 (iOS 18 이하)

// Manually animating changes with Observable objects
UIView.animage {
        // Set the new badge color on the Observable model object
        model.badgeColor = .red
// Manually flush updates on the view with animation
        badgeView.layoutIfNeeded()
}

• 수동으로 trait과 View 의존성을 유지하면 오류가 빈번하다
• 업데이트 or 애니메이션이 너무 많거나 적게 생성

Automatic flush update (iOS 26)

• flushUpdates 라는 새로운 애니메이션 추가
• 보류하던 업데이트를 애니메이션 직전/직후에 적용 → layoutIfNeeded() 호출 필요 없음
• flushUpdates 를 적용하려면 변경사항이 무조건 클로저 내에 있어야 한다

// Using the flushUpdates animation option to automatically animate updates
// Automatically animate changes with Observable objects
UIView.animate(options: .flushUpdates) {
    model.badgeColor = .red
}

• @Observable 객체인 badgeColor 를 사용하는 모든 뷰가 업데이트 자동 사용

// Automatically animate changes to Auto Layout constraints
UIView.animate(options: .flushUpdates) {
    // Change the constant of a NSLayoutConstraint
    topSpacingConstraint.constant = 20
    // Change which constraints are active
    leadingEdgeConstraint.isActive = false
    trailingEdgeConstraint.isActive = true
}

• Constraint에서도 당연히 사용 가능

Scene updates

SwiftUI와 UIKit의 혼용

• UIHostingSceneDelegate 추가
• 해당 delegate를 사용하는 UIkit 앱에서 SwiftUI Scene 지원 → UIKit에 VisionOS의 몰입형 공간과 볼륨 사용 가능

General enhancements

HDR color support

• 이미지 뿐만 아니라 UI에도 HDR 색상 사용 가능
• 기본 색상 값 + 노출 값
• 기본 Color Picker에서도 노출값 지원

// Create an HDR red relative to a 2.5x peak white
let hdrRed = UIColor(red: 1.0, green: 0.0, blue: 0.0, alpha: 1.0, linearExposure: 2.5)

Swift nofications

기존 NSNotificaiton이 NotificaitonCenter으로 변경

• Strongly typed Payload → 이제 일일이 타입캐스팅 안해도 된다
• Swift Concurrency 호환성 개선

// Adopting Swift notifications
override func viewDidLoad() {
    super.viewDidLoad()
    let keyboardObserver = NotificationCenter.default.addObserver(
        of: UIScreen.self
        for: .keyboardWillShow
    ) { message in
        UIView.animate(
            withDuration: message.animationDuration, delay: 0, options: .flushUpdates
        ) {
            // Use message.endFrame to animate the layout of views with the keyboard
            let keyboardOverlap = view.bounds.maxY - message.endFrame.minY
            bottomConstraint.constant = keyboardOverlap
        }
    }
}

Embrace flexibility

• UIScene 으로의 변화 필요
• UIApplicaiton 중심 API deprecated 예정
• UIWindow 용 init(windowScene:) 생성자만 남을 것
• iOS 26이후 릴리즈에서, 최신 SDK로 구축된 UIKit 앱은 전부 UIScene 라이프사이클을 사용해야만 실행 가능
• UIRequieresFullScreen 이 deprecated 예정 (iPadOS)

OpenURL supprots file URLs

기존 openURL메서드에 파일 URL도 허용

• 앱에서 미지원하는 문서도 사용가능
• 앱에서 미지원 되는 문서는 시스템이 외부 앱을 실행하고 URL을 따라 전달

SF Symbols 7

• 애니메이션 모드 추가
• 버튼 Configuration에 적용 가능하도록 지원
• 컬러 랜더링 모드 추가

새로운 디자인으로 UIKit 앱 빌드하기 - WWDC25 - 비디오 - Apple Developer

Tab views and split views

UITabBarController

// Minimize tab bar on scroll
tabBarController.tabBarMinimizeBehavior = .onScrollDown

// Add a bottom accessory
let nowPlayingView = NowPlayingView()
let accessory = UITabAccessory(contentView: nowPlayingView)
tabBarController.bottomAccessory = accessory

Navigation and toolbars

네비게이션 바의 디자인이 변경되었습니다.

Navigation의 BarButton

Titles and Subtitles

navigationItem.title = "Inbox"
navigationItem.subtitle = "49 Unread"

Bar Background

네비바 스크롤 시 보이는 Edge Effect가 다른 부분에도 적용됩니다.

let interaction = UIScrollEdgeElementContainerInteraction()
interaction.scrollView = contentScrollView
interaction.edge = .bottom
buttonsContainerView.addInteraction(interaction)

scrollView.topEdgeEffect.style = .hard

스크롤 동작

1. 화면 스와이프 도중에 스크롤 가능하도록 변경됩니다.
2. 화면 끝이 아니더라도 스와이프 백 가능하도록 변경됩니다

스와이프 정책 & 커스텀

• 스와이프 백 될지 안될지는 시스템이 알아서 판단
• 스와이프 액션 같은게 있는 경우, 뒤로가기 안함
• 상호작용 가능한 UI가 없는 경우, 뒤로가기 지원
• 스와이프 기능 우선순위 설정
  → 추가된 `interactiveContentPopGestureRecognizer`에 스와이프 백 실패 조건 정의

Presentation

• Popover UI 변경
• Sheet → 26 부터는 커스텀 배경 지우는걸 권장
• Action Sheet의 source 추가
  → 기존에는 그냥 다른 곳 터치시 내려갔으나 이제 source를 정의하지 않으면 cancel 버튼 표시

Search

상단에 위치했던 서치바가 이제 하단으로 이동

UISwitch

UISwitch 등의 컴포넌트 크기 변경됨
→ 기존 UI 해치지 않는지 확인 필요

UIButton

Configuration 에 .glass() 추가, 색조 커스텀 가능

UISlider

• 모멘텀, 스트레치 애니메이션 지원
• 눈금 추가 기능 + 값 제한 가능 (값 단위 설정, 10 씩만 설정 가능하거나 등등)
• 슬라이더 안에서 움직일 수 있는 범위 제한 기능
• thumb 핸들 없앨 수 있음 slider.sliderStyle = .thumbless

Custom elements

• Liquid Glass ≠ UIBlurEffect
• 글래스 이벤트는 상호작용 가능한 레이어
• 다른 UI의 최상단에 위치
• UIView 처럼 여러 커스텀 가능, 다크모드 지원, 애니메이션

// Adopting glass for custom views
let effectView = UIVisualEffectView()
addSubview(effectView)
let glassEffect = UIGlassEffect()
// Animating setting the effect results in a materialize animation
UIView.animate {
 effectView.effect = glassEffect
}

// Animating glass out using dematerialize animation
UIView.animate {
 effectView.effect = nil
}

동료들과 같이 보면서 생각하고, 혼자 작업 할 때에도 찾아 참고하기 쉽도록 책 각 부분의 결론을 모아 한 페이지(이지만… 짧진 않네요)로 정리해 보았습니다.

3장은 이론에 대한 이야기이므로, 직접 읽고 생각해 보시는 것을 추천드립니다!

1. 코드 정리법

1. 보호 구문 (Guard Clause)

// ❌ 이런 식의 중첩된 조건은 헷갈립니다.
if (조건)
    if (다른 조건 부정)
        ...

// ✅ 코드 시작 전 전제 조건을 말하는 것 같아 보기 좋습니다.
if (조건 부정) { return }
if (다른 조건) { return }

주의: 보호 구문을 남용하면 오히려 읽기 어렵습니다. → 조건들을 helper 메서드로 추출해서 보호 구문을 정리하세요.

2. 안 쓰는 코드

제발 지워라.

나중에 필요하면 어쩌지?
형상 관리 툴(Git 등)을 사용해서 롤백하면 됩니다.

⚠️ 항상 그렇듯, 각 정리 과정에서는 코드를 조금만 삭제할 것 → 잘못해도 복구가 쉽습니다.

3. 대칭으로 맞추기 (일관성)

일관성이 중요하다.

• 동작이 일관적이면, 이해가 빠릅니다.
• 두 가지 이상의 패턴을 섞어 쓰면 혼란스럽습니다.
• 공통성이 있어도 세부사항에 묻혀 드러나지 않을 수 있습니다 → 같은 부분들 속에 다른 부분을 분리하세요.

4. 새로운 인터페이스로 기존 루틴 부르기

기존 인터페이스를 호출하는 새 인터페이스를 만든다 → pass-through interface

5. 읽는 순서

읽기 좋은 순서로 정렬하기

파일의 마지막 부분에 전체를 이해하는 주요한 부분이 있다면 어렵습니다.

⚠️ 다른 코드 정리를 하고 싶어도 참자. 섞이면 안 됩니다.

6. 응집도를 높이는 배치

코드의 순서를 바꿔서 변경할 요소들을 가까이 놓자.
결합도가 있는 파일은 같은 디렉토리에 두자.

변경해야 할 동작을 찾았는데, 같이 변경해야 할 부분이 여러 곳에 흩어져 있습니다. 🤬
응집도를 높이는 순서로 정리하면, 더 쉽게 변경이 가능합니다.

7. 선언과 초기화를 함께 옮기기

선언과 초기화는 같이 둬라.

• 초기화는 이름이 주는 의미를 강화합니다.
• 한참 뒤에 초기화가 있으면 어떤 변수인지 까먹기 쉽습니다.

8. 설명하는 변수

표현식의 의도가 드러나도록 변수를 만들어 할당하세요.

❌ 변수가 무슨 의미인지 잘 모르겠습니다.
return new Point(
    ... 긴 표현식..., 
    ... 다른 긴 표현식...,
)

✅ 표현식의 의미가 명확합니다.
x := ...긴 표현식...
y := ...다른 긴 표현식...
return new Point(x, y)

9. 설명하는 상수

리터럴 상수는 상징적인 상수로 바꾼다.

❌ 404가 뭔데, 뭐 어떻게 하라고?

if response.code = 404
    ...코드...

✅ 무슨 코드인지 알겠다.

PAGE_NOT_FOUND := 404
if response.code = PAGE_NOT_FOUND
    ...코드...

❌ 이런 식으로 너무 빈약한 의미를 가진 코드 정리는 도움이 안 됩니다.

ONE = 1
...ONE... // 1이 필요한 어디든 사용

10. 명시적인 매개변수

일부 데이터가 명시적으로 전달되지 않는 경우:

루틴을 나눈다.

1. 매개 변수 값을 채운 후
2. 명시적으로 전달한다.

11. 비슷한 코드끼리

긴 코드를 읽다가 의미 구분이 되면 빈 줄로 분리하자.

12. 도우미 추출 (Helper Extraction)

목적이 분명하고 나머지 코드와 상호작용이 적은 코드 → 도우미(helper)로 추출한다.

// ASIS
routine()
    ...유지할 코드...
    ...변경할 코드...
    ...유지할 코드...

// TOBE
helper()
    ...변경할 코드...
routine()
    ...유지할 코드...
    helper()
    ...유지할 코드...

시간적 결합을 표현하려는 경우 (순서가 중요한 경우)

// ASIS
foo.a()
foo.b()

// TOBE
ab()
    a()
    b()

13. 하나의 더미 (One Lump)

필요한 만큼 코드를 하나의 더미처럼 느껴질 때까지 흩어진 코드를 모은 뒤, 정리하라.

한번에 머릿속에 기억하고 있어야 할 코드의 상세 내용을 줄여줍니다.
잘못된 작은 코드 조각은, 오히려 교류하는 과정을 알기 어렵게 합니다.

찾아볼 증상

• 길고 반복되는 인자 목록
• 반복되는 코드, 특히 조건문
• 도우미에 대한 부적절한 이름
• 공유되어 변경에 노출된 데이터 구조

14. 설명하는 주석

코드를 이해한 순간은 소중합니다. 기록하자.

• 코드에서 명확하지 않은 내용만 적자 → 이 코드를 처음 읽기 시작한 나를 떠올려보세요.
• 팀원이 읽을 것을 생각하며 적자.
• 코드 결함을 발견하면 달자.

15. 불필요한 주석 지우기

코드만으로 내용을 이해할 수 있다면, 필요 없는 주석입니다.

2. 관리

16. 코드 정리 구분 (PR 분리)

어딘가에는 코드 정리가 올라가야 하는데, 대체 어디에? → 가급적 코드 정리는 별도의 작은 PR들로 올리자.

안 좋은 사례:

1. 동작 변경과 코드 정리를 한 PR에 넣는다.
2. 사람들이 PR이 길다고 불평한다.
3. 코드 정리만 분리해서 PR에 넣는다.
4. 리뷰어들이 코드 정리만 담긴 PR이 무슨 의미로 만들었는지 모르겠다고 불평한다.
5. 다시 1로 돌아간다.

17. 연쇄적인 정리 (Sequential Tidy)

너무 대대적으로 코드 정리를 시작하지 말자. 너무 빠르게 바꾸지 말자. 작게 순차적으로 실행해 실패하지 않는 것이 시간을 아껴줍니다.

• 코드 정리는 새우깡과 같다 (계속 손이 간다) → 이 충동을 관리하는 것도 기술입니다.
• 정리의 크기는 본인 나름이지만, 아주 작은 단계로 나누어보자.
• 한 단계를 마치면, 다음 단계가 보일 것입니다.

연쇄 정리의 예시

• 보호 구문 → 조건이 설명하는 도우미 / 설명하는 변수 추출
• 안 쓰는 코드 → 코드를 읽는 순서 / 응집도를 높이는 배치
• 대칭으로 맞추기 → 유사한 코드가 묶여진 순서대로 읽을 수 있다
• 새로운 인터페이스로 기존 루틴 부르기 → 하나를 정리하면 뒤따른 정리가 다발로 이어진다
• 읽는 순서 → 너무 멀어 유사한지도 몰랐던 요소들이 보인다
• 응집도를 높이는 배치 → 하위 요소로 추출할 후보를 뽑을 수 있다
• 설명하는 변수 → 변수 이름으로 주석이 필요없어질 수 있다
• 명시적인 매개변수 → 매개변수 집합을 묶을 수 있다, 새로운 추상화를 도출할 수 있다
• 비슷한 코드끼리 → 코드 덩어리에 주석 붙이거나 도우미로 바꾸기
• 도우미 추출 → 보호 구문, 설명하는 상수나 변수, 불필요한 주석 지우기
• 하나의 더미 → 크고 명백하게 엉망인 하나의 덩어리가 보이면, 정리할 거리가 생긴다
• 설명하는 주석 → 설명하는 변수, 상수, 도우미를 쓸 수 있다면 주석을 코드로 옮긴다
• 불필요한 주석 지우기 → 중복 주석을 지우면, 명시적인 매개변수를 쓸 기회가 생긴다

18. 코드 정리의 일괄 처리량

하나의 변경사항을 검토, 배포하는 데 드는 고정 비용은 큽니다. → 코드 정리 비용을 줄이려면, 코드 정리 개수를 늘려서 동작 변경에 소용되는 비용을 줄여라.

통합 / 배포 전 고려사항

• 코드 정리를 변경을 돕는 작업으로 본다면, 다음 변경사항을 쉽게 하기 위해 얼마나 바꿔야 하나?
• 코드 정리의 크기가 어느 정도일 때 통합 / 배포가 쉬울까?
• 충돌: 일괄 처리 작업량이 많다 → 통합 지연시간, 충돌 가능성 ⬆️
• 상호작용: 코드 정리 사이에 상호작용이 있으면, 병합 비용 증가
• 추측: 필요한 것보다 더 많이 정리하면, 예상치 못한 추가 비용 발생

19. 리듬 (Rhythm)

코드 정리는 몇 분에서 한 시간이면 충분합니다.

• 한 번의 코드 정리에 한 시간을 넘기지 말 것.
• 코드가 너무 엉망이라서 몇 시간을 들이더라도 정리하는 게 나을 수도 있습니다.
• 코드 정리를 선행하면, 코드 정리한 내용도 뭉쳐집니다.

20. 얽힘 풀기 (Untangling)

교착 상태에선, 리셋하고 코드 정리 먼저 해보자. 선후 관계가 명확해지는 건 시간이 해결해 준다.

21. 코드 정리 시점

그래서 코드정리, 동작변경 어떤거 먼저?

1. 변경 안될 코드 / 개선해도 배울게 없다 → 코드 정리 포기
2. 분량에 비해 보상이 없거나 잠재적이다 / 작게 여러번 할 수 있는 양이다 → 정리를 미루기
3. 정리 안하고 두면 비용이 늘어난다 / 정리를 안하면 일이 안끝난거 같다 → 동작 변경 먼저 하고 정리
4. 정리하면 이해나 변경이 쉬운 즉각적 효과 / 어떻게 정리할 지 알고 있다 → 정리 먼저하고 동작 변경