What's new in UIKit

[hyun99999]

Discover the latest updates and improvements to UIKit and learn how to build better iPadOS, iOS, and Mac Catalyst apps. We'll take you through UI refinements, productivity updates, API enhancements, and more. We'll also help you explore improvements to performance, security, and privacy.

[hyun99999]

What's new in UIKit - WWDC22 - Videos - Apple Developer
본 글은 WWDC 를 보고, 번역 및 요약 그리고 실행해보는 스터디 프로젝트의 일환입니다.

UIKit 은 앱을 관통하는 강력한 프레임워크입니다. iOS 16 의 새로운 기능을 지원하기 위해 업데이트했습니다.

생산성을 위한 UI 개선, 컨트롤 개선 사항, API 개선 사항, UIKit 와 SwiftUI 를 함께 사용하는 방법에 대해서 이야기하겠습니다.

1. Productivity Improvements

깔끔하고 눈에 띄는 사용자 인터페이스를 디벨롭하기 위해서 UIKit 에서 다음과 같은 것들을 쉽게하도록 만들었습니다.

• 개선된 navigation bar 와 새로운 title menu 의 기능
• find and replace
• cut, copy, paste 등의 편집 인터렉션 개선

1) navigation bar

먼저, 내비게이션 바를 살펴보겠습니다.

데스크톱 수준의 툴바 기능을 지원하기 위해 업데이트 했습니다. iOS 16의 UIKit은 Browser 와 Editor 를 통해서 문서 기반의 앱을 지원합니다.

• Browser : 웹과 문서 브라우저와 같은 히스토리나 폴더 구조를 이용하여 탐색하기에 적합합니다.
• Editor : 문서 편집을 고려해서 만든 인터페이스입니다.

iOS 16에서는 앱에 bar button items 을 추가할 수 있습니다. 이것들은 navigation bar 의 정가운데에 배치됩니다.

Center Items

menu 에서 “Customize Toolbar” 를 탭하면 item 들을 popup 창에서 드래그하여 재배치 할 수 있습니다. 새로운 configuration 은 계속 유지됩니다.

side-by-side mode 를 실행하여 크기를 맞춰야하는 상황이 생기면 시스템은 자동으로 overflow menu 를 제공합니다.

2) Title Menu

새로운 내비게이션 스타일에서 동작하는 타이틀 메뉴를 추가하여 몇 가지 기능을 지원합니다.

• Duplicate
• Move
• Rename
• export
• print

이런 항목들은 대응하는 delegate 메서드를 적용하여 구현할 수 있습니다.

그리고 title menu 에 커스텀 아이템을 추가할 수도 있습니다.

Mac Catalyst

Mac Catalyst 로 빌드한 앱은 개선된 내비게이션 바를 이용할 수 있습니다. 이는 NSToolbar 와 매끄럽게 통합되며 추가적인 코드가 필요하지 않습니다.

3) Find and replace

iOS 16 은 여러 앱에 걸쳐 텍스트를 편집하는 방법을 도입했습니다.

첫 번째는 새롭게 바뀐 Find and replace 입니다.

개념적으로는 data model objects 로 운영되는 사진이나 캘린더 이벤트와 같은 높은 수준의 in-app search 와 다릅니다. 대신에 find and replace 는 텍스트에 맞게 설계되었습니다.

UITextView 와 WKWebView 와 같은 built-in UIKit 뷰에서 flag 를 설정하면 이 기능을 활성화할 수 있습니다.

추가적으로 이 기능을 적용한 여러 뷰와 문서에서 매끄럽게 작동합니다.

4) Editing Interactions

다음은 대규모 업그레이드가 된 edit menu 입니다.

이제 input method 에 따라서 다르게 보입니다. touch interaction 에서는 훨씬 상호작용적으로 재디자인된 menu 를 갖게 되었습니다.

포인터를 사용할 때는 모든 기능이 들어있는 context menu 가 등장합니다. 이러한 두 경험을 매끄럽게 제공하기 위해서 UIEditMenuInteraction 을 도입하여 이제는 deprecated 된 UIMenuController 를 대체합니다.

