What's new in Xcode 16 (feat. WWDC 2024)

안녕하세요. 그린입니다 🍏

이번 포스팅에서는 WWDC 2024에서 Xcode 16 세션을 보겠습니다 🙋🏻

 

발표된 Xcode 16에서는 어떤 편리한 기능들이 생겨났고, 성능은 좀 더 좋아졌을까요?
바로 한번 같이 시청해보시죠!

 

Xcode 16의 새로운 기능 - WWDC24 - 비디오 - Apple Developer

 

그나저나 이제 한국어 자막을 제공해줘서 너무 좋네요 👍

 

---

Xcode 16

---

코드 완성 기능

코드 완성 기능이 이제 더 빈틈없는 코드를 추천해줍니다.

Swift 및 Apple SDK를 통해 특별히 더 훈련된 온디바이스 코딩 모델덕이라고 해요!

 

 

이렇게 코드 완성은 함수 이름, 주석과 같은 주변 코드 맥락을 활용해 개발자가 구현하고자 하는 코드를 유추하여 제안해줍니다.

AI처럼 말이죠.

 

이게 가능한건 모두 Apple Silicon덕이며 macOS Sequoia 기반의 Xcode 16을 실행해야 사용할 수 있습니다 🙋🏻

 

---

Swift 6 지원

 

이제 Swift 6는 동시성 안정성을 보장하는 새 언어 모드를 지원해줍니다.

일반적으로 런타임에만 발생하는 데이터 경합을 컴파일 타임 문제로 가져와줍니다.

그렇기에 보다 더 안전하게 컴파일 타임에 에러를 보고 수정할 수 있죠.

해당 모드를 활성화 하기 위해선 Swift 6 모드를 채택해야해요.

 

 

해당 프로젝트에서 Build Settings > Swift Compiler - Upcoming Features 섹션으로 이동합니다.

여기서 Yes로 항목들을 변경하면 이제 적용되어 워닝이 표출됩니다.

즉, 워닝은 동시성이 안전하지 않아요~ 하고 알려주는것이에요.

 

워닝이 나오는곳에서 적절히 데이터 경합이 벌어지지 않게 처리해줘야 합니다.

마이그레이션 시 이렇게 먼저 점진적으로 하나씩 해결을 하는것도 좋습니다.

 

그후, 아래와 같이 마이그레이션이 완료되면 Build Settings에서 Swift Compiler의 Language를 Swift 6로 설정하면 됩니다.

 

 

저도 Xcode 16 베타를 통해 Swift 6 대응을 하고 있는데, 기존 코드에서 워닝이 정말 많더라구요 🥲

Swift 6 마이그레이션에 대해서 추후 또 포스팅을 할 예정입니다 😃

먼저 궁금하신분들은 해당 세션을 참고해주세요!

 

Migrate your app to Swift 6 - WWDC24 - Videos - Apple Developer

 

---

프리뷰 개선

프리뷰가 개선되었어요.

두 API가 추가되었는데요.

 

하나는, Previewable 매크로입니다.

State와 같은 속성 래퍼에 사용할 수 있어 프리뷰 블록 코드 내에서 API를 바로 사용할 수 있어요.

 

 

바인딩을 위해 프리뷰에서 State를 직접 만들때 @Previewable을 붙이는것이죠.

기존처럼 컨테이너를 감싸거나 하지 않아도 된다는 소리죠!

 

두번째로는 PreviewModifier API 입니다.

해당 기능을 통해 쉽게 프리뷰 관련 경험 혹은 데이터를 공유할 수 있어요.

중복 코드를 줄이고 프리뷰 시스템에서 데이터를 캐시할 수 있습니다.

 

 

RobotNamer는 서버와 동작하여 로봇 이름을 서버에서 비동기로 가져오고 있습니다.

그런데 프리뷰를 빌드하는 동안 서버를 계속 찌를 필요가 없죠.

 

그래서, 서버를 찌르는 대신 PreviewModifier로 모든 프리뷰를 위한 RobotNamer를 만들 수 있습니다.

 

해당 프로토콜을 채택하여 2가지 요구사항을 구현해야합니다.

 

makeSharedContext로 데이터를 로드 및 저장해야 합니다.

비동기식으로 작동하며 예외 처리를 넘겨 데이터를 비동기식으로 로드해 오류를 처리할 수 있죠.

핵심은 해당 메서드가 같은 타입의 모든 모디파이어에 대해 한번만 호출된다는 것입니다.

프리뷰에서 데이터를 캐시해주기 때문이죠.

 

