ios app에서 뷰의 역할은 무엇일까?
앱에서 가지고 있는 데이터를 사용자에게 보여준다.
사용자의 인터렉션 받아서 앱에 알려준다.
ios app에서 뷰 그리는 방법!
- Nib : 잡스가 애플에서 쫓겨나면서 넥스트 만들고 다시 애플 돌아오면서 합병됨. 넥스트에서 하던 ui그리던 방식.(드래그로 쉽게) next interface builder 약자임.
-> 고도화시킨게 Xib -> 스토리보드 -> 코드와 스토리보드 사용의 장단점을 고려해서 최근에는 SwiftUI 점차 사용되고 있다.
UIKit (storyboard)
- 장점
- 뷰를 위한 코드를 적게 작성 가능
- 뷰를 직관적으로 이해하기 쉬움
- 뷰작업 속도가 빠름
- 단점
- 작업내용을 보기가 어려움 → 컨플릭트 났을때, xml 보고 수정하는게 빡셈 (깃)
- 재사용성이 낮음
- 뷰의 동적 변화에 있어서 제약 (사용자가 어떤 행동했을 때 대응)
UIKit (Code)
- 장점
- 작업 내용을 보기가 쉬움
- 재사용성 높음
- 동적 변화에 제약이 덜함
- 단점
- 뷰를 위한 코드가 많이 들어감
- 뷰를 직관적으로 바로 이해하기 어려움
- 뷰작업 속도가 느림 (재사용성 높아짐에 따라, 속도는 향상 가능)
SwiftUI
- 장점
- 작업 내용을 보기가 쉬움
- 재사용성 높음
- 뷰를 위한 코드를 적게 작성 가능
- 뷰를 직관적으로 이해하기 쉬움
- 뷰작업 속도가 빠름
- 단점
- 현재 대부분 프로젝트는 UIKit 기반이 많음
- iOS 버젼 별로, 되는 UI가 있어서, 분기를 태워서 버젼별로 관리해주어야함
결국,
- UIKit 에서 스토리보드 vs Code 간 장단점 알기
- 현재 많은 회사에서 UIKit 기반 프로젝트 사용하고 있어서, UIKit을 꼭 알아야함
- 애플에서 앞으로 미래의 UI로 생각하는 기술인 SwiftUI도 꼭 알아야함
- 결국, UIKit / SwiftUI 둘다 알아야함
큰 앱, 코드 양 많은 프로젝트 경우는 재사용성 높아야 효율적인데 스토리보드로 하면 힘듬.
스토리보드도 하나당 뷰컨 하나로 각자 작업하면 conflict 많이 줄일 수 있음
빠르게 사용자 확인 필요한 경우는 스토리보드.
회사 상황이나 서비스 상황마다 다르다.
