iOS SDK의 새로운 API가 앱 발견과 마케팅에 실제로 도움이 되는건 드물죠. 그래서, 나에게 iOS 9에서 가장 흥미로운 기능은 새로운 검색 API 입니다.

이러한 기능은 Handoff 기능을 지원하기 위해 iOS 8에서 소개가 된 NSUserActivity 에서 구축합니다. iOS 9 Spotlight 검색에 표시하기 위해 iOS 9에 대한 추가 메타 데이터 및 URL의 딥 링크 앱에 추가할 수 있으며, 사용자는 앱을 출시할 수 있을 뿐만 아니라 내용을 볼 수 있게 합니다.

이건 즉시 기존 사용자에게 유익하지만, Apple은 이러한 결과를 중심으로 인텍스를 합니다. 아직 당신의 앱을 설치하지 않은 사용자가 Spotlight를 사용할 때, 당신의 앱은 추천으로 표시됩니다. 무료 마케팅? 그런거죠.

여기서 흥미로운 것은 당신의 기존 사용자가 정기적으로 앱을 사용하여 당신이 제공하는 검색 결과와 상호작용을 하고 있을 때 Apple이 새로운 사용자에게 앱을 추천하는 것 입니다. 이것은 곧 스팸인 앱을 차단하고 진정한 가치를 제공하는 것에 초점을 맞추고 있습니다. 그리고 App Store에 아주 좋은 것입니다.

빠른 팁보다 훨신 좋은 것이 있습니다. 그래서 이러한 API의 통찰력을 높이고, 이를 구현하기 위해 WWDC에서 Session 709 — Introducing Search APIs를 보는 것이 좋을 것입니다. iOS가 앱의 링크를 제대로 볼 수 있는지를 확인하기 위해 당신이 웹 사이트가 유효한지 검사하는 편리한 도구가 있습니다.

iPhone 6s와 iPhone 6s Plus에 관한 재미있는 발표해 개발자는 드디어 자신의 앱이 3D 터치를 사용할 수 있는 장점을 얻을 수 있으며, UI 상호 작용에 완전히 새로운 차원을 추가할 수 있습니다.

Apple의 예상대로, 3D터치는 간단하게 기초적인 수준에서 UITouch의 새로운 속성으로 매우 간단한 API를 통해 개발자를 위해 공개되었습니다.

override func touchesBegan(touches: Set<UITouch>, withEvent event: UIEvent?) {
     guard let touch = touches.first else { return }
     if traitCollection.forceTouchCapability == .Available {
        println("Touch pressure is \(touch.force), maximum possible force is \(touch.maximumPossibleForce)")
     }
}

이 새로운 API는 앱의 새로운 기능에 대한 엄청난 잠재력을 해방합니다. 예를 들어, 게임에 대한 추가 제어 옵션과 드로잉 앱으로 세분화 된 컨트롤 또는 우리가 초기 iOS 디바이스때 부터 사용하는 탭&홀드 패러다임 보다 더 좋습니다.

UITouch Api 이외에, Apple은 UIPreviewAction와UIApplicationShortcutItem라는 앱에 3D터치 기능을 추가하기 위해 두 개의 새로운 클래스 세트를 제공하고 왔습니다.

사용자가 UI 요소를 3D 터치할 때, UIPreviewAction 를 사용하면, 개발자는 곧 새로운’미리보기’ 오버레이에 컨텐츠를 표시할 수 있습니다. 이건 뷰 컨트롤러의 전환을 필요로 하지 않고 이메일이나 사진, 웹 사이트 등을 실시간 확인하는 것을 실현하는 좋은 방법입니다.

UIApplicationShortcutItem 개체는 iOS 홈 스크린에서 멋진 새로운 기능을 가능하게 합니다. 앱 아이콘을 3D 터치로 응용하면, 선택이 늘어선 시트가 나타나 사용자는 앱의 특정 섹션에 신속하게 이동하거나 앱에서 작업을 수행 할 수 있습니다.