그 다음 body를 구성하면 됩니다.

프리뷰를 공유된 컨텍스트로 래핑할 수 있죠.

 

모디파이어를 구성했으니 이제 trait을 통해 프리뷰에 제공하면 됩니다.

만약 자주 사용한다면 아래와 같이 코드를 줄이기 위해 PreviewTrait에 대한 확장을 정의해둬도 됩니다.

 

 

이제 프리뷰에 적용해볼까요?

 

 

간단히 이렇게 traits를 통해 적용하면 되는것이죠!

프리뷰 간 데이터를 공유해야하는 경우 유용하죠.

 

또한, 이 외에도 새 실행 엔진을 도입하여 프리뷰가 정말 빨라졌습니다 😃

 

 

더 이상 카피할 필요없이 바로 재조립합니다.

 

이제 빌드 개선으로 넘어가볼까요?

 

---

Explicit modules

 

Xcode 16은 명시적 모듈로 빌드가 정말 많이 개선되었어요.

병렬처리 및 디버깅이 빨라졌어요.

C나 옵젝씨에선 명시적 모듈이 기본적으로 활성화되어 있습니다.

그런데 Swift에선 활성화를 직접해야 합니다.

 

 

Build Settings에서 Explicity Built Modulers를 YES로 활성화 시킵니다.

 

참고로 Xcode 16의 Swift 패키지 통합 기능이 개선되어 패키지 확인을 기다리지 않아도 해당 빌드를 대기열에 추가할 수 있어요.

 

명시적 모듈을 사용하면 Xcode가 각 컴파일 단위의 처리를 스캔, 모듈 빌드 그리고 원본 코드 빌드 등 세 단계로 나눕니다.

 

 

처음 두 단계는 빌드 로그에서 Scan dependencies / Compile Clang module / Compile Swift module 명령어로 찍히죠.

 

 

이전엔 이런 작업이 소스 파일 컴파일의 일부로 암시적으로 수행되었어요.

이젠 빌드에 대한 분석과 개선된 병렬 처리를 사용하는것을 넘어 모듈 문제로 인해 빌드 실패에 대해서 더 명확한 오류 메시지를 받을 수 있어요.

 

명시적 모듈도 빌드 타임라인에 반영되기에 빌드 프로세스 중 어디에서 시간이 걸리고 있는지 쉽게 확인할 수 있고 최적화에도 도움을 주죠.

 

 

더 자세히는 아래 Demystify explicitly built modules 세션을 참고해주세요 🙋🏻

 

Demystify explicitly built modules - WWDC24 - Videos - Apple Developer

 

그럼 이제 디버그 개선을 알아볼까요?

 

---

Debug

표현식을 평가할 때 LLDB가 빌드 출력을 재사용할 수 있기 때문에, 명시적 모듈을 사용하면 디버그가 빨라집니다.

이제 iOS 18의 배포 타겟에 대해 빌드할 때, 기본 디버그 심볼 형식이 DWARF5 입니다.

즉, dSYM 번들이 작아지며 심볼 검색이 빨라집니다.

 

스레드 성능 검사기가 Xcode 16에서 실행될 때 이제 더 많은 작업을 수행합니다.

 

 

메인 스레드 행과 우선순위 역전을 찾는것에서 그치지 않고 과도한 디스크 쓰기 및 느린 앱 실행 진단을 표시하는것이 추가되었어요.

즉 앱 성능 개선에 도움을 줄 수 있죠.

 

 

새로운 진단 로그 카테고리가 생겨났어요.

(Disk writes나 Launches)

 

 

여기서 보이는 화살표부터 처리하는게 사용자에게 가장 큰 영향을 미치는 문제를 우선 처리하는것이죠.

 

코드를 디버그하는 동안 스레드 성능 검사기는 가장 심각한 문제를 런타임 문제로 표시해요.

즉, 집중해야 할 코드 행을 정확히 찾아내줍니다.

 

 

이런식으로 메인 스레드에서 동영상 에셋을 로드하면 안된다고 알려주죠.

 

브레이크 포인트를 찍어볼까요?

 

 

Backtrace를 추적할 수 있습니다.

이렇게 호출 스택을 따라가며 각 프레임의 주변 코드를 볼 수 있죠.

변수에 마우스를 올려 값을 확인할수도 있구요.

 

또한, 새로운 RealityKit 디버거 덕에 공간 개발도 훨씬 수월해졌다고 합니다.

 

 

클릭 한번으로 실행 중인 앱의 엔티티 계층 구조의 스냅샷을 캡쳐하고 Xcode 내에서 바로 3D로 탐색할 수 있습니다.

 