또한, text view 의 메뉴에 actions 을 삽입하는 새로운 API 도 생겼습니다. 아래의 세션을 통해서 새로운 edit menu 의 자세한 사항과 커스텀 뷰에서 find 인터렉션을 적용하는 법을 알아볼 수 있습니다.

Additionally

제가 다루고 싶은 시각적인 UI 업데이트 사항이 있습니다.

iOS 16에서 slide over 모드의 사이드바는 추가 코드가 없어도 활성화 됩니다. 이를 달성하기 위해서 UIKit 은 몇 가지 private views 를 관리합니다.

다음은 지금까지 알아보았던 UIKit 에서 새롭게 제공하는 기능들입니다.

오늘의 세션에서는 기본적인 내용만 다루었습니다. 더 많이 알아보기 위해서 세션들을 통해 확인할 수 있습니다.

2. Control enhancements

이제 추가한 두 가지 새로운 control 을 소개하고, UIPageControl 의 개선 사항을 논의하겠습니다.

1) UICanlendarView

이제 UIDatePicker 의 inline calendar style 을 모든 기능이 있는 독립적인 요소로 UICalendarview 의 형태로 사용할 수 있습니다.

UICalendarView 는 다양한 타입의 선택 동작을 지원합니다. 선택적인 단일 날짜나 여러 날짜의 선택이 가능합니다. 사용 가능한 날짜 범위 설정은 물론 선택 범위에서 일부 날짜를 제외하는 기능도 있습니다. 또한, 각 날짜를 annotate 할 수도 있습니다.(= 장식할 수도 있습니다.)

UICalendarView 와 UIDatePicker 의 중요한 차이점 한 개는 UICalendarView 가 날짜를 표현할 때는 NSDate 가 아닌 NSDateComponents 로 나타냅니다. NSDate 와 달리 NSDateComponents 는 특정 날짜를 더 정확하게 나타내지만 NSDate 는 시간의 한 포인트를 나타냅니다.

NSDateComponents 는 매우 유연하므로 어떤 NSCalendar 를 사용하는지 명확하게 명시해야 합니다.

현재 캘린더 타입에 관해 가정하면 안 됩니다. 그레고리력으로 달력을 설정해야한다면 gregorian 이라고 명시해야 합니다.

Configure calendar view

이전에 보았던 캘린더 뷰처럼 설정하려면 먼저 Calendar view 를 생성하고 delegate 를 설정합니다. 캘린더를 Gregorian NScalendar 로 정하기 위해서 calendarView 의 calendar 프로퍼티를 설정해줍니다.

다음은 multi-date 설정하기 위해서 UICalendarSelectionMultiDate 객체를 만들고, selectedDates 프로퍼티를 여러분의 data model 에 있는 기존 날짜에 설정하여(=myDatabase.selectedDates()) 캘린더 뷰에 나타나게 할 수 있습니다.

그리고 selectionBehavior 에 selection object 를 설정하세요.

캘린더의 개별 날짜의 선택을 막기 위해서 calendar 의 selection’s delegate 로 부터 multiDateSelection:canSelectDate: 메서드를 적용하여 선택할 수 있는 날짜를 제어할 수 있습니다.

선택할 수 없는 날짜는 calendar view 에서 회색으로 표시될 것입니다.

(hasAvailabilities(for:) 메서드는 DateComponents 매개변수가 선택할 수 있는지 제어합니다.)

Configure decorations

개별 날짜에 decorations 을 달고 싶다면 calendar delegate 에서 calendarView:decorationForDateComponents: 를 적용하면 됩니다.

(eventType(on:)메서드는 DateComponents 매개변수가 어떤 이벤트 타입인지 제어합니다.)

• decorations 이 없으면 nil 을 반환합니다.
• default 를 반환하면 기본값인 회색 원이 설정됩니다.
• 색상을 커스텀하여 image 장식도 생성할 수 있습니다.
• 필요하다면 커스텀 뷰를 반환할 수도 있습니다.

커스텀 뷰 decoration 은 interaction 을 허용하지 않으며 공간에 고정되어 있다는 점을 주의해 주세요.

2) UIPageControl

UIPageControl 도 개선되었습니다.

