최근 회사에서 모듈화를 진행하고 있습니다. 그런데 tuist도 제대로 모르면서 모듈화라뇨.. 신입인 저에겐 공부해야할게 산더미군요 기존 프로젝트는 레이어별 모듈화로 이루어져 있었습니다. App, Domain, Core, Util. 구조 자체는 깔끔해 보였어요. 그런데 프로젝트가 점점 커지면서 문제가 슬슬 보이기 시작했습니다. 빌드 속도가 말도 안되게 느려졌습니다.Home 화면 버튼 하나를 수정했을 뿐인데, Domain 220개 파일과 Core 154개 파일이 전부 다시 컴파일되는 거예요. 레이어별 모듈화의 구조적 문제입니다. 한 레이어의 어느 파일이 바뀌면, 그 레이어에 의존하는 모든 것이 다시 컴파일되어야 합니다. 주변의 도움도 받고 그러다보니 자연스럽게 이런 이야기가 나오기 시작했습니다."이제 Fe..

오랜만에 글 쓰네요 날씨가 따듯해지면서 오늘은 좋은 카페에 와서 글을 써요 오늘의 카페 추천은합정에 있는 콤파일입니다.어두컴컴하고 아주 제 취향이더라고요. (주말 2시간 컷은 너무하긴하네요)암튼 오늘은 오랜만에 swift에 대해 재밌는 Q&A 영상 올라와서 정리해보려고요:)Apple 엔지니어들이 직접 나와서 Swift Concurrency 관련 질문들에 답해주는 영상인데, 실제로 헷갈렸던 것들이 꽤 많이 해소됐어요. Swift 6로 넘어오면서 data race 검사가 빡세지면서 경고 폭탄을 맞은 분들도 많을 것 같아서, 제가 정리한 내용 같이 공유해봐요 :)isolation 이란?Swift Concurrency에서 가장 먼저 이해해야 할 개념이 있어요. 바로 isolation입니다.isolation(격리..

토스 같은 금융 앱은 하루에 수백만 건의 알림을 보냅니다. 송금 완료, 카드 결제, 이벤트 참여, 마케팅까지.....만약 이걸 그냥 "생각날 때마다" 보낸다면? 사용자는 알림 폭격에 스트레스 받아서 앱 삭제할 겁니다. 저도 쓰잘데기 없는 알람이 많은 앱들은 성가셔서 대부분 삭제했어요... (죄송합니다 개발자분들)실제로 Localytics 연구에 따르면 사용자의 절반 이상이 성가신 알림 때문에 알림 권한 자체를 거부한다고 하죠.그럼 대기업들은 어떻게 할까요? 그저 "알림 보내기"가 아니라 "언제, 어떻게, 얼마나 자주 보낼 것인가"를 시스템적으로 설계합니다. 이를 위해 알람에 대해 먼저 공부하고 -> 어떻게 설계하는지 -> 로 이어지면서 오늘의 글을 시작하겠습니다:) 발송 주체 Local VS Remot..

