클린 아키텍처 원 그림과 사용자 관점의 불일치최근 흥미로운 대화를 나눴습니다."iOS 개발할 때 클린 아키텍처의 원과 사용자 관점이 잘 안 맞는 것 같지 않나요?" 소프트웨어 개발자라면 한 번쯤은 접해봤을 클린 아키텍처의 유명한 원형 다이어그램에 대한 이야기입니다.이 다이어그램에서는 네트워크 계층이 가장 바깥쪽에 위치하고, Presenter, Use Case, Domain 등이 안쪽에 배치되어 있습니다.하지만 실제 사용자 시나리오를 보면, 화면이 먼저 나타난 후 사용자 이벤트에 따라 네트워킹이 발생하는 것이 일반적입니다.즉, 사용자 관점에서는 네트워크보다 Presenter나 UseCase를 먼저 경험하게 되는 것이죠. 물론 이 다이어그램이 잘못되었다고 할 순 없습니다.이렇게 널리 알려진 데에는 분명한 이..

서론Swift 4.1에서 flatMap이 deprecated되고 compactMap으로 역할이 분리되었습니다.저는 한 가지 착각하고 있었습니다. "flatMap이 아예 사라지고 compactMap이 새로 생겼구나"라고 오해했는데요, flatMap은 여러 형태가 존재했고, flatMap 중 하나가 compactMap이 된거였습니다.이번 포스팅은 pointfree의 https://www.pointfree.co/episodes/ep10-a-tale-of-two-flat-maps 영상과 스크립트를 정리한 포스팅입니다. flatMap이 어떤 형태를 제공했었고, 어떤 메서드가 compactMap이 된 것인지 알아보겠습니다. flatMap의 세 가지 형태flatMap은 총 세 가지 형태로 제공됩니다.extension..

