🧠 핵심 요약
@available은 Swift에서 API의 사용 가능 여부를 선언하는 속성(attribute)이다.
이 속성을 사용하면 특정 플랫폼, 버전, 또는 전체 플랫폼에서 사용 가능/불가능 여부를 명시할 수 있다.
✅ 기본 문법
@available(platform version, *, message: "Optional message")platform:iOS,macOS,watchOS,tvOS등version: 해당 플랫폼에서 사용 가능한 최소 버전*: 모든 플랫폼에 적용됨을 의미message: 사용자가 API를 쓸 때 나타나는 안내 메세지
🧩 주요 키워드 종류
| 키워드 | 설명 |
|---|---|
@available(...) | 해당 조건에 따라 사용 가능 |
@available(*, unavailable) | 모든 플랫폼에서 사용 불가 |
@available(..., deprecated) | 사용은 가능하지만 권장되지 않음(경고 발생) |
@available(..., obsoleted) | 완전히 사용 불가 (컴파일 에러 발생) |
✔️ 사용 예시
1) 특정 버전부터 사용 가능
@available(iOS 15, *)
func doSomethingNew() {
// iOS 15 이상에서만 사용 가능
}2) 특정 버전부터 deprecated (경고만 표시)
@available(iOS, deprecated: 14.0, message: "Use newAPIMethod() instead")
func oldMethod() {
// 여전히 작동하지만 경고 표시
}3) 완전히 사용 금지 (컴파일 에러 유도)
@available(*, unavailable, message: "Use init(title:) instead")
init() {
fatalError("Use designated initializer")
}4) 여러 플랫폼 동시 선언
@available(iOS 14, macOS 11, *)
func sharedFeature() {}🔐 @available이 중요한 이유
- ✅ 버전별 대응이 쉬움 (
if #available) - ✅ API 설계 명확성 향상
- ✅ 컴파일러 경고/에러로 안전성 강화
- ✅ 팀 개발에서 실수 방지
❓ required init?(coder:)와 함께 사용
Swift에서 UIView를 상속해서 커스텀 뷰를 만들 때, 직접 init(frame:)이나 커스텀 이니셜라이저를 정의하려고 하면 Swift는 반드시 required init?(coder:)도 구현하라고 요구한다.
이건 Interface Builder(스토리보드, XIB 등)에서 인스턴스를 만들 때 필요한 이니셜라이저이기 때문이다.
하지만 스토리보드를 사용하지 않는다면 이 이니셜라이저는 절대 호출되지 않기 때문에, @available을 사용하여 해당 이니셜라이저가 사용되는 것을 막을 수 있다.
@available(*, unavailable) // 모든 플랫폼에서 사용 불가
required init?(coder: NSCoder) {
fatalError("init(coder:) has not been implemented")
}✅ 장점
- 컴파일 타임에 막음: 다른 사람이 실수로 스토리보드에서 이 뷰를 사용할 때 컴파일 에러가 발생 ->
fatalError는 런타임 시점에서 중단하기 때문에 이보다 강력함 - 명시적으로 불가 선언: 팀원이나 후속 개발자가 이 뷰는 코드로만 사용된다는 것을 명확하게 알 수 있음
- SwiftUI나 UIKit 코드 작성 시 불필요한 경로 제거: 코드 기반 뷰만 허용하겠다는 명시적인 의도 표현
📌 결론
이번에 다른 개발자가 required init?(coder:)에 @available을 활용하는 코드를 보고 왜 사용하는 것인지 의문이 생겨서 @available에 대해 공부를 해보았는데, 생각보다 활용할 수 있는 범위가 넓은 것 같아서 큰 도움이 되었다.
특히 버전별로 관리하거나 플랫폼 별로 관리를 할 수 있다는 점이 인상 깊었는데, 앞으로 프로젝트를 할 때도 유용히 사용할 수 있을 것 같다.
이유있는 코드를 쓰자!!