What's new in SwiftUI (feat. WWDC 2026)

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

이번 포스팅에서는 WWDC 2026에서 소개된 What's new in SwiftUI 세션을 정리해보겠습니다 🙌

뭔가 오랜만에 SwiftUI를 공부하고 정리하는것 같아 재밌을것 같아요 😁

 

Refreshed look and feel

리퀴드 글래스 기능이 나온건 벌써 좀 되었지만, 여전히 강조하고 개선시키고 있습니다.

appearsActive 환경값을 통해 창이 비활성화 일때 불투명도를 조절할 수 있어요.

 

또한, 이제 macOS나 iPadOS에서 메뉴바가 정말 심플해졌는데요.

원한다면 labelStyle을 통해 타이틀과 아이콘이 같이 나오도록도 설정할 수 있죠.

 

그리고 어쩌면 폴더블을 예상케하는 기능도 생겨났어요.

iOS 27에서는 프리뷰를 통해 앱이 대화형 크기 조정에 어떻게 반응하는지 볼 수 있어요.

이렇게 늘리고 줄여서 이상이 없는지 바로 확인할 수 있죠.

 

이는 추후 출시된다는 소문이 많은 폴더블에 대한 대응을 미리 해놔라 라는 의미로도 들려지네요 🥲

 

 

이 반응형은 SwiftUI로 앱을 구성하면 자동으로 따라오지만 만약 UIKit과 SwiftUI 모두 사용한다면 고려해야할 몇가지가 있습니다.

 

 

1️⃣ 스크린 지오메트리 확인

2️⃣ 디바이스 대신 사이즈 클래스 이용하기

3️⃣ 화면 회전과 같은 방향에 대해 체크

 

이에 대해 더 자세히 알아보려면, 아래 세션을 참고하세요!

 

Modernize your UIKit app - WWDC26 - Videos - Apple Developer

 

탭뷰에서도 새로운 기능이 생겼습니다.

 

이렇게 우측에 특별한 탭 배치를 하고 싶다면 prominent role 속성을 주어 그걸 표현해낼 수 있어요.

 

이 탭 메뉴는 아래처럼 디바이스 사이즈에 따라 자동으로 크기가 변하거나, 항목의 갯수가 줄어들거나 늘어나게 표현될 수 있습니다.

 

이때 줄어들어서 숨겨진 메뉴들은 더보기 버튼을 통해 오버플로우 메뉴로 확인할 수 있죠.

 

 

또한, 이렇게 ToolbarItemGroup에서 undo, redo가 기본적으로 숨겨져있는데 만약 가시성있게 주고 싶다면 visibilityPriority를 high로 속성을 지정해주면 됩니다.

물론 이것도 이번 iOS 27에서 나온 기능이죠.

 

 

반대로, 오버플로우 메뉴로 숨기려면 ToolbarOverFlowMenu로 지정하면 됩니다.

 

 

마지막으로, 절대 숨기지 않고 항상 표현해주고 싶은 메뉴가 있다면 이렇게 placement 속성에 tobBarPinned를 사용하면 되죠.

 

 

컨텐츠가 많아서 스크롤 시 네비게이션 바를 숨기고 싶다면 toolbarMinimizeBehavior 뷰 모디파이어를 이제는 사용하여 원하는것을 구현할 수 있습니다.

 

---

Document-based apps

지금까지 SwiftUI는 문서 기반 앱을 지원해왔습니다.

이번 릴리즈에선 이걸 기반으로 더 확장된 새로운 API를 가져왔어요.

 

Document creation context

이제 이렇게 문서를 생성할때 빈 문서 혹은 사진으로 바로 문서를 만들 수 있어요.

이걸 가능하게 하는 코드들이 들어가서 구성할 수 있습니다.

 

이렇게 DocumentGroupLaunchScene에서 버튼을 두개 blank, photo로 구성합니다.

 

그 후 DocumentGroup 구성으로 context를 넘겨주는것이죠.

그러면 blank, photo 컨텍스트가 넘어가 만약 photo라면 자동으로 바로 사진 선택창을 띄우게 되는것입니다.

 

Performance

문서 기반 앱은 잦은 업데이트가 있고 또한 그에 따라 UI 업데이트도 잦을 수 있죠.

 