서론제가 개발 중인 앱에는 다국어를 지원합니다. 총 영어(en), 일본어(ja), 터키어(tr), 스페인어(es) 총 4개의 다국어를 지원하고 있어요.그래서 Localizable.strings로 다국어를 키-문자열 쌍으로 관리하고 있습니다.아래에서 설명할 이유들로 Lokalise 서비스 도입을 결정했고, 이 과정에서 도입을 위한 작업을 효율적으로 개선한 경험을 공유드리려고 합니다. 기존의 다국어 관리 문제기존 다국어 적용은 기획자가 각 클라이언트 개발자(iOS, Android, Web)에게 문자열을 전달해 줍니다.문자열을 받으면 각자의 방식으로 키를 정의하고 관리했죠. 이로 인해 기입 실수가 발생하면 클라이언트마다 다국어가 다른 경우가 생겼습니다. (특히 일본어는 한자라서 실수가 발생해도 알아차리기 어렵..

서론제 프로젝트에서는 대부분의 UseCase가 Repository와 ViewModel을 단순히 연결해 주는 역할만 하고 있었습니다. 예를 들면 다음과 같은 코드였죠.struct FetchBooksUseCase { func execute() async -> Something { await repository.fetchBooks() }}이런 구조 때문에 저는 종종 "과연 이 상황에 UseCase가 정말 필요할까?" 하는 의문을 가졌습니다. 하지만 최근 UseCase를 정의한 것이 매우 적절했다고 느낀 경험이 있었습니다.물론 이것이 엄청난 발견이나 깨달음은 아니었습니다. 다만, 인터넷에서 자주 언급되는 "UseCase를 사용해야 하는 이유"를 직접 체감하고 경험했다는 점에서 작은 감동을..

UIPageViewController 크래시 분석UIPageViewController를 사용하는 앱에서 높은 비율로 크래시가 발생했습니다.The number of view controllers provided (0) doesn't match the number required (2) for the requested transitionThe number of view controllers provided (0) doesn't match the number required (1) for the requested transitionUIPageViewController에 제공하는 UIViewController의 개수를 제대로 컨트롤하고 있었기 때문에 원인을 파악하기 어려웠습니다. UIPageViewControl..

Swift Macros 사용 이유이전 포스팅(https://jeong9216.tistory.com/727)에서 Swift macros에 대해 소개했습니다.Swift macros는 코드 작성 시 발생하는 반복적인 패턴을 효과적으로 제거하는 데 큰 도움이 됩니다.여기서 주목할 점은 단순한 코드의 반복이 아닌, 코드만으로는 해결하기 어려운 '패턴의 반복'을 제거할 수 있다는 것입니다. 이는 Swift macros의 강력한 특징 중 하나입니다. 구체적인 예로, DTO(Data Transfer Object)에서 CodingKeys를 작성하는 패턴을 들 수 있습니다. 이러한 패턴은 일반적인 방법으로는 코드 레벨에서 반복을 제거하기 어렵습니다. 그러나 Swift macros를 활용하면 이러한 반복적인 패턴을 효과적으..

매크로 지원의 필요성Swift는 보일러 플레이트 코드를 줄이기 위한 다양한 기능을 제공하지만, 이러한 기능들로도 해결되지 않는 경우가 발생할 수 있습니다.이때, 개발자가 Swift 컴파일러를 수정하는 방법도 있습니다. Swift가 오픈 소스로 제공되기 때문에 컴파일러 수정이 가능하긴 하지만, 이 방법은 복잡하고 유지보수가 어렵습니다.매크로를 활용하면 컴파일러를 수정할 필요 없이 패키지에 포함된 형태로 보일러플레이트를 제거할 수 있습니다.이는 개발자들이 원하는 기능을 쉽게 구현할 수 있도록 도와줍니다. 매크로는 명확해야 한다Swift 컴파일러는 #과 @ 기호를 매크로로 인식하여 확장성을 추가합니다.매크로는 두 가지 유형이 있습니다.독립형 매크로: 항상 # 기호로 시작합니다.첨부 매크로: 코드 선언부에 작성..

Boost SwiftUI 스터디최근 SwiftUI 스터디를 시작했습니다.이름은 Boost SwiftUI 스터디! (사실 공식 이름 없음 ㅎ;)iOS 개발자 7명과 디자이너 1명이 함께하는 스터디입니다. (혹시 깃허브 레파지토리가 궁금하다면...? https://github.com/BoostSwiftUI/SwiftUI) SwiftUI Tutorial로 기초를 잡고, 디자이너와 피그마로 협업하여 다양한 UI 개발 경험을 쌓습니다.마지막으로 주 1회 WWDC 시청으로 딥 다이브를 하고 있습니다. 스터디를 시작한지 약 한 달이 지난 지금, SwiftUI와 관련된 생각이 조금씩 쌓여서 글까지 쓰게 되었습니다.참고로 저는 최소 지원 버전을 iOS 15로 설정하여 진행했습니다. 깊은 고민 없이도 만들기 쉽다.처음 이..

회고 요약 feat. GPTSwiftUI 기초 학습과 다양한 UI 구현 목표, 적극적인 7명의 멤버와 함께 시작.유지보수와 개선에 중점을 둔 한 주. QA 티켓 감소와 기획자들에게 도움이 되는 선행 배포라는 긍정적인 경험을 얻음.SwiftUI 학습을 본격적으로 시작, WWDC 영상을 주 1회 시청하며 공식 개념 학습. 한 일SwiftUI 스터디 시작!SwiftUI 스터디를 시작했습니다.SwiftUI의 기초를 학습하고, 다양한 UI를 SwiftUI로 구현하는 것이 목표예요. SwiftUI Tutorial과 WWDC로 기초를 학습하고, Mobbin을 참고해서 다양한 화면을 구현해 볼 예정이에요.하다 보니 7명이나 모였는데, 한 분 한 분 모두 적극적이신 분이라 너무 기대됩니다. (아직 아이스 브레이킹만 함 ..

한 일 (16일 ~ 21일)새로운 기술 도전잘한 점새로운 기술에 도전했습니다.Tuist를 이용한 모듈화와 FlexLayout + PinLayout 중 고민하였고,FlexLayout + PinLayout을 이용해 UI 성능을 개선하기로 결정했습니다.현재 저의 개발 환경은 혼자 + 크기가 작음 이기 때문입니다.특히 혼자 개발하는 환경에서 모듈화가 크게 의미가 없다고 생각했습니다.결국 저에게 좀 더 가깝게 다가오고 흥미가 있던 FlexLayout과 PinLayout에 도전했습니다.(+ 최근 자주 보고 있는 당근 테크 블로그에서도 봐서 더 친근하게 느껴졌어요 ㅋㅋ) 개인 프로젝트 뿐만 아니라 현업에서도 새로운 기술에 도전하고 있어요.이번 주는 새로운 기술 도전을 크게 한 일주일이라고 생각이 드네요 :) 아쉬운 ..