[Live Photos]
라이브 포토는 사진 촬영 직전의 1.5초와 직후의 1.5초의 움직임을 소리까지 합해서 저장할 수 있게 만든 기술입니다. 유저 입장에서는 소히 말하는 움짤을 손쉽게 촬영할 수 있게 되었습니다. 참고로 iPhone 6S, 6S+ 기기에서만 사용할 수 있습니다.
라이브 포토는 PHLivePhoto 객체를 통해 다룰 수 있습니다. 라이브 포토가 들어있는 사용자의 앨범에 접근하기 위해서는 기존과 마찬가지로 PHImageManager 혹은 UIImagePickerController 클래스를 활용하면 됩니다.
iOS9.1에서 사진 관련 추가/변경된 사항은 다음 링크를 참고해주세요.
[Multitasking Enhancements for iPad]
iPad를 위한 멀티태스킹환경이 도입되었습니다. 이제 한 번에 앱을 2개씩 켜놓고 동시에 사용할 수 있게 되었는데요. 12인치나 되는 큰 화면의 아이패드에서 활용하면 편할 것 같은 모드들을 몇 가지 소개하겠습니다.
(1) Slide Over
메인 앱을 사용하면서 서브 앱을 화면 한 쪽에서 작게 볼 수 있는 모드입니다.
(2) Split View
화면을 분할하여 동시에 두 앱을 실행하는 모드입니다. 가운데 구분 막대를 드래그하여 두 앱의 화면 비율을 조절할 수 있습니다. 슬라이드 오버 모드에서 바로 이 모드로 전환이 가능합니다.
(3) PIP(Picture in Picture)
다른 앱을 실행하는 와중에도 동영상 앱의 재생화면을 스크린에 띄워서 계속 볼 수 있습니다.
[3D Touch]
디스플레이에 포함된 센서가 터치의 강도를 탭, 누르기, 세게 누르기 3단계로 나누어 인식할 수 있는 기술입니다. iPhone 6S, 6S+ 기기에서만 활용가능합니다.
(1) Peek & Pop
Peek&Pop은 콘텐츠를 살짝 탭하면 내용을 미리 살펴볼 수 있고, 콘텐츠를 조금 더 강하게 누르면 팝업으로 띄워주는 기능입니다. 지금까지는 메일 목록에서 일련의 메일을 확인하기 위해서는 메일을 하나하나씩 클릭해 들어가서 내용을 보고 다시 백키를 눌러 리스트로 돌아오는 동작을 해야 했습니다. 3D Touch를 이용하면, 이렇게 메일들의 본문에 일일이 들어갔다가 다시 나오는 동작을 반복하는 대신 1번의 3D 터치만으로 메일의 본문을 간단히 확인할 수 있습니다. 즉 사용자가 빠르게 자신이 필요한 정보를 확인할 수 있도록 도와주어 편리성을 높여줍니다.
앱 내의 뷰 컨트롤러와 웹 뷰에서 Peek&Pop을 지원할 수 있습니다. 뷰 컨트롤러에 적용하려면 UIViewControllerPreviewing, UIViewControllerPreviewingDelegate 등 새롭게 추가된 클래스들을 살펴보세요. 또한 WKWebView와 UIWebView 클래스의 allowsLinkPreview 프로퍼티를 YES로 두면 자동으로 웹뷰에서 링크 미리보기 Peek&Pop이 적용됩니다. UITouch 클래스에 새롭게 추가된 프로퍼티들을 통해 터치의 압력 정도를 파악하여 그 강도에 따른 인터랙션을 제공할 수도 있습니다.
(2) Quick Actions
퀵 액션은 홈 화면에서 바로 각 앱들의 자주 사용하는 기능을 실행시킬 수 있도록 해주는 기능입니다. 이제 유저는 메일 앱 아이콘을 누르고 메일 앱을 켜고 메일 작성 버튼을 누르는 과정을 밟지 않아도, 홈 화면에서 한번에 메일 작성 화면으로 갈 수 있게 됩니다.
자신의 앱이 퀵 액션을 지원하게 하고 싶다면 유저에게 제공할 퀵 액션을 정의하세요. 퀵 액션은 static과 dynamic 두 가지 종류로 정의할 수 있습니다. static 퀵 액션은 앱이 설치될 때 퀵 액션이 정의되고 그 후 바뀔 일이 없는 경우에, dynamic 퀵 액션은 사용자의 동작이나 목적에 기반하여 앱의 런타임에서 퀵 액션이 변화되어야 할 경우에 사용하면 좋을 것 같습니다. static 퀵 액션은 Info.plist에 퀵 액션 아이템을 등록하면 됩니다. dynamic 퀵 액션은 코드 내에서 UIApplicationShortcutItem으로 퀵 액션을 정의하고, 필요한 때에 이것을 UIApplication의 shortcutItems 프로퍼티에 셋팅하면 됩니다.
[Search]
아이폰에 저장된 개인정보와 설치한 앱들이 가지고 있는 정보들을 활용한 새로운 검색시스템이 등장했습니다. 인터넷 검색은 외부 검색엔진을 사용할 수 있지만, 폰 내 검색은 민감한 개인정보를 포함하기 때문에 자체 플랫폼이 있어야만 한다는 필요성에서 나온것으로 보입니다. 앱 데이터를 검색한 결과를 선택하면 Deep Link를 통해 앱 안에 검색된 데이터를 보여주는 화면으로 바로 이동할 수 있으며, 검색 결과는 Siri도 접근할 수 있습니다.
기본적인 개념들을 몇 가지 소개합니다.
(1) NSUserActivity
사용자의 Activities을 캡쳐해 놓음으로써, 다른 Device에서도 해당 Activities를 이어서 할 수 있게 하는 클래스입니다.
예를들어, A사용자의 아이폰 사파리 브라우저에서 기사를 보는도중 사파리를 종료 하였더라도, 아이패드에서 사파리를 키면, 중단시점에 기사의 스크롤 위치 그대로 가져와서 보여줄 수 있습니다.
이 클래스를 활용해 사용자의 Activities를 저장해 놓고, Siri 또는 Reminder를 통해 해당 Activities를 검색할 수 있게 됩니다.
(2) Core Spotlight Framework
해당 앱 내에 있는 contents들을 카테고리 별로 indexing 해놓고 searchable하게 설정해 놓으면, 해당 contents들이 사용자의 검색어에 따라 노출되게 됩니다. 검색된 contents를 tap하면 해당 contents가 있는 app내에 navigation point로 이동합니다.
(3) Web markup
app content중 자신의 웹사이트에 추가적으로 제공해야 할 정보가 있다면 web markup을 사용해서 해당 web site로 유도할 수 있습니다.
[App Thinning]
앱스토어와 os에서 앱 설치를 최적화 하는 것으로 사용자 개개인의 기기에 맞게 앱 결과물을 만들어서 제공하는 기술입니다. 이 기술을 통해 앱의 용량 낭비를 줄이고 추후 업데이트에 대한 대응과 함께 빠른 다운로드를 유저에게 제공할 수 있습니다.
(1) Slicing (슬라이싱)
iOS 기기가 다양해져서 비트(32/64), 종류(아이폰/아이패드), 디스플레이(비레티나/레티나/3x레티나), 메모리 별로 필요한 요소가 많아졌습니다. 그래서 유저들은 자신의 기기에서는 사용하지 않는 불필요한 것들까지 다운을 받게 되었습니다. 이것을 해결하기 위해서, 이제 유저가 앱 다운 요청시 앱스토어가 해당 기종에 맞게 최적화된 버전을 사용자에게 제공해줍니다.
일반적으로 이미지의 경우 2x/3x 이미지를 동시에 넣는데, Slicing을 위해서는 Images.xcassets 에 이미지를 넣어서 관리해야만 기기에 맞게 이미지가 선택된다고 하니 주의해주세요.
(2) Bitcode
앱을 중간형태(intermediate representation)로 컴파일해서 앱 스토어에 등록하면 앱스토어에서 알아서 다운로드 시점에 맞게 최적화된 실행 파일을 만들어서 배포를 합니다. ios의 경우는 기본적으로 설정되어 있지만 옵션이고 watchOS에서는 필수입니다. 비트코드를 제공하기 위해서는 앱 번들 내의 모든 앱과 프레임워크가 비트코드를 포함해야 합니다.
설정 방법: 'Build Settings' > 'Build Options' > 'Enable Bitcode'
(3) On-Demand Resources
이미지나 사운드와 같은 리소스에 키워드로 태킹을 하고 그룹화 하여 해당 리소스가 필요한 시점에만 그 자료를 다운받아서 사용하고 불필요한 부분을 삭제하여 전체적으로 앱 용량을 줄이는 방법입니다. 비록 네트워크를 사용하는 단점이 있지만 줄어든 용량의 앱을 빠르게 다운받고 처음 실행시 세팅 시간을 줄여주는 효과를 줍니다. On-Demand Resources에서도 마찬가지로 Slicing을 지원합니다.
[App Transport Security]
iOS9에서는 http 프로토콜 통신을 사용하는 경우에는 예외처리 등록이 필요하고, app to app 인증을 하려면 개별 schmem 등록이 필요합니다.
Apple iOS9 대응관련 레퍼런스
[Contacts and Contacts UI]
기존 Address Book / Address Book UI 프레임워크를 대신할 새로운 주소록 Contacts API가 도입되었습니다. Contacts API를 사용하는 대부분의 앱이 정보를 읽는데만 사용하기 때문에, 이 프레임워크는 read-only usage에 최적화 되어있습니다.
새로운 Contacts 클래스인 CNContact는 thread-safe 하며 NSDictionary와 비슷하게 mutable한 subclass CNMutableContact를 가집니다.
그리고 multi value를 가질 필요가 있는 프로퍼티를 위해 ( ex. 주소(집, 회사), 전화번호(집, 핸드폰)) 복수의 값을 담을 수 있는 CNLabeledValue를 제공합니다.
Contact를 위한 뷰 컨트롤러에는 CNContactPickerViewController, CNContactViewController 등이 있습니다. 이 뷰 컨트롤러들은 Contact를 displaying, editing, selecting, creating 하는 UI 인터페이스를 제공합니다.
(1) Fetching Contacts(CNContactStore)
- user’s contacts database라고 생각하면 된다.
- fetch, save가능
- CNContactStore의 대부분 methods들은 synchronous 하기 때문에 background thread에서 사용하는 걸 추천한다. 필요하다면, fetch된 immutable data들을 main thread로 보낼 수 있다.
- predicates기능을 통한 filtering 가능
- ex)”AppleSeed”라는 이름을 가진 Contats정보를 fetch해오고 싶다. -> CNContact.predicateForContactsMathchingName(“AppleSeed")
- keysToFetch array를 이용해 지정한 key에 해당하는 것들만 Fetch가능
(2) Privacy
- 사용자가 앱내에서 Contact 정보 접근권한을 얻는 도중에는 CNContactStore의 보내지는 모든 메세지는 block처리 된다. 즉, 해당 block으로 인해 mainThread block으로 이어지는 사태를 막기 위해서는
ContactStore의 비동기 메서드인 [CNContactStore requestAccessForEntityType:CNEntityTypeContacts completionHandler:]를 사용하거나 background thread에서의 사용을 권한다.
(3) Unified Contacts
- 다른 계정에 있는 각각의 Contact라 할지라도 동일한 사람을 나타내면, 해당 Contacts들은 자동적으로 linked되어 Unified Contacts가 될 수 있다.(ex. iCloud계정의 Contact 정보 + FaceBook의 Contact 정보 = Unified Contact)
- Unified Contact는 In-memory, temporary view 개념이다. (DB로 따지면 table이 아니라 view 개념)
- Unified Contact는 Unique Identifier를 가지고 있는데 Unified Conatct에 포함된 Contact들의 Indentifier와는 구별된다. 즉, 해당 Unified Contact를 refetch를 하려면 Unified Contact의 Indentifier를 통해 수행해야 한다.
[Keychain]
OS X와 달리 iOS에서는 자신의 Appliction에 속한 Keychain Item들만 접근이 가능합니다. 또한 Keychain에 대한 권리는 해당 앱의 provisioning profile에 의존합니다. 그러므로 앱 버전이 다르더라도 같은 provisioning file을 사용하기를 권장합니다.
keychain은 여러가지 속성의 정보를 포함하고 있습니다. 그 중 password나 private key같은 정보들은 encrypt되어 저장되고, certificates같은 데이터들은 encrypt되지 않은 채 저장됩니다.
키체인에 접근할 때 touch id를 사용할 수 있습니다. (kSecAccessControlTouchIDAny 사용)
앱 비밀번호를 이용한 접근도 가능합니다. (kSecAccessControlApplicationPassword 사용)
또한 오직 touch id로, 또는 오직 앱 비밀번호만으로 접근할 수 있는 고유 데이터를 지정할 수 있습니다. 지문 데이터가 지워지면 데이터가 따라 지워지게 할 수도 있습니다.
[Additional Framework Changes]
앞서 언급한 것들을 제외한 프레임워크의 나머지 변경점들을 소개합니다.
(1) Foundation Framework
on-demand 로딩을 위해 NSBundle API들이 추가되었습니다. on-demand 로딩에 대한 개념과 설명은 [App Thinning] 부분에서 다루고 있으니 해당 부분을 참고해주세요. 추가된 API들의 주요 역할은 특정 리소스의 우선순위를 셋팅하는 것입니다.
전력과 열 관리를 위해 NSProcessInfo API들이 추가되었습니다. NSProcessInfo는 현재 실행중인 프로세스의 정보에 접근하는 것을 도와주는 클래스입니다. 이 클래스를 통하여 전력/열 관리를 제어할 수 있습니다. 예를 들어서, 새로 추가된 LowPowerModeEnabled 프로퍼티를 통해 현재 디바이스의 최소전력모드 활성화 여부를 알 수 있습니다. 이 프로퍼티의 값을 확인하여 개발자는 디바이스가 최소전력모드에 들어가있을 때 앱이 최소한의 동작만 하게 만들 수 있습니다.
(2) MapKit Framework
MapKit framwork에서 다음 사항들이 추가/변경되었습니다.
- 대중교통의 방향과 도착시간을 가져올 수 있게 되었습니다. MKLaunchOptions과 MKDirections 클래스를 활용하세요.
- 3D 플라이오버 뷰를 지원합니다.
- 어노테이션(Annotations)의 커스터마이징 범위가 늘었습니다. MKAnnotationView 클래스의 DetailCalloutAccessoryView 프로퍼티를 활용하세요.
- 검색 결과에 타임존 정보를 제공합니다.
(3) Safari Services Framework
앱 안에서 웹뷰를 띄울 수 있게 해주는 SFSafariViewController가 추가되었습니다. SFSafariViewController는 Safari와 쿠키, 데이터를 공유하며 Safari의 자동완성, 읽기도구 같은 주요 기능들도 사용할 수 있게 해줍니다. 그리고 주소창 옆에 Done 버튼을 제공해주는데, 이 버튼을 누르면 앱의 이전 화면으로 가게 됩니다.
SFSafariViewController는 사파리와 다르게 하나의 페이지를 보여주는 것에 적합합니다. WKWebView나 UIWebView 기반의 브라우저를 통해 웹 컨텐츠를 보여주고 있었다면 SFSafariViewController로 전환하는 것을 고려해보세요. 단순히 웹 컨텐츠를 표시하는 것 뿐이라면 훨씬 편한 것 같습니다.
(4) UIKit Framework
새로 추가된 UIStackView는 위와 같은 레이아웃을 다양한 화면 크기에 대응하여 편하게 구현할 수 있게 도와줍니다.
StackView라는 이름처럼, 서브뷰들을 마치 스택에 쌓는 것처럼 horizontal 정렬, vertical 정렬하여 쌓을 수 있습니다. layout constraint를 사용하지 않아도 가능합니다! 프로퍼티를 설정하는 것만으로 서브뷰의 정렬 방향을 손쉽게 바꿀 수 있고, 서브뷰 중 하나의 히든 속성이 바뀌면 자동으로 눈에 보이는 서브뷰들의 레이아웃을 재구성해줍니다. 이런 과정을 자동으로 해준다고 하니 수직/수평 정렬이 많이 필요한 뷰에서 유용하게 사용해볼 수 있을 것 같습니다.
그 외에도 다음과 같은 점들이 추가/변경되었습니다.
- UILayoutGuide 가 새롭게 추가되었습니다. 화면 크기에 따라 본문 텍스트의 좌우마진을 얼마나 가져야 하는지 자동으로 계산해주는 역할 등을 합니다.
- Peek&Pop, 퀵 액션, 애플와치와의 인터랙션 등을 위해서 UIApplicationDelegate에 새로운 메서드들이 추가되었습니다.
- UIUserNotificationAction에 behavior이라는 프로퍼티가 추가되었습니다. 알림이 도착했을 때 유저에게서 바로 텍스트를 입력받을 수 있도록 해줍니다.
- 모든 UI요소가 right-to-left 형식의 언어에 적합하게 flip 동작을 지원합니다.
[Deprecated APIs]
iOS9에서 Deprecated된 API 중 주요 몇 가지만 소개합니다.
(1) Address Book and Address Book UI frameworks
기존의 주소록 API가 Deprecated되고 새로운 주소록 API가 도입되었습니다. [Contacts and Contacts UI] 부분을 참고해주세요.
(2) NSURLConnection API
NSURLConnection API가 deprecated 되었습니다. init 메서드, 비동기 리퀘스트를 보내는 메서드 등이 deprecated되었는데요. 애플은 NSURLConnection으로 개발된 네트워크 관련 코드를 NSURLSession을 사용하는 코드로 전환할 것을 권장하고 있습니다. 앞으로 새로운 업데이트는 NSURLSession에만 이루어지며, watchOS에서는 NSURLConnection를 아예 지원하지 않습니다. 다행히 전환은 그렇게 어렵지 않다고 합니다. 참고로 iOS 프로젝트에 많이 쓰이고 있는 AFNetworking도 현재는 NSURLConnection을 사용하고 있지만 이후 릴리즈 버전에서는 해당 코드를 없애겠다고 밝혔습니다.
Deprecated 된 모든 API 목록을 보고 싶다면 아래 링크를 참고해주세요.
-출처 : NHN Ent 기술공유 게시판
'IOS > 공통' 카테고리의 다른 글
| About Bundle (0) | 2017.02.14 |
|---|---|
| iOS Architecture (0) | 2016.12.18 |
| UIApplicationMain? (0) | 2016.02.18 |
| 디버깅 (Crash 핸들링) (1) | 2015.11.05 |
| [iOS 9] Search (0) | 2015.11.05 |
