왕논의 연구실

여러 회사에서 사용하고 있는 Swift Style Guide를 정리했습니다. 1. Apple API Design Guidehttps://www.swift.org/documentation/api-design-guidelines/ 2. Google Swift Style Guidehttps://google.github.io/swift/ 3. The Official Kodeco Swift Style Guide.https://github.com/kodecocodes/swift-style-guide.git 4. Style Sharehttps://github.com/StyleShare/swift-style-guide.git 5. airbnbhttps://github.com/airbnb/swift.git git, g..

🚀 RIBs란 무엇인가?RIBs는 Uber가 만든 모바일 앱 아키텍처야.큰 규모의 앱과 많은 개발자가 함께 일할 때 생기는 문제들을 해결하기 위해 만들어졌어.iOS / Android 크로스 플랫폼 공통 패턴이고복잡한 상태 관리와 많은 기능을 모듈 단위로 깔끔하게 나누는 데 최적화되어 있어.🧠 왜 RIBs를 쓰는 걸까?RIBs는 다음과 같은 장점이 있어:✔ 플랫폼 간 협업 쉬움iOS와 Android 모두 같은 구조를 쓰니까 팀 간 코드 이해와 리뷰가 쉬움.✔ 글로벌 상태가 줄어듦앱 전체의 상태를 전역에서 관리하는 대신, 작은 기능 단위(RIB)별로 상태를 숨김 → 오류 예측이 쉬움.✔ 테스트하기 쉬움각 부분이 독립적으로 구성·분리돼 있어서 단위 테스트가 쉬움.✔ 개발 생산성 향상코드 생성 도구, 정적 ..

이제 MVVM 단계로 넘어가서, MVVM → VIPER로의 변화를 차근히 살펴보겠습니다.이번에는 “왜 MVVM에서 만족하지 못하고 VIPER로 갔는가?” 즉, MVVM의 한계 → VIPER의 필요성을 먼저 알아보겠습니다.🧩 2️⃣ MVVM → VIPER : “확장성과 협업의 한계”🧠 MVVM의 본질MVVM은 분명히 MVC보다 훨씬 나은 구조입니다.ViewController는 화면만 관리하고, ViewModel이 데이터 로직을 담당하니까요.하지만, 프로젝트가 커지고 팀 단위로 개발하기 시작하면곧 두 가지 큰 문제가 드러납니다.⚠️ 문제 1️⃣ — “ViewModel이 커진다 (Massive ViewModel)”MVVM은 Controller의 부담을 ViewModel로 옮겼을 뿐,ViewModel이 또다..

MVC에서 이어서 말하자면 MVC로 작성하다보면 ViewController가 굉장히 커집니다. 🔁 해결 방향 – ViewModel의 등장이 문제를 해결하기 위해 등장한 게 바로 MVVM입니다.핵심은 단순합니다:“Controller(UI)는 단순히 보여주기만 하고,모든 데이터/로직은 ViewModel이 관리하자.”즉, ViewController의 역할을 최대한 줄이자는 겁니다.🧠 MVVM 구조 핵심Model: 데이터View: UIViewModel: View가 표시할 데이터를 가공하고, 이벤트를 처리UI와 ViewModel은 바인딩(binding) 으로 연결됩니다.즉, ViewModel 값이 바뀌면 UI가 자동으로 업데이트됩니다. 구분MVCMVVM핵심 역할Controller가 모든 걸 담당ViewMode..

기본적인 아키텍처 공부를 하기 위해서 처음부터 정리를 해보려고 합니다.MVC 개요MVC (Model - View - Controller) 는 iOS의 기본 아키텍처로, UIKit이 처음 등장할 때부터 존재하던 구조입니다.Model: 데이터, 비즈니스 로직 (예: User, Product)View: 화면 UI, UIKit View들 (UILabel, UIButton 등)Controller: View와 Model을 연결하는 다리 역할 (UIViewController)MVC의 장점간단하다. (학습 곡선 낮음)iOS 프레임워크 구조에 완벽히 녹아있다.소규모 앱에서는 빠르게 개발 가능하다. iOS UIkit을 사용해서 앱을 만들때 만들어지는 가장 기본적인 구조입니다. 문제는 모든 로직인 Controller에 모인..