현재 페이지에 커스텀 indicator 이미지를 추가하여 페이지의 선택 여부에 따른 다른 이미지를 선택할 수 있습니다. 이제 page control 의 direction(이동방향) 이나 orientation(고정된 상황에서의 방위)을 완벽하게 커스텀할 수 있게 되었습니다.

여기 vertical page control 을 설정하는 예시가 있습니다.

현재와 현재가 아닌 페이지에서 인디케이터가 바뀝니다. page control 의 direction 을 top to bottom 으로 설정하면 끝입니다.

3) UIPasteControl

Apple 은 사용자 개인 정보와 보안을 지키려고 노력합니다. iOS 15에서는 앱이 프로그래밍적으로 system 이 제공하는 Pste interfasces 를 통하지 않고 pasteboard 에 접근하면 pasteboard 에 접근했다는 배너가 나타났습니다.

iOS 16 에서는 시스템 동작이 변경되었습니다. 이제는 배너 대신 pasteboard 의 사용 허가를 묻는 알림창이 나타납니다.

사용자가 system 의 paste interface 를 사용하면 pasteboard 에 대한 암묵적인 액세스를 제공하여 alert 창을 피할 수 있습니다.

(paste interface : edit menu 등에서 copy 할 때 alert 창 피함. pasteboard : 제스처(손가락 세 개 모으기)를 통해서 복사. 이때는 배너 등장)

만약, cutom paste controls 가 있다면 새로운 UIPasteControl 로 대체할 수 있습니다. 이것은 UIButton 와 모습과 동작이 비슷합니다.

지금까지 UICalendarView 와 개선된 UIPageControl 보안 중심의 UIPasteControl 을 알아봤습니다.

이제, API 개선 사항을 짚어드리겠습니다.

3. API refinements

1)Customizing Sheets

iOS 15에서는 sheet 에 detent 를 추가하여 유연하고 역동적인 UI 를 구축할 수 있었습니다. iOS 16에서는 커스텀 detents 를 지원하여 sheet 를 마음대로 조절할 수 있습니다.

Detent?

이 기능을 활용하려면 .custom detent 를 사용하여 관련된 block 에서 시트의 높이를 지정할 수 있습니다.

constant value 를 반환해도 되고, detent 의 최대 높이의 비율을 반환해도 됩니다.

@MainActor static func custom(
    identifier: UISheetPresentationController.Detent.Identifier? = nil,
    resolver: @escaping (_ context: UISheetPresentationControllerDetentResolutionContext) -> CGFloat?
) -> UISheetPresentationController.Detent

다른 API 를 참조해야 한다면 custom detent 에 식별자를 줄 수도 있습니다.

예를 들어 식별자를 사용하여 custom detent 에서 dimming 을 비활성화할 수 있습니다.

(기본값은 nil 이고, 설정한 detent 보다 큰 detent 에만 dimming view 를 추가하려면 이 프로퍼티를 설정하면 됩니다.)

custom block 으로부터 반환하는 값은 bottom safe area inset 을 고려하지 않습니다. floating 과 edge-attached sheets 에서도 동일하게 계산됩니다.

위의 설정에 관해서는 해당 세션을 참고하면 됩니다.

2) SF Symbool

SF Symbol 에서도 새로운 기능이 있습니다. sybol 은 4가지 랜더링 모드를 지원합니다.

• Monochrome, Multicolor, Hierarchical, Palette

UIKit 은 기본적으로 Monochrome 을 지원합니다. iOS 16에서 UIKit 은 symbol 을 렌더링할 때 렌더링 모드가 지정되지 않은 경우 모노크롬이 아닌 모드를 사용할 수 있습니다.

iOS 15에서는 렌더링 모드를 지정하지 않았을 때 모노크롬 렌더링을 사용했습니다. iOS 16에서는 이런 symbol 들의 기본값은 gierarchical rendaring 입니다.

일반적으로 심벌의 기본적인 렌더링 모드는 심벌을 표시하는 선호 방식입니다. 그래서 위의 경우에는 기본값으로 gierarchical rendaring 을 허용합니다. 하지만, monochrome rendering 을 명시적으로 요청할때는