성능은 어떻게 최적화 시켰을까요?

 

 

우선은 가장 기본적으로 Obervable 매크로를 이용합니다.

이를 통해 업데이트 되어야 할 친구들만 업데이트 쳐서 성능을 어느정도 보장해주죠.

 

그치만, 가장 중요한건 읽기/쓰기 성능이죠.

 

 

여기서 새로운 API가 등장합니다.

성능 향상을 위해 우선 WritableDocument 프로토콜을 채택합니다.

이는 세가지의 준수사항을 가지고 있어요.

 

1️⃣ writableContentTypes: 문서의 타입을 나타냅니다. 여기서는 커스텀한 스티커문서 타입을 지정해줬어요.

2️⃣ snapshot: 쓰기 스냅샷을 지원해줍니다. 커스텀한 PageSnapshot 객체를 만들어 사용할 수 있죠.

3️⃣ writer: DocumentWriter 프로토콜을 준수하며 지정된 형식으로 문서를 디스크에 쓰는 방법입니다. 요청된 컨텐츠 형식을 지정해요.

 

DocumentWriter 프로토콜에는 snapshot의 개념이 존재합니다.

여기서 준수할 사항은 write죠.

write 메서드는 nonisolated이자 비동기입니다.

즉, 비용이 많이 드는 쓰기 작업 자체를 백그라운드에서 수행하게 하죠.

그리고, snapshot을 통해 업데이트가 필요한 부분만을 쓰죠.

이런 최적화에도 불구하고 당연히 쓰기 작업은 오래걸릴 수도 있습니다.

이때 progress인자로 주어지는 Subprogress API를 사용해 진행 사항을 알 수 있습니다.

 

그 다음 ReadableDocument도 있어요.

 

 

둘은 쌍둥이라고 볼 수 있을 정도로 완벽하게 대칭됩니다.

당연하겠죠?

 

이 두가지를 활용하여 문서 읽기/쓰기 성능을 향상시켰습니다.

 

---

First-class support for URL access

페이지를 이미지로 저장할 수도 있어야겠죠?

앱이 없는 사람도 충분히 있으니까요.

Document API writer를 활용하면 충분히 다른 형식으로도 저장이 가능합니다.

 

 

우선, writableContentTypes에 png도 넣어줍니다.

이미지로 저장을 위해서요.

 

 

그리고 Writer 구현체에서 contentType이 png일때 하나의 이미지로 합쳐지도록 코드를 추가해줘요.

 

이렇게 해주면 손쉽게 이미지로 문서를 저장할 수 있습니다 🙌

 

---

Presentation and interaction

화면에 보이는 요소와 인터랙션에 대한 개선들이 있습니다.

 

 

reorderable과 reorderContainer를 이용한다면 리스트에 있는 요소들의 순서를 내 마음대로 변경할 수 있어요.

이 Reorderable API는 List만이 아니라 모든 컨테이너에서도 동일하게 적용하고 동작할 수 있습니다.

 

이제 SwiftUI는 List뿐만 아니라 모든 뷰에서 스와이프 동작을 지원합니다.

 

swipeActionsContatiner를 붙이고 그 안에서 아이템 섹션에는 원하는 swipeActions를 구성해주면 됩니다.

 

또한 만약 항목을 제거하고싶다, 이 예시에서는 스티커를 제거하고 싶다? 라면 이렇게 할 수 있습니다.

우선 요렇게 contextMenu를 통해 삭제 버튼을 배치하고 stickerToDelete 변수에 저장되도록 해줍니다.

그리고 이렇게 이번 API에서 업데이트된 confirmationDiaglog를 통해 삭제 다이얼로그를 구성하고 삭제나 다른 동작을 할 수 있어요.

이건 alert 모디파이어로도 대체할 수 있습니다.

 

이 밖에도 무수한 업데이트 사항들이 있어요ㅎㅎ

 

---

Data flow and performance

이제 데이터 흐름과 성능 주요 개선 사항들에 대해 살펴볼께요.

 

잘 알고 있는, AsyncImage는 온라인의 이미지를 나타내는데 용이하고 나타날때 그려줬죠.

그리고, 지금까지는 이미지를 메모리에 유지하지 않았어요.

즉, 캐싱이 없었죠.