이제 테스트에 관해 알아볼까요?

 

---

Test

 

Swift Testing은 Swift 언어 기능을 활용해 테스트를 더 강력하고 간결하게 표현할 수 있는 새로운 프레임워크입니다.

기존 XCTest와 함께 사용할 수 있죠.

 

 

위와 같이 Testing 프레임워크와 테스트를 할 앱을 임포트합니다.

그 후, Test 매크로를 추가하면 되죠.

이제 그럼 Xcode가 테스트 메서드로 인식하여 탐색기에 표시합니다.

 

 

expect 매크로를 활용해 여러 자료형의 형식이 동일한지 확인할 수 있습니다.

 

 

만약 테스트에 실패하면 에러를 눌러 각 값에 대한 추가 정보를 볼 수 있어요.

 

수정이 되었으면 좀 더 편리하게 Quick Actions으로 테스트를 빠르게 실행해볼 수 있습니다.

Command + Shift + A로 퀵 액션을 활성화해 test again을 입력해 테스트를 재실행할 수 있어요.

 

 

Test 매크로는 함수만 테스트로 표시하지 않습니다.

함수에 정보를 추가하거나 함수의 작동 방식을 바꿀 수 있는 특성도 처리할 수 있어요.

 

 

이렇게 말이죠.

 

또한, Swift Testing은 태그 기반 구성을 제공합니다.

태그를 만들어 여러 Suite에 걸쳐 테스트를 그룹화할 수 있죠.

 

 

이렇게 태그의 모든 테스트를 실행할 수 있어요.

태그를 통해 테스트 계획에서 테스트를 포함 및 제외할수도 있죠.

 

Edit Test Plan에서 가능합니다.

 

 

이렇게 planting 태그에 대해 배제할 수 있어요.

 

이제 마지막으로, Profile에 대해 알아보겠습니다.

 

---

Profile

테스트는 빨라도 앱 실행은 느릴 수 있죠.

 

 

Instruments는 성능 문제를 진단하는데 효과적인 툴입니다.

Xcode의 Profile에서 바로 접근할 수 있죠.

 

특히, Time Profiler를 통해 코드의 CPU 사용량을 시각화하고 앱을 실행하는데 소요되는 시간을 측정해줍니다.

 

 

앱을 시작할 때 정말 긴 행이 발생하는걸 볼 수 있네요.

 

이걸 해결해볼까요?

 

먼저, 왜 발생하는지 이유를 파악하기 위해 Inspection Range를 행 구간에 설정해 시작합니다.

 

 

문제의 범위를 줄이기 위해서 Instruments 16의 새로운 Flame Graph를 사용할 수 있습니다.

(Jump Bar에서 활성화 할 수 있습니다.)

 

 

Flame Graph는 추적 실행에 대해 문제를 한눈에 볼 수 있게 해줍니다.

실행 간격은 추적에서 차지한 시간 비율에 따라 가중치가 부여되고 간격은 왼쪽에서 오른쪽 정렬이 됩니다.

즉, 그래프의 왼쪽 부분은 항상 가장 많이 실행된 코드를 시각화합니다.

 

 

파악해보면 이 load 함수가 실행 시간의 대부분을 차지하고 있습니다.

거슬러 파악하며 올라가면, 이 load는 SwiftUI 뷰 바디에서 호출되고 있구요.

 

해당 body를 수정하기 위해 프레임에서 우클릭을 통해 Reveal in Xcode를 선택해 바로 해당 코드로 갈 수 있습니다.

 

 

그 후 문제가 되는 지점을 수정해주면 됩니다.

(해당 세션에선 메인 스레드에서 load를 진행하여 성능 문제가 발생했었습니다. 이에 백그라운드 스레드로 작업을 옮겼죠.)

 

 

이후 다시 추적해보니 이제 행이 확연히 줄었죠. 

에셋이 여러 백그라운드 스레드에 분산되어 더 이상 메인 스레드를 막지 않기에 성능이 향상되었습니다.

 

Profile을 통해 앱을 정기적으로 검사해 성능을 향상시켜보면 좋을것 같아요.

 

---

그 외 업데이트 사항

이번 포스팅에서 다룬 주제들 외에도 정말 다양한 업데이트가 생겼습니다.

 

 

Xcode 16을 설치해 한번 더 많은 개선사항들을 찾아보는것도 재밌을것 같네요 👍

 

---

레퍼런스

Xcode 16의 새로운 기능 - WWDC24 - 비디오 - Apple Developer