• 모든 Objective-C API는 swift에서 사용가능
  • 만들어지는 인터페이스는 XCode에서 확인 가능
• Swift 인터페이스가 Objective-C에 노출되는 때
  • NSObject의 subclass
    • private는 제외
    • Swift만의 기능(Objective-C에서 활용 불가능함)
    • @objc 마크가 안붙어 있을때 -> 지금은 신경 안쓰고 하고 있다.
  • @IBOutlet, @IBAction, @NSManaged
    • dynamic
• Swift인터페이스를 Objective-C와 쓸때의 문제점
  • Selector Conflict: Objective-C가 메소드를 결정할 때 type을 사용하지 않기 때문
    • @nonobjc attribute로 노출하지 않음으로 해결할 수 있다.
  • Function Pointer
    • 클로저와 비슷하지만 상태를 가져갈 수 없다는 차이점
    • @convention(c) attribute로 C API를 그대로 사용 가능
  • error handling
    • objective-C에는 throw가 없다
    • 마지막 인자에 (NSError **)에 에러를 넣으면 자동으로 swift에서 throw로 바뀐다.
    • objective-C에서 swift 메소드를 호출하는데 거기서 에러가 나면?

// ErrorType -> Error
@objc enum RequestError: Int, ErrorType {
	case Incomplete = 9001
}

• Nullability
  • Objective-C에서는 모든 것이 nullable
  • 따라서 swift로 갈때는 모든 것이 암시적 옵셔널로 바뀐다
  • 그래서 nullable여부를 표시해야 한다.
    • nullable -> Type?
    • nonnull -> Type
    • null_unspecified -> Type!
  • 일일이 체크하기 귀찮으면 구역으로 할 수 있다.
    • NS_ASSUME_NONNULL_BEGIN, NS_ASSUME_NONNULL_END
    • 구역 안에 있어도 개별적으로 nullable 설정 가능
  • __nullable: 타입 선언할때도 사용 가능
• Typed Collection
  • Objective-C는 기본적으로 Type이 없는 Collection을 사용
  • 그래서 Swift에서 타입 가지고 사용할 수 있도록 Objective-C에도 Generic 유사하게 적용

NSArray<UIView *> *views

• Type Safety가 간접적으로 지켜진다(컴파일이 안되진 않음, 워닝이 뜰 뿐)
  • Generic적용하는 것도 swift와 유사

@interface NSArray<ObjectType>

• 제네릭 없는 콜렉션과 상호 대입 가능
• Kindof
  • id에 더 많은 타입 정보를 제공하는 것
  • id기 때문에 sub-super간 이동은 자유롭지만, 관련 없는 타입간의 이동에는 warning을 발생
  • 목표는 id대신 타입 정보를 많이 담는 것
    • 정말 타입 정보가 필요 없을 때만 id를 쓸 것