UIImage.SymbolConfiguration.preferringMonochorme()

을 사용합니다.

UIKit 은 variable symbol 지원하면서 0과 1사이의 값에 따라심벌의 변화를 나타낼 수 있습니다. 현재 볼륨의 레벨을 심벌로 표현한다고 해보겠습니다. 앱은 speaker.3.wave.fill 심벌을 사용할 수 있는데 variable rendering 을 지원하도록 업데이트 되었습니다.

0일때는 speaker wave 를 흐리게하여 가장 낮은 볼륨 레벨을 표현합니다. 값이 1로 증가할수록 wave 가 점점 채워지면서 더 높은 볼륨 레벨을 표현합니다.

만약 심벌이 variable rendering 을 지원한다면, 앱들은 0과 1 사이의 값을 반영한 심벌을 앱에서 요청할 수 있습니다. variable symbols 를 사용하면 직관적입니다.

일반적인 non-variable symbol 는 UIImage 에 있는 SF Symbol API 로 얻을 수 있습니다.

variable 값을 가지는 심벌의 버전을 얻기 위해서 variableValue 파라미터를 간단하게 추가할 수 있습니다.

variable rendering 과 다른 렌더링 모드를 섞을 수도 있습니다. 예를 들어 palette 모드로 심벌을 꾸밀 수 있습니다.

많은 시스템 심벌들이 이제 variable rendering 을 지원하며 앱들은 custom symbol 을 업데이트하며 다양성을 지원할 수도 있습니다.

custom variable symbol 을 만드는 법이 궁금하시면 위의 세션을 통해 알아볼 수 있습니다.

3) Swift Concurrency and Sendable

UIKit 을 새로운 Swift concurrency 기능에 맞춰서 개선했는데 UIImage 와 UIColor 와 같은 immutable(불변) types 을 Sendable 을 준수하는 것을 포함하여 MainActor 와 custom Actor 사이에서 컴파일러의 경고 없이 전송이 가능합니다.

예를 들어, Processor 라는 costom actor 와 ImageViewer 라는 뷰 컨트롤러가 있는데 이는 잠재적으로 MainActor 에 바운딩 되어 있습니다.

sendImageForProcessing 메서드 안에서 ImageViewer 가 Processor actor 에 처리를 위해서 이미지를 보내서 반짝이나 무지개 등을 추가할 수 있게 됩니다.

UIImage 가 immutable type 이므로 안전하며 Processor 가 새로운 복사본을 만들어서 반짝이나 무지개 등을 추가할 수 있습니다.

original image 에 대한 참조하는 모든 코드는 이런 수정 사항을 나타내지 않으며 공유 상태는 불안전하게 변화되지 않습니다.

반면에 UIBezierPath 는 mutable 이기 때문에 Sendable 할 수 없습니다. 이전에는 documentation 로만 표현할 수 있었던 것은 컴파일러로 확인할 수 있으면 얼마나 멋질까요?

• iOS 15

• iOS 16

컴파일러가 확인할 수 있게 되었다.

Sendable 과 Swift Concurrency 에 관해 더 알고 싶다면 아래의 세션을 통해 알 수 있습니다.

3) Stage Manager

iOS 16은 external displays 를 위해 강력한 기능을 지원합니다. 또한, 이 기능을 얻기 위해 앱을 업데이트하지 않아도 됩니다. UIScreen API 를 사용하는 경우는 제외합니다.

이제 더이상 앱에 main screen 이 있다고 가정하지 않아도 됩니다. 대신 더 trait collection 과 UIScene API 들과 같은 구체적은 API 들을 따르며 원하는 정보를 얻을 수 있습니다. 만약 여러분의 앱이 아직 UIScene 을 사용하지 않고 있다면, 업그레이드를 하지 않을 이유가 없고 multiple windows 를 지원하세요.

4) Self-resizing cells

UICollectionView 와 UITableView 를 위해 셀을 self resizing 것이 크게 업데이트 되었습니다. 이제 셀들이 알아서 크기를 바꿉니다! iOS 16 에서는 cell 의 콘텐츠가 변경될 때 자동으로 새로운 콘텐츠에 맞춰서 셀 크기를 조정하게 됩니다.

