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는 이미지를 그리죠.여기서 중요한 점은 래스터화는..

앱을 종료했다가 다시 켰을 때도, 내가 설정해둔 값들이 그대로 남아있어야 하잖아요?예를 들어 다크모드 설정이라든지, 게임 속 설정 같은 것들이요. 그런데 Swift에서 메모리에 올라간 객체들은 휘발성이라 앱이 종료되면 다 사라져 버립니다.그래서 iOS에서는 데이터를 영구적으로 저장하기 위한 여러 방법이 있어요.UserDefaults (가장 간단한 방법)가장 먼저 떠올릴 수 있는 게 바로 UserDefaults입니다. 작고 단순한 데이터를 저장할 때 쓰기 딱 좋아요 하지만! 지원하는 타입은 한정적입니다:String, Int, Double, Float, Bool, URL, Data 그리고 이 타입들로 구성된 Array, Dictionary결국 기본 타입들이네요? 그러면 우리가 개발하면서 만든 객체들은 어떻게..

객체들끼리는 어떻게 협업을 할까?아! 그 전에 객체지향이 모냐면...데이터와 그 데이터를 다루는 행위를 하나로 묶고 메시지를 통해 협업하는 프로그래밍 패러다임 입니다캡슐화: 관련된 프로퍼티와 메서드를 하나의 객체로 묶고, 내부 구현은 감추며 외부에는 필요한 인터페이스만 제공책임 분리: 각 객체는 하나의 명확한 책임만을 가져, 역할이 겹치지 않도록 분리합니다.메시지 전달: 객체들이 서로 소통하며 더 큰 기능을 하는거죠객체지향을 처음 배울 때 이런 생각 해보셨나요? "그냥 하나의 클래스에 모든 기능을 다 넣으면 안 되나?"하지만 생각을 해보면 한 사람이 주문받고, 요리, 서빙, 계산까지 다한다면 그 한사람이 아프면 가게가 마비가 되겠죠?=> 바로 응집도가 낮고 단일 책임 원칙(SRP)을 위반한 결과입니다...

왜 PHPickerController가 세상에? 나오게 되었을까?🤔 🤔 iOS에서 사진을 가져오는 전통적인 방식은 UIImagePickerController였습니다.하지만 몇 가지 심각한 단점이 있었습니다:1. 프라이버시 문제 👿UIImagePickerController를 사용하려면 반드시 info.plist에 이런 설정을 추가해야 했어요:NSPhotoLibraryUsageDescription사진에 접근하려고 합니다. 위 사진은 오로지 본인을 위해 사용됩니다​UIImagePickerController로 앨범을 열면, 사실상 사용자의 전체 사진 라이브러리에 접근 권한을 요구해야 했습니다.앱 입장에서는 단순히 “사용자가 선택한 사진”만 필요하지만, 시스템은 모든 사진 접근 권한을 앱에 넘겨줘야 했죠.이..

작년인가? 포켓몬 빵 대란이 일어진 사건을 기억하시나요???다들 띠부씰을 얻기 위해서 포켓몬빵 오픈런을 하면서 오박사님이 "ㅅㄱ!"를 외치거나 다른 사람들과 가위바위보까지 하는 사건이 일어났습니다 😱 그러면 포켓몬 빵 사려고 온 사람들은 어쩔수 없이 다시 집으로 갔다가 계속 "아 언제나와!!!" 하면서 주변 편의점 알바들을 괴롭혔죠. 갑자기 왜 포켓몬 빵이냐!! 바로 Observer Pattern을 사용했다면 당신은 오픈런을 하지 않아도 되었기 때문이죠!!!Observer Pattern 왼쪽이 이전에 계속 편의점들을 괴롭혔던 포켓몬 빵 사냥꾼들이었다면, 오른쪽은 편의점에서 지인들에게 "야 포켓몬빵 나왔어 빨리 가져가!!" 하고 알려주는 방식이에요. 이게 바로 Observer Pattern의 핵심입니다!..