그렇기에 다시 위로 스크롤하면 다시 그려줬습니다.

 

이제 iOS 27부터는 AsyncImage가 표준 HTTP 캐싱을 지원해줍니다 👍

즉, 기본적으로 이미지 캐싱이 되는거죠!!

별다른 코드 변경없이도 자동으로 적용됩니다.

 

 

물론, cachePolicy 파라미터가 생겨 원하는 캐시 정책을 설정할 수도 있습니다.

 

 

아니면, 이렇게 아예 커스텀한 캐시 정책을 추가할 수도 있어요.

 

앱 데이터를 저장하는 좋은 방법은 Observable 클래스를 이용하는것이죠.

이전까지는 이 코드에서 만약 상위 뷰가 업데이트되어서 StickerStoreView가 초기화되면 StickerStore의 새 인스턴스가 만들어졌어요.

하지만 원래 인스턴스가 여전히 State 변수에 저장되어 있었습니다.

그렇기에, 새 인스턴스는 그냥 버려졌죠.

이 기존 방식은 매번 초기화될때마다 새 인스턴스를 버리고 낭비하는 아주 안좋은 성능이였습니다.

 

이제는 State 프로퍼티를 사용하여 초기화되고 저장되는 클래스가 lazy하게 되었습니다.

 

즉, 한번만 초기화된다는 소리죠 👍

 

이를 가능하게 하는건, @State Dynamic Property에서 @State Macro로 변환되었기에 가능합니다.

이제는 이후 초기화에서는 새 클래스 인스턴스를 만들지 않게 됩니다.

 

더 좋은 소식은, 이 변환은 하위 호환도 백포팅 되어서 iOS 17도 적용이 자연스레 되었다는 점입니다!

 

 

다만 이제는 이 변경으로 인해 이전 버전에서 이렇게 사용하고 있던 코드들이 초기화 관련 에러를 뱉을 수 있게 됩니다.

즉, 선언 시 할당하지 않아야 합니다.

 

 

그리고 어쩌면 가장 많이 개발자들을 괴롭히고 마주칠 수 있는 부분인데요.

뷰에 많은 중첩된 표현이 있다면 이렇게 컴파일러가 오류를 냅니다.

즉, 주어진 해당 시간안에 컴파일러가 타입 체킹을 하기 어렵다는 투정이죠.

 

 

이런일이 발생하는 근본적인 원인은 컴파일러가 해당 컴포넌트를 그릴때 어떤 조건으로 그릴지 모르기에 다 시도해봐야되는거죠.

이렇게 선택지가 많고 중첩되면 더 복잡해질 수 밖에 없죠.

 

이렇게 복잡한걸 생성 유형에 제약을 받지 않고 컨텐츠를 그저 조합하기만 한다면 얼마나 좋을까요?

 

이게 바로 이번 릴리즈에서 이룬것입니다.

 

 

가장 일반적인 빌더 집합이 이제 단일 이니셜라이저를 공유해 단 하나의 명확한 경로만 남깁니다.

 

ContentBuilder가 나타났기에 가능한 일입니다.

여러 다른 빌더 유형이 하나로 통합되었어요.

단일 빌더를 위해서요!

이는 기존 ViewBuilder의 진화로 모든 타겟 버전에서 사용할 수 있습니다 👍

 

그리고 이제는 AI 시대니까..

이 명령어 한줄로 Swift나 SwiftUI 관한 애플의 스킬을 익스포트 받을 수 있습니다.

 

 

---

Conclusion

개인적으로 엄청 많은 변화는 없다고 느껴지는데 알짜인 변화들이 있어 보여요.

AsyncImage도 이미지 캐싱이 되지 않아 쓰는 선택지에서 배제되었었는데 이제는 지원해준다니 감개무량하네요!

또한, SwiftUI View 성능이 정말 항상 불만이였는데, 특히 컴파일러 뷰 타입 체크 성능 관련해서...

이것 또한 개선되었다니 큰 업데이트라고 생각됩니다!

이게 다 소개처럼 잘 작동하고 정말 체감이 되는거라면 Xcode 27로 업데이트 하지 않을 이유가 없네요ㅎㅎ

 

---

References

SwiftUI의 새로운 기능 - WWDC26 - 비디오 - Apple Developer