<h1><center> iOS interview 9 </center></h1>

###### tags: `💻 면접 질문`
###### date: `2025-11-0217:21:33.284Z`

> [iOS interview](https://github.com/JeaSungLEE/iOSInterviewquestions)

## 근황

- 근황? 핫픽스..?
- 외주 냠냠 > 이전 코드는 개발세발, 다른 협업자들은 모름...
- 헉 오늘 꿈에 무슨 동아리 이름이 개발새발이었는데
- PM이 되어버려... 승진이 되어버려... 미친 능력자가 되어버려... 커리어 킹 되어버려...
>> 동아리 ㄱ? / AWS, DB -> 다 해줘... 뭘 해야하지..?

## 목표

- DI ?

- Swinject
- Needle
- swift-dependencies
- or custom

### Swinject

https://pokers.tistory.com/7

> UIKit에 친화 되어있고, 객체를 register, resolve해서 사용함
> Container DI
> 여기서 추가적인 고민해봐야하는 것

**고민 포인트**

container.register(Animal.self, name: "cat") { _ in Cat(name: "Mimi") }

### Assembly

https://github.com/YAPP-Github/Reed-iOS/tree/develop/src/Projects/BKCore/Sources/DiContainer

https://github.com/YAPP-Github/Reed-iOS/blob/develop/src/Projects/BKDomain/Sources/DomainAssembly.swift

> https://github.com/Swinject/Swinject/blob/master/Documentation/Assembler.md

### Scope

https://pokers.tistory.com/7

DI에서 중요한 것은 등록되어 있는 혹은 만들어진 instance 를 어떻게 유지, 재사용, 삭제 하느냐가 주요한 내용입니다. 예를 들어, repository layer의 경우 앱이 실행 될때 하나만 생성되는, 즉 앱의 전체 life cycle과 동일한 주기를 가지는 singleton instance라고 할때에 하나의 instance만 생성해서 여러곳에서 사용될 수 있도록 scope를 설정해 주어야 합니다.

#### Graph - default
가장 기본적인 scope이고 register할때에 scope에 대한 설정을 하지 않은 경우에도 기본적으로 설정되는 scope입니다.

resolve를 이용해서 instance를 요청 할때에 항상 새로운 instance를 만들어서 전달합니다. 단, instance등록하는 factory closure내에서 호출 되는 경우 하나의 instance를 공유하게 됩니다.

#### Transient
이름에서 유추 하실 수 있듯이 instance를 공하지 않고 resolve호출 시 항상 새로운 instance를 생성해서 전달합니다.

#### Container
instance를 현재 container내에서 항상 공유합니다. 이때 child containers가 있다면 child containers들도 해당 instance를 공유하게 됩니다. Design pattern의 singleton을 구현할때에 사용할 수 있습니다.

#### Weak
Container와 비슷한 속성으로서 instance를 현재 container와 child containers들에게서 공유하게 됩니다. 다만 해당 instance에 strong reference가 있을때에만 유지되고 strong references가 종료되어 사라지는 시점에 해당 instance의 공유도 종료되고, 이후 resolve시 새로운 instance를 생성해서 전달 합니다.

### DI 를 설득하는 방법 / 써야하는 이유

- protocol은 이미 채택중
- 테스트 다음 주부터 진행 예정
- 객체 생성 주기를 관리하는게 더 명확해진다. (Scope)

프로젝트 컨텍스트

### Needle

계층구조로 작성하도록 유도하고 컴파일시점에서 DI를 확인

Component
의존성 Scope를 정의해요
각 의존성 범위는 Component로 정의되고 그 의존성은 protocol로 캡슐화되고
제네릭을 이용하여 Component - Dependency

## App Router

> https://krpeppermint100.medium.com/swiftui-navigationstack-router%EB%A1%9C-%EA%B9%94%EB%81%94%ED%95%98%EA%B2%8C-%EA%B4%80%EB%A6%AC%ED%95%98%EA%B8%B0-6ec792593fb3

## 숙제

- DI에서 라이브러리가 정말 필요할까?
- Needle
- DI에서 객체의 생성주기
- DIContainer에 register하는 여러 객체간의 의존성 관리 >> Needle, Swinject > Assembly < SwiftUI??
- **swift-dependencies** > TCA에서 제공하는 것 | TCA가 거의 표준... > 모르고 쓰는 사람도 많아...

https://dokit.tistory.com/54

https://okanghoon.medium.com/ios-needle-%EB%A1%9C-%EC%9D%98%EC%A1%B4%EC%84%B1-%EC%A3%BC%EC%9E%85%ED%95%98%EA%B8%B0-f5019a4f2b92

struct SomeView: View {
    @Environment(AppRouter.self) var appRouter
    @Environment(Container.self) var container
    @Environment(SomeViewModel.self) var someViewModel
    // 화면에서 쓰는건지
    @Environment(\.dismiss) var dismiss
    ...
    
    var body: some View {
        ChildView(viewModel: continer.childViewModel)
    }
}


@Observable
class SomeViewModel {
    @Dependency(\.network) var networkService
}

자기소개

- 내 커리어 도메인
- 개인 성향
- 대화하고 싶은 때 제일 먼저 떠오르는 사람
- 앱 출시 경험 기반

지원동기

- 도메인