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

서론제가 개발 중인 앱에는 다국어를 지원합니다. 총 영어(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..

Unit Test 자동화GitHub Actions를 활용하면 Xcode에서 작성한 Unit Test를 자동으로 체크할 수 있습니다.PR을 생성할 때, push를 할 때 등의 액션이 발생하면 Unit Test를 수행하는 방식입니다.Test 편의성과 안정성을 동시에 챙길 수 있으므로 꼭 필요한 과정입니다.  GitHub Actions로 자동화하며 겪은 에러저는 GitHub 안에서 개인 프로젝트 사이클을 돌리고 싶었기 때문에 GitHub Actions를 선택하였는데요.쉽게 가능할 줄 알았지만, 많은 에러를 겪었습니다. 고군분투의 흔적 ;;결과론적인 이야기지만, 앞에서부터 차근차근 살펴봤다면 쉽게 해결했을 텐데... 반성합니다 🥲성공한 Workflow는 최하단에 있으니 최종 결과만 필요하시면 쭉 내리시면 됩니..

* 혼자 고민한 과정을 기록 목적으로 적은 포스팅입니다. 읽기 전 참고 부탁드립니다 :) DTO DTO는 서버와 통신하는 API의 데이터를 디코딩, 인코딩하기 위한 객체입니다. { "id": 1000, "name": "다이어트", "continued": 10, "lastChallenged": "2011-04-10T20:09:31Z" } 가령 API로 오는 데이터가 위와 같다면, struct CategoryDTO: Codable { let id: Int let name: String let continued: Int let lastChallenged: Date } CategoryDTO는 id, name, continued, lastChallenged 속성을 가지게 됩니다. 이때 각 속성은 Non-옵셔널이 ..

서론 앱을 개발할 때 서버와 API 통신을 자주 합니다. API 통신 개발 과정에서 문제가 생겼을 때 디버깅을 위해 Postman, Swagger를 사용하기도 합니다. Postman, Swagger도 좋은 방법이지만, 실제 내 앱이 어떤 요청과 응답을 주고 받는지 궁금할 때가 있습니다. if let requestBody = urlRequest.httpBody, let requestBodyString = String(data: requestBody, encoding: .utf8) { print("[요청 데이터]\n\(requestBodyString)") } if let responseBody = try? encoder.encode(body), let responseBodyString = String(dat..

서론 UnitTest 사용해보기와 XCTest 성능 측정 (Command Line 환경)에서 UnitTest를 하는 방법과 성능 측정 방법을 다뤘습니다. 이전에는 동기 메서드만 테스트만 다뤄서 이번에는 비동기 테스트에 대해 말해보려고 합니다. 대부분의 앱에는 네트워크 통신이 필요합니다. 네트워크 통신은 오래 걸리는 작업이기 때문에 반드시 비동기로 처리해야 합니다. 같은 이유로 네트워크 테스트도 비동기로 테스트해야 하며, 다른 동기 테스트와 분리해야 합니다. 비동기 테스트 비동기 메서드를 동기 테스트 코드와 똑같이 테스트하면 제대로 테스트할 수 없습니다. 비동기 메서드의 결과가 나오기 전에 테스트 함수가 종료되기 때문입니다. 그래서 비동기 메서드가 종료될 때까지 기다리는 작업이 필요한데요. 이를 위해 XC..

서론 Xcode 15.1 Beta에서 IBDesignable이 Deprecated 되었습니다. Xcode 15부터 생긴 #Preview 매크로를 적극 권장하기 위한 처리가 아닐까 생각이 들어서 이번 기회에 #Preview를 사용해 보기로 했습니다. 막상 사용해 보니 생각보다 더 편하고 유용해서 이렇게 포스팅까지 하게 되었네요. 특히 무선 Preview가 상상 이상이라 놀라웠습니다. 하나하나 천천히 살펴봅시다! Preview 관련 WWDC를 다룬 포스팅도 봐주시면 감사하겠습니다 ㅎㅎ #Preview #Preview를 사용하는 방법은 정말 간단합니다. #Preview { 보고 싶은 뷰 } 위 코드만 소스 파일 최상위에 적어주면 됩니다. 그럼 Xcode 화면이 분리돼서 Preview가 보입니다. Xcode가 ..

서론 언제나 그렇듯 아래와 같이 Delegate를 만들고 있었습니다. protocol OOODelegate: AnyObject { func ... } 근데 아차! 싶었습니다. Delegate에 왜 AnyObject를 붙여야 하지?라는 생각을 따로 안 해봤더라고요. 어렴풋이 알고는 있었지만 따로 생각을 해보거나 글로 정리한 적이 없어서 이렇게 포스팅하기로 결정했습니다. iOS에서는 언제 Delegate를 쓸까? Delegate는 Delegate를 채택하는 누군가에게 나의 행위를 위임합니다. Delegate를 사용하는 곳에서는 메서드를 호출만 하고, Delegate를 채택하는 곳에서 메서드를 구현하는 것입니다. iOS에서는 주로 유저 이벤트에 따른 행위를 구현할 때 Delegate를 사용합니다. 예를 들어,..