🌀 RunLoop와 예약된 작업 처리iOS 앱을 개발하다 보면 setNeedsLayout()이나 setNeedsDisplay() 같은 메서드를 쓰는데,이걸 호출해도 화면이 즉시 바뀌지 않는 경험을 한 번쯤 있습니다..이 글에서는 왜 즉시 반영되지 않고 '예약'만 되는지, 그리고 그걸 언제 처리하는지즉, RunLoop가 어떤 역할을 하는지를 정리해보겠습니다.📌 예약만 하고 바로 안 되는 이유?UIKit은 성능을 위해 UI 변경 작업을 즉시 처리하지 않고,한 번에 모아서 처리하는 구조를 사용합니다.이때 사용하는 시스템이 바로 RunLoop입니다.🔁 RunLoop란?RunLoop는 iOS 앱이 실행되는 동안 돌아가는 이벤트 처리 루프입니다.앱은 항상 RunLoop를 돌며 "터치, 타이머, 네트워크, UI..

🔍 두 방식의 차이 요약구분ViewModel을 ViewController에서 주입ViewModel을 View에서 직접 참조구조ViewController가 View와 ViewModel을 연결View가 ViewModel을 직접 소유장점역할 분리 명확, 테스트 용이코드가 간결하고 SwiftUI에 가까움단점코드가 장황해질 수 있음View가 똑똑해지고 재사용성 저하흔한 사례UIKit, 전통적 MVVMSwiftUI, 간단한 화면 구성아키텍처적 해석MVVM with Coordinator / Clean ArchitecturePassive MVVM or MVVM-ish🎯 각 방식의 코드 구조와 의미1. ViewModel을 ViewController에서 관리 (전통적 MVVM)class MyViewController:..

1. 왜 ‘소유권 (ownership)’이 필요할까?Swift 의 값 - 복사(copy) 기반 모델은 편리하지만, 고유-자원(파일 디스크립터, 락, GPU 버퍼 등)은 “한 번에 하나만” 소유되어야 안전합니다. 불필요한 ARC retain/release · 메모리 복사는 성능을 떨어뜨립니다.이를 해결하기 위해 Swift 5.9~5.10에서 “값의 소유권 을 코드에 표현” 하는 세 가지 키워드가 도입되었습니다.키워드의미대표 위치~Copyable (비복사/noncopyable)“이 값은 복사 불가, 이동-전용(move-only)”타입 선언borrowing“잠깐 빌려쓰기”∙읽기 전용, 끝나면 호출자 소유권 유지파라미터·메서드·클로저consuming“소유권을 넘겨받아 소비”∙끝나면 호출자에서 더 못 씀파라미..

📸 이미지는 같은데 용량이 왜 이렇게 다를까?“갤러리에선 3 MB인데 앱 메모리에서는 30 MB?!” 오늘 작업을 하면서 메모리를 너무 많이 차지하는 이슈를 처리하였습니다.이 작업이 처음에 어려웠던 게 논리상 문제가 없는데, 메모리가 너무 많이 사용되었습니다. 계속 메모리 상승하는 부분을 추적하다가 UIImage를 저장하거나 사용하는 곳에서 매우 큰 메모리 상승이 일어나는 것을 보고 찾아보았습니다. PNG·JPG 파일 크기와 UIImage가 차지하는 메모리의 비밀을 아주 쉽게 풀어봅니다.1. 파일 용량 ≠ 메모리 사용량상황내부 형식1 픽셀당 바이트1920×1080 이미지 예시디스크(저장소)PNG·JPG (압축)0.1 ~ 0.5 B (가변)약 1 ~ 3 MB메모리(램)RGBA (비압축)4 B1920×10..

UIView 기준함수호출 시점주로 하는 일비고init(frame:)코드로 View 생성 시View 초기 설정초기화init?(coder:)Storyboard, Xib 로드 시View 초기 설정초기화layoutSubviews()Frame 변경 시서브뷰 레이아웃 재배치AutoLayout 안 쓰거나 커스텀 레이아웃 할 때 주로 사용draw(_:)View 다시 그릴 때직접 그래픽 그리기CoreGraphics, 무거움 주의updateConstraints()constraints 업데이트 필요 시제약조건 동적 업데이트setNeedsUpdateConstraints() 호출 후 실행됨UIViewController 기준함수호출 시점주로 하는 일비고loadView()메모리에 View 로드 시View 직접 생성 (특수 케이스)..