이번 글은 UIKit 프레임워크를 스토리보드를 사용하지 않는 코드 기반으로 세팅하는 방법에 대해 알아보겠습니다.
스토리보드와 코드 베이스에는 장단점이 존재합니다.
우선 스토리보드의 장점은 어노테이션이나 컴포넌트와 관련된 코드를 줄일 수 있어 로직에 더욱 집중할 수 있습니다. 뷰가 복잡해질 수록 관리할 코드가 줄어들기 때문에 관리하게 편해집니다. 또한 오토 레이아웃을 시각적으로 보여주어 오류를 쉽게 파악할 수 있습니다. 단점은 스토리보드는 xml 기반이기 때문에 다른 개발자가 확인하기에 어렵다는 문제점이 있습니다. 스토리보드를 수정하고 PR를 요청했을 때, 다른 개발자가 코드만을 보고 변화를 확인하기 어렵다는 단점이 있습니다. 또한 뷰에 컴포넌트가 추가되어 복잡해질수록 파일이 무거워진다는 단점도 있습니다.
코드 베이스의 장점은 우선 속도가 빠르고, 다른 개발자가 코드의 수정을 쉽게 확인할 수 있다는 점입니다. 또한 Class 기반이기 때문에 상속을 통해 코드의 중복 문제를 개선할 수 있습니다. 단점으로는 뷰를 시각적으로 확인할 수 없어 빌드를 통해 확인해야 한다는 점이 있지만, 이는 PreView를 통해 확인할 수 있습니다.
이젠 세팅하는 순서에 대해 알아보겠습니다.
1. Interface를 StoryBoard로 설정한 뒤, 프로젝트 생성해줍니다.

2. 프로젝트를 생성하면 기본적으로 Main.storyboard 파일이 있을텐데, 해당 파일을 삭제해줍니다.
(Move to Trash를 통해 삭제하기)

3. [TARGETS] -> [Info] -> 'Main storyboard file base name'의 기본값은 Main으로 되어있는데, 이를 삭제해줍니다.

4. Info.plist를 확인해보면 'Storyboard Name'이라고 적혀있는 프로퍼티를 삭제해줍니다.
참고로 2 ~ 4번의 순서가 달라져도 상관없습니다.

5. SceneDelegate의 Scene 메서드를 수정해줍니다.
windowScene의 rootViewController를 ViewController로 선언해줍니다. 스토리보드가 있을 때에는 Main.storyboard가 자동으로 선언해주었지만, 스토리보드를 제거했기 때문에 이를 선언해주어야 합니다.
func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
guard let windowScene = (scene as? UIWindowScene) else { return }
let window = UIWindow(windowScene: windowScene)
window.rootViewController = ViewController() // Your initial view controller.
window.makeKeyAndVisible()
self.window = window
}
이제 세팅이 완료되었습니다. ViewController의 backgroundColor를 변경하고 실행함으로써 잘 적용이 되었는지 확인해봅시다.


보시는 바와 같이 잘 적용됨을 알 수 있습니다.
'iOS > UIKit' 카테고리의 다른 글
[UIKit] 메모리 관점에서의 CollectionView, PageView, ScrollView의 동작 방식 (2) | 2025.01.29 |
---|---|
[iOS-UIKit] Final 키워드를 사용하는 이유 (최적화의 관점) (0) | 2025.01.19 |
[UIKit] 문자열 보간법의 실행 구조 (feat. UI*.text) (0) | 2025.01.06 |
[UIKit-Storyboard] 스토리보드 컴파일 과정 (0) | 2024.12.31 |
이번 글은 UIKit 프레임워크를 스토리보드를 사용하지 않는 코드 기반으로 세팅하는 방법에 대해 알아보겠습니다.
스토리보드와 코드 베이스에는 장단점이 존재합니다.
우선 스토리보드의 장점은 어노테이션이나 컴포넌트와 관련된 코드를 줄일 수 있어 로직에 더욱 집중할 수 있습니다. 뷰가 복잡해질 수록 관리할 코드가 줄어들기 때문에 관리하게 편해집니다. 또한 오토 레이아웃을 시각적으로 보여주어 오류를 쉽게 파악할 수 있습니다. 단점은 스토리보드는 xml 기반이기 때문에 다른 개발자가 확인하기에 어렵다는 문제점이 있습니다. 스토리보드를 수정하고 PR를 요청했을 때, 다른 개발자가 코드만을 보고 변화를 확인하기 어렵다는 단점이 있습니다. 또한 뷰에 컴포넌트가 추가되어 복잡해질수록 파일이 무거워진다는 단점도 있습니다.
코드 베이스의 장점은 우선 속도가 빠르고, 다른 개발자가 코드의 수정을 쉽게 확인할 수 있다는 점입니다. 또한 Class 기반이기 때문에 상속을 통해 코드의 중복 문제를 개선할 수 있습니다. 단점으로는 뷰를 시각적으로 확인할 수 없어 빌드를 통해 확인해야 한다는 점이 있지만, 이는 PreView를 통해 확인할 수 있습니다.
이젠 세팅하는 순서에 대해 알아보겠습니다.
1. Interface를 StoryBoard로 설정한 뒤, 프로젝트 생성해줍니다.

2. 프로젝트를 생성하면 기본적으로 Main.storyboard 파일이 있을텐데, 해당 파일을 삭제해줍니다.
(Move to Trash를 통해 삭제하기)

3. [TARGETS] -> [Info] -> 'Main storyboard file base name'의 기본값은 Main으로 되어있는데, 이를 삭제해줍니다.

4. Info.plist를 확인해보면 'Storyboard Name'이라고 적혀있는 프로퍼티를 삭제해줍니다.
참고로 2 ~ 4번의 순서가 달라져도 상관없습니다.

5. SceneDelegate의 Scene 메서드를 수정해줍니다.
windowScene의 rootViewController를 ViewController로 선언해줍니다. 스토리보드가 있을 때에는 Main.storyboard가 자동으로 선언해주었지만, 스토리보드를 제거했기 때문에 이를 선언해주어야 합니다.
func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
guard let windowScene = (scene as? UIWindowScene) else { return }
let window = UIWindow(windowScene: windowScene)
window.rootViewController = ViewController() // Your initial view controller.
window.makeKeyAndVisible()
self.window = window
}
이제 세팅이 완료되었습니다. ViewController의 backgroundColor를 변경하고 실행함으로써 잘 적용이 되었는지 확인해봅시다.


보시는 바와 같이 잘 적용됨을 알 수 있습니다.
'iOS > UIKit' 카테고리의 다른 글
[UIKit] 메모리 관점에서의 CollectionView, PageView, ScrollView의 동작 방식 (2) | 2025.01.29 |
---|---|
[iOS-UIKit] Final 키워드를 사용하는 이유 (최적화의 관점) (0) | 2025.01.19 |
[UIKit] 문자열 보간법의 실행 구조 (feat. UI*.text) (0) | 2025.01.06 |
[UIKit-Storyboard] 스토리보드 컴파일 과정 (0) | 2024.12.31 |