밀루의 개발 블로구

바야흐로 작년 3월,, 처음 SwiftUI를 접했을 때 익숙한 UIKit과 너무 달라 울고 싶었던 기억이 떠올랐다예를 들어 상태관리라던가 상태관리라던가 상태관리라던가......그 근본적인 이유가 Struct와 Class의 차이인데, 그땐 미처 생각하지도 못했다 많은 차이점들이 있지만 SwiftUI와 UIKit에서 느꼈던 Struct와 Class의 차이를 위주로 정리해보려고 한다 ✅ 메모리 저장 방식의 근본적 차이Class (UIKit) 힙(Heap) 영역에 저장참조(포인터)를 통해 접근여러 변수가 같은 객체를 가리킬 수 있음ARC로 메모리 관리// UIKit 방식class UIViewController { var view: UIView! var title: String?}let vc1 = My..

Swift의 String과 CollectionType(Array, Dictionary, Set) 등은 struct로 구현된 값 타입COW(Copy-on-Write) 최적화 덕분에 값 타입처럼 동작하면서도 실제 복사는 필요할 때만 일어남 var a = [1, 2, 3]var b = a // 힙 메모리를 참조만 공유 (복사 X)b.append(4) // 쓰기 시점에 복사 발생 (COW)b가 수정되기 전까지는 a와 동일한 힙 메모리 참조를 공유b.append(4) 시점에 Swift는 복사본을 생성하고 변경 작업을 수행→ 불필요한 복사를 줄이면서도 값 타입처럼 안전하게 동작

뷰컨트롤러 파일에 모든것을 때려박아 개발한 어제의 나 왜그랬을까? 오늘의 내가 view와 viewcontroller 그리고 tableview로 분리했다.. 처음에 생각한 순서는 뷰 → 테이블뷰 → VC 순으로 분리한다였다단순한걸 먼저 정리하는게 나을거라고 생각했기 때문에!뷰를 분리한 후 빌드해볼 생각은 안하고 신나게 테이블뷰까지 다 분리를 하고 빌드를 하니 !완전히 꼬임 ^^당연한게 뷰 분리 후에도 테이블뷰 로직이 VC에 남아 있어서 애매한 상태로 테이블뷰를 분리했었다 뷰 내에서 독립적으로 동작하는 테이블뷰를 먼저 분리하는 게 맞는 순서였다테이블뷰 → 뷰 → VC 순으로 분리테이블뷰를 먼저 분리하면 해당 뷰 컴포넌트만 띄워보기가 가능하다 가장 중요한건 매 단계 빌드 가능한 상태임을 항상 확인하자 ‼️ ..