What's new in SwiftUI (WWDC26)
목차
- Refreshed look and feel
- Document-based apps
- Presentation and interaction
- Data flow and performance
Refreshed look and feel
새롭게 앱을 빌드하고 실행하면 Liquid Glass 디자인이 업데이트 된 모습으로 자동 적용
appearsActive를 사용해서 조건부로 버튼의 불투명도를 조절할 수 있음.
Xcode 27부터는 Preview에 리사이징이 가능하도록 변경
SwiftUI로 만든 앱은 이런 기능을 자동으로 지원하지만 UIKit과 SwiftUI를 모두 사용하고 있다면 고려해야할 사항 존재.
Screen Geometry 확인, 디바이스 대신에 size class 사용, 화면 회전 대응 등이 추가되는데 WWDC26의 Modernize your UIKit app 확인
우측 하단에 새로운 탭 형태가 생겼고, 띄워서 배치하려면 role을 prominent로 지정.
앱의 윈도우 크기를 조정하면 Toolbar 아이템이 시스템에 의해서 자동으로 조정되며, 공간이 부족할 때 어떤 버튼을 계속 표시할 지 여부도 지정할 수 있음.
visibilityPriority를 높이므로써 공간이 좁아져도 가시성 있게 유지할 수 있음.
반대로 숨기고 싶다면 ToolbarOverflowMenu를 사용하면 됨.
절대로 숨기고 싶지 않은 버튼의 경우에는 placement에 topBarPinned를 지정하면 됨.
toolbarMinimizeBehavior를 사용하면 스크롤 시 네비게이션 바를 시스템이 자동으로 숨길 수 있음.
SwiftUI는 Document 기반 앱을 지원했으나 이번 iOS27부터 더 확장된 API를 제공. DocumentGroupLaunchScene에 source를 통해 버튼을 지정하고 DocumemtGroup의 context를 클로저를 통해 받아서 해당 source에 따라서 초기표현할 UI를 결정할 수 있음.
문서 기반앱은 특히 Performance 중 데이터를 읽고 쓰는 작업이 많음.
Document 앱은 우선 View 영역에서 @Observable 매크로를 이용해 의존하는 프로퍼티가 변경될 때만 View를 업데이트 해서 이것 만으로도 View 성능을 향상.
그러나 문서 기반 앱은 읽기와 쓰기 성능을 개선하는게 가장 중요함.
성능 향상을 위해 WritableDocument를 채택
- writableContentTypes 변수를 정의해야 하는데 커스텀 한 타입으로 지정 가능.
- 쓰기용으로 현재 문서 콘텐츠를 반환하는 snapshot 메서드로 콘텐츠를 나타내기 위해 PageSnapshot 구조체를 사용.
- writer를 작성하는데, 지정된 형식으로 디스크에 쓰는 방법에 대한 정의
DocumentWriter 프로토콜에는 Snapshot이라는 개념이 존재하는데, 유일한 요구사항은 write 메서드를 작성하여 성능을 최적화 할 수 있는 여러 기회를 제공함.
- nonisolated asnyc로 비동기 메서드로 백그라운드에서 실행
- 실제로 업데이트 필요한 부분만 작성하는데 previous와 snapshot을 비교하여 결정
그러나 이런 모든 최적화에도 불구하고 시간이 오래 걸릴수도 있어서 process 를 통해 SwiftUI가 현재 쓰기 작업에 대해 진행경과를 확인할 수 있음.
ReadableDocuments를 통해서 DocumentWriter의 쌍둥이 프로토콜로 읽기를 지원
각 프로토콜은 지원퇴는 콘텐츠 유형에 대한 타입이 필요하며, Writer는 Snapshot을 제공하고 Readble은 apply를 통해 대칭됨. 또한, Writer 프로토콜은 write 메서드를 통해 Readable 프로토콜은 read를 통해 대칭됨.
또한 앱이 없는 사람들과도 공유할 수 있도록 페이지를 이미지로 저장하는 기능도 제공 CoreGraphics를 활용해 PNG로 변환하는 것처럼 페이지를 다른 타입으로 저장할 수 있음.
추가적인 형식을 지원하기 위해 ContentType을 추가하고, 앱이 지원하는 형식에 대해서 확인하고 PNG 형식으로 만들기 위해서 CoreGraphics를 활용해 스티커랑 배경 사진을 하나의 이미지로 만들고 최종적으로 결과물을 만들어 냄.
프레젠테이션과 인터랙션에 대해서도 개선사항들이 존재.
reorderable modifier를 추가하고 reorderContainer에 apply를 적용하여 손쉽게 순서 변경을 지원할 수 있음.
apply 메서드는 내부적으로 오픈소스은 swift-collection 패키지를 사용
Reorderable API는 List 뿐만 아니라 LazyVGrid 등 모든 컨테이너에서 동작함.
SwiftUI는 이제 List 뿐만 아니라 모든 View에서 Swipe 동작을 지원하며, swipeActionContiner를 modifier로 추가하면 됨.
만약 특정 항목만 제거하고 싶은 경우에는 contextMenu를 통해 삭제 아이템에 배치한 후 confirmationDialog를 통해서 삭제 동작을 정의할 수 있고, 이는 .alert 대체 가능
휼룡한 성능은 앱이 반응적이고 세련되게 느껴지도록 하는 데 중요. 따라서 데이터가 흐르는 방식에 신중하게 접근하는 것이 가장 좋은 방법.
AsyncImage가 표준 HTTP 캐싱을 지원(서버의 캐시 헤더)하며 기본적으로 이미지가 캐싱됨.
이미지 다운로드 방식을 더 세밀하게 제어하려면 URLRequest를 직접 만들어서 더 세밀하게 제어할 수 있음. 이를 통해서 요청별로 다양한 커스터마이즈가 가능함.
아예 URLSeesion을 직접 만들어서 필요한 용량으로 URLCache를 설정할 수도 있음. 이 경우 .asyncImageURLSession modifer를 통해서 전달
SwiftUI는 앱이 데이터를 모델링하고 저장하는 다양한 방법을 제공하는데 앱 데이터를 저장하는 가장 좋은 방법은 Observable 클래스를 사용하는 것
iOS 26까지는 View가 초기화 되면 store가 새로운 인스턴스를 생성. 기존 인스턴스가 여전히 @State를 통해 저장되고 있음에도 불구하고 버려지기 때문에 성능이 좋지 않음.
하지만, iOS 27 부터는 State 프로퍼티를 사용하여 초기화되고, 저장되는 클래스가 lazy하게 동작함. (이제 한번만 초기화 됨)
이는 @State가 Dynamic Property에서 Macro로 전환되었기 때문
이제부터 초기화 이후에는 새 클래스 인스턴스가 생성되지 않으며, 해당 동작은 하위 호환되어 iOS 17부터 지원하는 것으로 백포팅되었음.
하지만 이로 인해서 init에서 동일한 @State 변수에 값을 할당할 경우 Xcode가 초기화 전 사용할 수 없다는 오류를 발생.
이 오류를 해결하기 위해서는 불필요한 기본 값 할당을 제거할 것.
좋은 런타임 성능을 유지하는 것은 앱이 원활하게 작동하는데 중요하고, 또 다른 종류로는 앱 개발 경험에 영향을 줄 수 있는 성능임.
View가 깊게 중첩되어 있다면 컴파일러가 오류를 발생 시키는 오류를 만날 수 있음.
원인은 컴파일러가 해당 컴포넌트를 그릴 때 어떤 조건을 그릴지 모르니 모두 다 시 도해야하는 문제에서 기인함. 따라서, 중첩이 깊어질수록 더 복잡해지고 오래 걸릴 수 밖에 없음.
복잡한 빌더들이 생성 타입에 제약받지 않고, 콘텐츠를 조합하는 형태로 이번 릴리즈에서 개선함.
가장 일반적인 Builder 집합이 이제 단일 initializer를 공유하여 단 하나의 명확한 경로만 남김.
@ContentBuilder를 통해 단일 빌더를 위해 여러 다른 빌더의 유형을 하나로 통합. SwiftUI API 전반에 걸쳐 통합된 Builder를 지향하는 첫 걸음으로 기존 ViewBuilder를 내부적인 개선으로 모든 SwiftUI 버전에서 사용할 수 있음!
@ContentBuilder는 SwiftUI로 된 앱을 빌드할 때 빌드 성능을 크게 향상시킴.
(참고)