토스 같은 금융 앱은 하루에 수백만 건의 알림을 보냅니다. 송금 완료, 카드 결제, 이벤트 참여, 마케팅까지.....만약 이걸 그냥 "생각날 때마다" 보낸다면? 사용자는 알림 폭격에 스트레스 받아서 앱 삭제할 겁니다. 저도 쓰잘데기 없는 알람이 많은 앱들은 성가셔서 대부분 삭제했어요... (죄송합니다 개발자분들)실제로 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는 이미지를 그리죠.여기서 중요한 점은 래스터화는..

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

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