[iOS] 프로젝트 파일 그룹 구조 잡기

 

iOS 앱의 아키텍처를 잡는 문제는 아니고, 프로젝트가 있으면 파일을 어떻게 그룹별로 관리하는 게 좋은지에 대한 글이다.

사실 회사 코드의 경우 이미 쓰임새에 맞춰 그룹별로 잘 나눠져 있어 크게 고민할 건 없는데, 개인 프로젝트를 할 때면 고민이 생긴다.

뷰 컨트롤러끼리는 같은 그룹에 둬야 하나? 아니면 같은 화면을 구성하는 것들을 같은 그룹에 둬야 하나?

그룹 구조 잡는 일은 별 거 아니라고 생각할 수도 있지만 화면이 많아지고 파일이 많이 생기다 보니 미리부터 고민을 좀 해둘걸 하는 생각이 들어서 지금이라도 쓴다. 실은 미래의 내가 참고하라고 쓰는 글에 더 가깝다.

 

• 서로 연관되어 있거나, 공통점이 있는 것들을 같은 그룹에 넣는다.
  • 예를 들면, 같은 모듈이나 화면 등을 이루는 모델, 뷰모델, 뷰컨트롤러는 같은 그룹에 분류한다. 뷰모델끼리 분류하는 것보다 이렇게 연관된 것들끼리 같은 그룹에 넣어두면 나중에 찾아보기도 더 쉽다.
• 재사용 가능한 뷰의 경우, 앱 전반에 사용 가능한 재사용 뷰와 특정 모듈에서만 사용되는 서브 뷰들이 있다.
  • 첫 번째 경우에는 Components 등의 그룹을 따로 만들어서 관리한다.
  • 두 번째 경우에는 해당 모듈의 Subviews나 Components 서브 그룹을 만들어 관리한다.

 

 

1. Resources 그룹

에셋, 스토리보드 등의 파일이 들어간다.

• Resources
  • Assets
  • Base.lproj -> LaunchScreen.storyboard 

2. Sources 그룹

모델, 서비스, 뷰컨트롤러와 리액터 등 앱의 기능을 이루는 파일이 들어간다.

•  Sources
  • Networking (통신 관련 파일)
  • Models (모델 파일)
  • Services (UserDefaults, UIAlertAction, 데이터베이스 작업 등을 담은 파일)
  • Modules (화면 단위의 그룹)
    • Subviews (화면 내에서만 재사용되는 커스텀 뷰들)
  • Components (재사용되는 커스텀 뷰들)
  • Extensions (기본 타입의 Extension들을 모아둔 파일)
  • Utils (기타 파일)
• AppDelegate
• SceneDelegate

3. Support 그룹

Info.plist 등 앱의 설정에 관한 파일들이 들어간다.

• Support
  • Info.plist 

 

 

References

• The Best Way To Structure Your iOS Project
•