그거 아세요???iPhone으로 사진을 찍으면 파일 확장자가 .HEIC인데, 스크린샷을 찍으면 .PNG로 저장된다는 사실을요!!왼쪽 사진은 제가 직접 쿠알라룸푸르에서 찍은 트윈타워! 그리고 오른쪽은 그 화면을 다시 캡처한 이미지에요! 그래서 파고들기 시작했습니다. 그리고 알게 됐어요.이게 단순히 "애플이 그냥 그렇게 만들어서"가 아니라, 각 포맷의 압축 방식과 특성이 완전히 다르기 때문이라는 걸요. 오늘은 이 이야기를 해보려고 합니다. iOS에서 이미지가 어떻게 처리되는지, 그리고 왜 상황에 따라 다른 포맷을 쓰는지 말이죠. 그리고 살짝쿵 이미지 압축 처리도 들어있어서 어려울 수 있어요:(이미지가 화면에 보이기까지사실 이거는 이전에 https://codeisfuture.tistory.com/96 근본으로..

UIKit으로 개발할 때, 저는 Clean Architecture + MVVM + Coordinator 조합을 사용했어요. 사실 처음엔 누구나 그렇듯 MVC 패턴으로 시작했죠. 근데 이게... ViewController가 점점 비대해지더라고요. 전형적인 Massive View Controller 문제가 발생 🚨🚨첫 번째 시도: 상태를 Struct로 분리struct UserState { let name: String let email: String}class ViewController: UIViewController { private var state: UserState func updateUI() { nameLabel.text = state.name ..

let task = URLSession.shared.dataTask(with: url) { data, response, error in // 응답 처리}task.resume()딸-깍 그런데 안에서는 어떤 동작이 이루어지는 지 아시나요? 이번 시간은 URLSession에 뭐가 있는지 아예 베이스에 대해서라기보다는 어떻게 동작하는지에 초점을 맞춰 글을 작성하려합니다.대신!! URLSession에 관해서는 아주 좋은 블로그를 추천해드리겠습니다:)https://codeisfuture.tistory.com/148 URLSession에 대한 에브리띵실제로는 URLSession은 Apple이 만든 거대한 URL Loading System의 하나인 거고 그 안에는 여러 라이브러리들이 있어요:) URL Loadi..

왜 캐싱이 필요할까?대부분의 앱은 서버와 HTTP 통신으로 데이터를 가져와요. 그런데 이 과정에는 생각보다 큰 비용이 들어가죠.클라이언트(앱) → 네트워크 왕복 시간이 걸림서버 → 요청을 처리하느라 부하가 증가함사용자 → 데이터 사용량과 배터리를 소모함특히 이런 상황을 생각해봅시다.👉방금 받아온 데이터랑, 지금 또 요청하려는 데이터가 똑같다면? 업데이트된 정보도 없는데, 또 네트워크를 타는 건 이건 명백한 낭비죠입니다.이 문제를 해결하는 방법이 바로 HTTP 캐싱이에요.캐시는 어디에 저장되나?캐시는 어디에 저장되나?중간 서버에 캐시를 둔 구조CloudFront, Cloudflare 같은 CDNNginx, Varnish 같은 프록시요청이 캐시에 있으면 원 서버까지 안 가도 되지만, 여전히 네트워크는 타요..

실제로는 URLSession은 Apple이 만든 거대한 URL Loading System의 하나인 거고 그 안에는 여러 라이브러리들이 있어요:)URL Loading System의 전체 구조URL Loading System의 핵심 특징:비동기 처리: 모든 네트워크 작업이 백그라운드에서 수행되어 앱의 반응성 유지프로토콜 지원: HTTP, HTTPS, FTP, 파일, 그리고 커스텀 프로토콜까지 지원Cookie Storage (쿠키 관리부서 🍪)HTTPCookieStorage: 웹사이트 로그인 상태 유지, 사용자 설정 기억 등을 위한 쿠키 자동 관리HTTPCookie: 개별 쿠키 정보를 담는 컨테이너 역할Authentication & Credentials (보안 인증부서 🔐)URLProtectionSpace..

iOS 앱에서 스크롤은 손가락을 움직이면 화면이 부드럽게 따라 움직이죠. 하지만 이 단순한 동작 뒤에는 iOS의 렌더링 시스템과 UIView의 핵심 속성들이 얽혀 있습니다. 이번 글은 UIScrollView가 어떻게 작동하는지, 그 근본적인 원리인 UIView의 렌더링 과정부터 시작해 frame과 bounds의 차이, 그리고 contentOffset의 정체(?)까지 깊이 파헤쳐 보겠습니다화면 렌더링의 두 단계: Rasterization과 Composition1단계: Rasterization (래스터화): 각 뷰가 자신의 이미지(콘텐츠)를 그리는 단계각 뷰가 자신의 콘텐츠를 비트맵 이미지로 변환하는 과정입니다. UILabel은 텍스트를, UIImageView는 이미지를 그리죠.여기서 중요한 점은 래스터화는..