이 동작은 기본적으로 활성화 되어 있고, UICollectionView 와 UITableView 는 seflSizingInvalidation 프로퍼티가 추가되어 이 새로운 기능을 제어할 수 있게 되었습니다.

원리를 알려 드리겠습니다.

selfSizingInvalidation 이 활성화되어 있을 때 셀은 포함된 collection 또는 table view 통하여 크기 조정을 요청할 수 있습니다.

UIListContentConfiguration 으로 셀을 설정한다면, 셀의 configuration 이 바뀔 때마다 자동으로 무효처리가 됩니다.

다른 경우에는 셀이나 셀의 contentView 의 invalidateIntrinsicContentSize 메서드를 호출하여 조정할 수 있습니다.

UIListContentConfiguration 의 경우는 자동으로 무효처리가 되지만 다른 경우에는 invalidateIntrinsicContentSize 를 호출하여 intrinsic content size 즉, 고유 크기를 무효화 해야 합니다. 이를 통해 constraint-based layout system 은 다음 layout pass 에서 새로운 intrinsic content size 를 가져갈 수 있습니다.

고유의 크기를 무효화하고 다음 레이아웃을 반영할 때 새로운 고유 크기를 반영하는 원리입니다.

---

기본적으로 cell 들은 애니메이션과 함께 resize 됩니다. 하지만, invalidateIntrinsicContentSize 를 호출하는 것을 UIView.performWithoutAnimation 블럭 안에 래핑하면 애니메이션이 나오지 않습니다.

이처럼 UICollectionView 와 UITableView 는 지능적으로 셀의 크기 무효화를 최적의 시기에 하나의 업데이트로 수행하도록 통합합니다.

만약, Auto Layout 을 셀에서 사용한다면 enabledIncludingConstraints 를 선택하므로써 더 포괄적인 행위로 옵트인 할 수 있습니다.

이것은 contentView 내에서 오토레이아웃의 변화를 감지할 때 자동으로 invalidateIntrinsicContentSize 를 스스로 호출하여 소속된 collection 또는 table view 가 필요에 따라 resize 할 수 있습니다.

이를 통해 아주 쉽게 콘텐츠나 레이아웃의 업데이트에 대해서 자동으로 셀의 크기를 조정할 수 있습니다.

4. UIKit and SwiftUI

UIKit 은 강력하고 유연합니다. SwiftUI 를 사용하면 UI 를 구현할 때 더 풍성하게 표현할 수 있습니다. 같은 앱에서 두 개의 프레임워크를 쉽게 적용할 수 있도록 하였습니다.

UIHostingConfiguration

iOS 16에서 SwiftUI 를 사용하여 collection 과 table veiw 를 위한 새로운 방식으로 셀을 만들 수 있습니다.

이렇게 가능하도록 하는 것은 새로운 content configuration type 인 UIHostingConfiguration 덕분입니다.

위의 코드 한 줄이면 SwiftUI 를 셀 안에서 바로 작성할 수 있습니다. 추가 뷰나 뷰 컨트롤러는 필요 없습니다.

아래는 간단한 SwiftUI 로 작성한 custom cell 입니다.

여러분들의 앱에 SwiftUI 를 통합하는 정말 멋진 방법일뿐 아니라 SwiftUI 의 풍부한 표현을 통해 UIKit 에서 커스텀 셀을 만드는 것이 무엇보다 효율적으로 되었습니다. 더 알아보고 싶다면 위의 세션을 통해 알아볼 수 있습니다.

A Couple of Smal but Important Changes

여러분들이 알둬야할 작지만 중요한 변경사항이 있습니다!

• 사용자가 추적되는 것을 방지하기 위해서 UIDevice.name 은 이제 유저의 커스텀 기기 이름이 아닌 모델 이름을 반환합니다. 커스텀된 이름을 사용하기 위해서는 이제 entitlement(권한) 를 요구합니다.
• UIDevice.orientation 설정은 이제 지원하지 않습니다. UIViewController API 인 preferredInterfaceOrientation 으로 인터페이스의 의도된 방향을 지정할 수 있습니다.