정리하자면, 3D 터치의 발표는 iOS 디바이스의 새로운 상호 작용의 패러다임을 해줌으로써 앞으로 개발되는 iOS 앱에서 새로운 세대의 혁신을 가능하게 할 것입니다. 샘플 코드 및 3D 터치 자체의 더 기본적인 정보는 Apple Developer 사이트의 3D Touch page에서 확인할 수 있습니다. Good luck!

iOS 9.0과 OS X 10.11의 새로운 점은 `UILayoutGuide와 NSLayloutGuide 클래스입니다. 이것들을 사용함으로써 본질적이지 않은 더미 뷰를 생성하지 않고 Auto Layout의 제약에 관련 있던 “View-like” 객체를 생성 할 수 있습니다. 예를 들어, 비어있는 뷰를 생성하고 그 크기 등을 제한하는 대신 이러한 새로운 클래스를 사용할 수 있습니다.

// Create the layout guides.
let layoutGuideA = UILayoutGuide()
let layoutGuideB = UILayoutGuide()

// Add them to the view.
let view: UIView = ...
view.addLayoutGuide(layoutGuideA)
view.addLayoutGuide(layoutGuideB)

// Add constraints using them.
layoutGuideA.heightAnchor.constraintEqualToAnchor(layoutGuideB.heightAnchor).active = true

// You can even set their identifiers...
layoutGuideA.identifier = "layoutGuideA"
layoutGuideB.identifier = "layoutGuideB"

// ...and get their calculated frames (valid once the owning view has been laid out)
print("layoutGuideA.layoutFrame -> \(layoutGuideA.layoutFrame)")

iOS 9에서 도입이 된 NSLayoutAnchor API는 제한 조건의 설명을 정리할 뿐만 아니라 정적 타입 검사를 통해 제약의 정확성에 대한 추가 보장합니다. 예를 들어, 예전 NSLayoutConstraint API를 사용하여 만든 이 제약을 생각해봅시다.

NSLayoutConstraint *constraint =
    [NSLayoutConstraint constraintWithItem:view1
                                 attribute:NSLayoutAttributeLeading
                                 relatedBy:NSLayoutRelationEqual
                                    toItem:view2
                                 attribute:NSLayoutAttributeTop
                                multiplier:1.0
                                  constant:0.0];

Y축 (top)의 특성에 X축 (leading)의 속성을 제약하고 있기 때문에 이러한 제한은 무효입니다. 그러나 이것은 어떠한 경고도 없이 컴파일되고 실행되며, 조용히 실패됩니다. 그리고 레이아웃을 Undefined 상태로 하여 디버깅은 매우 어렵습니다. 수십 (또는 수백 수천..)중 하나의 제약이 잘못된 것이 로그에 남지 않습니다.

NSLayoutAnchor 은 Swift와 Objective-C 모두에서 Generics의 힘을 활용하여 이 문제를 해결합니다. UIView 의 anchor accessors은 NSLayoutAnchor에서 상속된 형태 정보를 메소드에 추가하고 NSLayoutAnchor의 서브 클래스를 구체화합니다. 이 Anchor의 형태는 각각 동일한 형식의 다른 Anchor에 제한되는 것이 가능하여, X축, Y축 및 크기 (width/height)를 위한 다른 NSLayoutAnchor의 서브클래스가 있습니다. API는 유효한 제약을 만들기 위한 규칙 적용을 위해 타입 검사기를 사용하여 NSLayoutAnchor의 메소드 Anchor 매개 변수를 수신기와 같은 제네릭 타입에 제약합니다.

이전 예제로 돌아가보면, 여기에서는 동일한 제약이 NSLayoutAnchor API를 사용하여 선언이 되어 있습니다.

NSLayoutConstraint *constraint =
    [view1.leadingAnchor constraintEqualToAnchor:view2.topAnchor];

이전 API를 사용하는 것보다 훨씬 더 읽기 쉬울뿐만 아니라, 컴파일러는 당신이 다른 형태의 Anchor를 사용하여 제약 조건을 생성할 수 없는 것을 알고 있기 때문에 컴파일러의 경고 “Incompatible pointer type”을 쏟아줍니다.

자세한 내용은 NSLayoutAnchor 문서를 참조하세요.

Swift와 Objective-C Generics에 대해 이 글을 쓰고 있는 시점에서 Xcode 7 beta 6와 Objective-C generics를 사용하여 Swift애 정확하게 브릿지는 할 수 없습니다. 만약에 이 API를 Swift에서 사용하는 경우에 이 Tips에서 언급된 추가의 형태가 적용되지 않는다는 것입니다. 하지만 Objective-C를 사용하는 경우에는 Joe Groff가 증명하고 있는 것 처럼 정확하게 움직입니다.

나의 iOS9의 Tips은 iOS7을 그롭하고 내가 좋아하는 UIAlertController (iOS 8+)을 사용하는데 있습니다. 그것은 뷰 컨트롤러뿐만 아니라 경고와 액션 시트와 레이아웃을 생각할 때 가장 좋은 방법입니다. UIStackView (iOS 9+)의 표시를 제공합니다. 당신이 아직 체험을 한 적이 없으면 꼭 도전해보세요. 이건 너무 멋집니다. 이러한 이전 iOS 버전에 적용한 (PSTAlertController와 TZStackView)라는 오픈 소스 라이브러리도 있으므로 이것들을 사용하면 매우 가치가 있고, iOS 7과 iOS 8을 버릴 준비가 되어 있다면 UIKit 버전으로 스와핑하면 된다.

Apple은 iOS 9에서 App Transport Security 를 발표했다. 이것은 모든 앱이 기본적으로 HTTPS를 사용하는 것을 요구하는 것이다. 모든 자신이 HTTPS를 통해 제공되는 것은 아니기 때문에, Apple은 ATS를 부분적으로 또는 전체적으로 비활성화하는 방법도 제공하고 있습니다.

만약에 당신의 앱이 임의의 URL (예 UIWebView)를 로드가 필요한 경우 NSAllowsArbitraryLoads 키를 Yes로 설정하면 아마도 ATS를 전체적으로 비활성화 하는 것일거다. 이것은 문제가 되지는 않지만 ATS를 전체적으로 해제하고, 중요한 도메인을 위해 부분적으로 ATS를 활성화하는 것이 좋다. 그것은 NSExceptionDomains 키를 설정하여 수행 할 수 있다. 예를 들어, 이것은 WorkFlow의 info.plist의 일부입니다.

우리가 HTTP를 통해 사용자의 파일 다운로드를 지원하고 있는 것을 알 수 있다고 생각합시다. 그러나 workflow.is(workflow가 사용하는 모든 API의 도메인)에 연결할 때, HTTPS를 필요로합니다.

또한 특별히 주의해야할 것은 ATS가 각각의 번들에 적용이 된다는 것이다. 당신은 ATS 딕셔너리를 기본 앱의 Info.plist뿐만 아니라 당신의 확장의 Info.plist 파일에 추가해야합니다.

당신은 새로운 검색 기능을 많이 구현할 수 있습니다. 검색은 향후에 매우 중요한 것입니다. 그리고 iOS 9는 단지 시작일 뿐입니다. 가능한 빨리 앱에 NSUserActivity 지원을 추가하는 것이 좋습니다.

정말 믿을 수 없을 정도이며 단도직입적으로 당신이 개발이 완료되면 앱은 Handroff와 새로운 proactive 프레임워크를 모두 지원합니다. 만약 당신의 앱이 뭔가 검색 가능한 컨텐츠를 가지고 있다면 당신은 확실히 새롭고 굉장한 Core Spotlight 프레임워크를 활용하여 어떻게 그 모든 것을 인덱싱하는지를 프레임워크에 전달합니다. 앱에 연관된 모든 Web 컨템프가 iOS 9의 새로운 검색 결과보기 용으로 최적화되고 있는지를 확인할 필요가 있으며, Apple은 몇 가지 간단한 메타 태크가 어떻게 도움을 주는지 좋은 가이드를 소개하고 있습니다.

사용자가 무엇을 하고 있는지, 그리고 어떤 컨텐츠를 그들이 만들어 상호 작용하고 있는지를 시스템이 알면 알수록 더 지능적인 제안이나 옵션을 제공합니다.

iOS의 공유 코드 기반에서 작업하는 사람은 아무도 이 Storyboard 파일에서 충돌이 발생하여 종종 IB에서의 모든 변경을 수동으로 다시 하는 것을 경험하고 있습니다. 이것은 여러 팀에게 공동으로 Storyboard의 개발을 포기하고 여러가지 Source control shingle를 구현하는 것처럼 매우 힘든 작업입니다.

만약에 불행하게도 대응책이 없는 경우에 병합 충돌을 최소화 하기 위한 가장 좋은 방법은 몇 가지 작은 Storyboard로 분할 하는 것입니다. 지금까지는 Storyboard에 걸쳐 화면 전환이 필요한 경우 코드에서 구현해야했지만, Xcode 7과 iOS 9가 있으면 StoruBoard Reference를 통해 일반 Segue를 사용하여 작업을 수행 할 수 있습니다. 단일 storyboard 네비게이션의 모든 이점을 가지고 간단한 병합을 위해 파일을 분할하게 됩니다.

하나의 스토리보드를 분할하는 가장 빠르고 쉬운 방법은 축소입니다. 관련 장면의 그룹을 Shift + 선택을 하고 ‘Editor’에서 ‘Refactor to StoryBoard …‘를 선택합니다. (예, 스토리보드 리팩토링이 가능합니다. Swift는 아직 불가능 합니다..). 그러나 이 방법은 모든 장면에 스토리보드 Reference를 남겨두고 필요에 따라 외형이 좋지 않은 Storyboard ID를 자동으로 생셩하기 때문에 개인적으로 나는 ‘File’에서 ‘Duplicate …‘을 선택하고 복제에서 추가 장면만 삭제하는 방법을 사용합니다.

만약 이미 여러 스토리보드를 가지고 있다면, 축하합니다! 이제 몇 줄의 코드를 제거하면 됩니다. object 라이브러리에서 스토리보드 Reference에 끌어 Segue를 설정하고 Delete 키를 두드리고 manual navigation code 삭제하세요.

나는 iOS 9을 깊게 보지는 않았지만, Watch OS 2 관련 개발에 참여했습니다. 만약 Apple Watch 앱을 개발하고 있다면, 나는 새로운 Watch Connectivity 프레임워크를 사용하여 처음부터 코드를 작성하는 것을 권장합니다. watchOS 2는 전혀 다릅니다. 이전의 WatchKit extension 보다 훨씬 강력합니다. 이것은 미래입니다. 그래서 watch를 watchkit 확장으로 유지하는 것은 단지 자신의 기술적 부채를 늘리는 것 뿐입니다.

또한 Complication를 당신의 watch 앱에 추가하는 것을 고려하세요. Apple Watch에서 사용하는 계층 구조는 Notifications, Glances, 앱입니다. future #1은 Complications입니다. 상상해보세요. 사용자가 손목을 들때마다 당신의 앱이 동작한 다는 것을!

시작하려면 아래의 리소스를 확인해 보세요.

• WWDC 2015 Video: Introducing Watch Connectivity
• WWDC 2015 Video: Creating Complications with ClockKit
• watchOS 2 Tutorials from Kristina Thai
• Getting Data to Your watchOS 2 App

만약에 당신이 나를 좋아한다면, 당신은 코드의 검증 로직을 구성하는 데 Early Exit을 사용할 것 입니다. Early Exit는 처음부터 Swift로 가능했지만, 몇 가지 주의 사항이 있었습니다. 첫번째, 그들은 당신이 원하는 조건이 아니라 원하지 않는 조건 (eg IF variable is nil)에 대해 체크해야합니다. 그러나 더 중요한 것은 자주있는 경우라고 생각합니다만, 만약 변수가 nil 시에는 처리를 종료하고 그렇지 않을 때는 계속하는 경우, 그 값을 사용하여 처리를 계속하기 위해서는 Early Exit 에서 더욱 그 변수를 강제로 풀어야합니다.

Swift 2에서는 Swift 팀은 Early Exit에서 우리를 도와 줄 새로운 키워드 guard 를 제공했습니다. guard 는 위의 문제를 모두 해결합니다. 좀 상상해보세요. 당신은 게임을 만들고 있습니다. 그리고 그 게임 개발자는 콜백을 분리하는데 매우 게으르기 때문에 모든 입력의 변경은 하나의 콜백 함수를 통해 처리됩니다.

func gameController(gameController: GameControllerType, didActivateInput input: InputType?)

입력의 비활성화될 때, 두 번째 콜백을 갖는 것은 좋지만, 이것은 guard 가 유용하게 밝히고 있습니다. 이 선택적 인수 input이 nil 이 아닐 때 버튼을 누를 때 게임은 반응해야합니다. 버튼이 이미 밀리지 않는 것을 알리기 위해 인수 input은 nil입니다. 만약 우리가 버튼이 눌려 있는지에 대해서만 주의를 하는 경우 Swift 1 다음 Early Exit를 사용하여 실현 할 수 있습니다.

func gameController(gameController: GameControllerType, didActivateInput input: InputType?)
{
    if input == nil
    {
        return
    }

    self.performExampleMethodWithNonOptionalInput(input!)
}

우리는 취급하고 싶지 않은 사건에 대해 입력을 비교하고 있다는 것을 깨닫습니다. 이 경우에는 그것이 nil 인지 여부입니다. 그렇지만 더 중요한 것은 인수 input은 선택적이며, 우리는 그것이 nil이 아닌 것으로 알고있음에도 불구하고 후 처리로 그 값을 강제로 풀어야 한다는 것입니다. Swift 2는 더 좋아지고 있습니다.

func gameController(gameController: GameControllerType, didActivateInput input: InputType?)
{
    guard let unwrappedInput = input else { return }
    // in development, I call the unwrapped variable the same name
    // as the variable. However, unwrappedInput demonstrates this better.
    self.performExampleMethodWithNonOptionalInput(unwrappedInput)
}

이처럼 인수 input이 nil이 아니라는 조건을 “guard”하고 unwarappedInput에 대입하고 그렇지 않으면 return합니다. 자, unwarappedInput은 필수 사항입니다. 없으면 그대로 사용할 수 있으며, 모두가 행복합니다. 이렇게 ‘guard’는 iOS 9 코드를 깨끗하게 오류를 일으켜 어렵게 할 수 있습니다.

내 프로젝트는 실제로 대부분의 사람들과 조금 다릅니다. 저는 Mac에서 로봇 제어 소프트웨어를 사용하고 있습니다. iOS 9 / Swift 2 / El Capitan 의 릴리즈를 위해 우리가 했던 가장 큰 준비는 Swift 2에 대한 오류 핸들링의 업데이트 입니다. Swift 1이 출시되었을 때 우리는 NSError 문제가 많이 있었기 때문에 자신의 오류 처리 방법을 쓰고 내장했습니다.

하드웨어 개발을 시작한지 오류 핸들링은 우리의 소프트웨어의 정말 중요한 부분입니다. 만약 제대로 유료를 예측하거나 처리할 수 없는 경우는 많은 물리적인 손상을 일으키기 때문입니다. 물리적 손상이 많이 듭니다. 그래서 제가 iOS 9 Tips 를 소개한다면, 당신은 오류 처리에 익숙하게 되기 위해 Swift를 사용하는 경우, 나는 그것이 재미도 화려하지도 않지만 우리가 할 것입니다. 단위 테스트와 같은 것이라고 알고 있습니다. 라고 말하고 싶습니다. 그렇지만 우리는 외부 세계를 통제하지 않으면, 일이 잘못 될 때 어떻게 당신의 애플리케이션을 반응시키고 싶은지를 생각하는 것이 중요합니다.