왜 다시 봐야 할까요? 처음 NavigationStack를 도입했을 때 SwiftUI 내비게이션은 분명 좋아졌습니다. 하지만 앱이 커지면 문제는 다시 생깁니다. path 상태가 여러 화면과 feature에 흩어집니다. 인증, 딥링크, 로깅, 정책 판단이 화면 코드에 섞입니다. “A에서 B로 간다”는 흐름을 테스트 가능한 데이터로 다루기...

왜 만들었을까요? iOS에서 네트워킹 코드를 작성할 때마다 비슷한 고민이 반복됩니다. URLSession 코드가 장황합니다. 요청 하나를 보내려면 URL을 만들고, URLRequest를 설정하고, dataTask를 만들고, response를 체크하고, JSON을 디코딩해야 합니다. 이 과정에서 같은 보일러플레이트를 반복해서 작성하게 됩니다. 에러...

들어가며 SwiftUI가 도입된 이후, 상태 관리에 대한 고민은 깊어졌습니다. @State, @StateObject, @EnvironmentObject 등 다양한 프로퍼티 래퍼가 제공되지만, 프로젝트가 커질수록 상태의 흐름을 추적하기 어려워집니다. “이 상태가 어디서 변경되었지?”라는 질문에 답하기 위해 여러 파일을 오가는 경험, 한 번쯤 있으실 겁...

들어가며 Swift 5.9부터 도입된 Macro 시스템은 Swift 코드의 보일러플레이트를 줄이는 데 큰 역할을 하고 있습니다. @Observable처럼 선언을 간결하게 만들어 주는 기능이 대표적입니다. 하지만 의존성 주입(Dependency Injection) 영역에서는 여전히 수동으로 코드를 작성하거나, 런타임 기반 라이브러리에 의존하는 경우가...

서론 이제 마지막으로 실제 현업에서 사용할 수 있을 정도의 프로젝트를 만들어보려고 합니다. 여러명이 동시에 개발한다고 가정하고, 최소 2개 이상의 피쳐가 존재한다고 생각하고 진행할 예정입니다. 지난 블로그 에서 볼 수 있듯 아래와 같은 프로젝트 구조를 기반으로 Tuist Project를 생성하려고 합니다. 프로젝트 생성전에 먼저 모듈 추가...