👀 Issue

✅ Todo

• [ ]

✅ Todo

• [ ]

👀 Issue

✅ Todo

• [ ]

👀 Issue

• 중복되는 UI 한 타겟으로 재구성해야한다.

✅ Todo

• [ ]

👀 Issue

✅ Todo

• [ ]

👀 Issue

✅ Todo

• [ ]

👀 Issue

✅ Todo

• [ ]

👀 Issue

✅ Todo

• [ ]

👀 Issue

토큰 및 유저정보를 저장할 키체인 스토어를 구축

✅ Todo

• [ ]

👀 Issue

✅ Todo

• [ ]

👀 Issue

✅ Todo

• 모듈을 생성할 때 일일이 만들지 않고 make 명령어로 편하게 Module을 생성하기 위함

👀 Issue

✅ Todo

• Signing
• Workspace & Project Name 변경

👀 Issue

✅ Todo

• [ ]

👀 Issue

Root View를 구성합니다.

1. View를 라우팅 해야합니다.
2. 하위 Feature에서 쓰이는 공통으로 쓰이는 View들의 관리를 고민합니다.
3. Reducer의 body를 분리할 방법을 고민합니다.

✅ Todo

• [ ]

👀 Issue

✅ Todo

• [ ]

👀 Issue

✅ Todo

• [ ]

👀 Issue

✅ Todo

• [ ]

👀 Issue

✅ Todo

• [ ]

👀 Issue

✅ Todo

• [ ]

👀 Issue

Pretendard Font, Color 값들에 접근하기 위한 공용 디자인 시스템을 구축

✅ Todo

• [ ]

👀 Issue

로그인을 제외한 권한 획득 부터 홈화면 진입까지의 플로우를 개발

✅ Todo

• [ ]

👀 Issue

✅ Todo

• [ ]

👀 Issue

✅ Todo

• [ ]

👀 Issue

✅ Todo

• [ ]

👀 Issue

Core Layer의 Network 모듈을 구현

✅ Todo

• [ ]

논의사항

결정된 사항을 정리합니다.

Folder 네이밍 한 뎁스 낮추는 것으로 결정

Tuist로 패키지 및 폴더를 강제하므로, 폴더 이름에서 중복을 제거하는 것으로 합니다.

Feature/FeatureOnboarding/FeatureOnboardingHome
->
Feature/Onboarding/Home

View는 인터페이스로 결정

오래된 이슈였는데, 결국 View와 Store가 모두 Interface에 있어야 View 타입을 재사용할 수 있다는 결정이 있었습니다.
아래의 이슈를 해결하고자 하기 위함입니다. 같은 레이어의 모듈간 Implements를 서로 몰라야하고 Interface로만 소통해야 함입니다.

또한 store의 구현부를 빼낸 것처럼 할수 있었지만, 그럴 필요가 없다는 결론을 내렸습니다. View는 껍데기일 뿐이고, Store가 핵심 비즈니스 로직을 담당하기 때문에 이부분만 빼내면 된다는 판단입니다.

즉 FeatureHome과 FeatureProfile은 Interface로 소통하고, Feature에서 FeatureHome과 FeatureProfile을 컴포지션 합니다.

// FeatureHome에서 FeatureProfile이 필요한 상항에서 다음과 같이 해결합니다.
// Feature
import FeatureProfile
import FeatureProfileInterface
import FeatureHome
import FeatureHomeInterface

let makeOtherProfileView: (...)  -> OtherProfileView = { ... in
    return OtherProfileView(store: ...)
}

HomeRootView(..., makeOtherProfileView: makeOtherProfileView)

// FeatureHome
struct HomeRootView: View {
     let makeOtherProfileView: (...) -> OtherProfileView

     public init(..., makeOtherProfileView:  @escaping (...) -> OtherProfileView) {
          ...
          self.makeOtherProfileView = makeOtherProfileView
    }
}

Cell을 DesignSystem에 포함되고, Store와 View를 한쌍(또는 많이)로 갖는 것으로 결정

Cell은 재사용을 위한 struct임이 분명하고, CellView와 CellStore로 나누어서 파일을 관리합니다. Cell이 상태를 갖게 설계하는 것을 피하며, 반드시 부모에게 내려받는 상태로 관리하는 것으로 하는 것을 강제합니다.

DesignSystem의 Components에 해당하는 View는 Store를 갖지 않는 것으로 결정

Button, TextField 등 으로 사용되는 공통 컴포넌트는 Binding 키워드를 통해 관리합니다.

물론 상태는 부모에서 관리합니다.

👀 Issue

Onboarding, Apple Login, HealthKit Auth 개발

✅ Todo

• [ ]

👀 Issue

✅ Todo

• [ ]

👀 Issue

• static framework
  • (복사) do not embed 방식
  • 컴파일 타임에서 로드 시킴
  • 단점: 앱의 사이즈가 증가 (바이너리 파일이 포함되어야 하기 때문)
  • 장점: 빠르다
• dynamic framework(framwork 디폴트 값 임)
  • (참조) embed 방식
  • 런타임에서 필요시 로드 시킴 (lazy 한 작동 방식)
  • 단점: 느리다
  • 장점: 앱의 사이즈 늘지 않음 (바이너리에 미포함, 런타임 시점에서 로드 시키기 때문), 재사용시 참조 방식이어서 중복이 발생하지 않음

실사용 제안점

한번만 쓰일 모듈은 static framework로 가져가는 것이 런타임 시 속도 측면에서 이득
재사용 되는 모듈은 dynamic framwork로 가져가는 것이 앱 사이즈 측면, 중복 측면에서 이득

✅ Todo

• [ ]

✅ Todo

• [ ]

👀 Issue

✅ Todo

• [ ]

👀 Issue

각 피쳐에서 Sheet, FullScreenSheet, Navigation을 한군데서 관리하기 위한 Router를 개발한다.

✅ Todo

• [ ]

👀 Issue

✅ Todo

• [ ]

👀 Issue

✅ Todo

• [ ]

✅ Todo

• [ ]

👀 Issue

✅ Todo

• Alamofire
• Tuist
• TCA
• [TCACoordinators](https://github.com/johnpatrickmorgan/TCACoordinators)
• [LinkNavigator](https://github.com/interactord/LinkNavigator)
• [airbnb/swift](https://github.com/airbnb/swift)
• [Swinject](https://github.com/Swinject/Swinject)

👀 Issue

✅ Todo

• [ ]

👀 Issue

✅ Todo

• [ ]

👀 Issue

✅ Todo

• [ ]

👀 Issue

✅ Todo

• [ ]

✅ Todo

watchOS와 iOS 앱 연동 데모 앱

• 앱 종료해도 실시간으로 트래킹 되는지
• iOS 앱에서 watch앱의 시작 종료가 가능한지

👀 Issue

✅ Todo

• [ ]

👀 Issue

프로젝트 구성을 위해서, 샘플코드를 추가하여서 전체 학습을 돕는 목적입니다.
아직 기획전이긴 하지만, 최대한 예측해서 작성해보면 좋을 것 같습니다.

✅ Todo

• [ ]

🔥 버그

📝 todo

• [ ]

👀 Issue

https://github.com/anc95/ChatGPT-CodeReview

✅ Todo

• [ ]

👀 Issue

✅ Todo

• [ ]

👀 Issue

✅ Todo

• [ ]

👀 Issue

✅ Todo

• [ ]

👀 Issue

✅ Todo

• [ ]