먹고 기도하고 코딩하라

우리 회사 앱은 iOS 12까지 지원하고 있는데, 얼마 전에 12.5 유저가 앱을 켜자마자 바로 강제종료된다는 CS가 들어왔다. 센트리에도, 크래시리틱스에도 에러가 잡히지 않아서 이상하게 생각하고 있었다. 정상적으로 사용했다고 보고된 마지막 사용 로그를 살펴보는데 앱 버전이 달랐다. 그렇다면 업데이트된 버전 사이에서 뭔가 달라졌을 텐데 하는 생각이 들어 iOS 12 테스트 폰을 빌려 빌드를 해봤다. 과연 앱이 실행하자마자 바로 강종됐다. 콜스택에 뭐가 쌓인 것도 아니고, AppDelegate의 가장 첫 메소드에 찍은 브레이크포인트도 안 타고 그냥 강제종료. Thread 1: EXC_BAD_ACCESS 와 나에겐 별 도움이 되지 않는 주소값을 함께 제공하는 차가운 메시지와 함께… 지푸라기라도 잡는 마음에 ..

iOS 17에서 기존과 같이 위젯을 만들었을 때, 크게 2가지 문제점이 있다. 위젯 위아래의 마진으로 레이아웃 깨짐 디버그 모드에서 설치 안됨 1. 위젯 위아래의 마진으로 레이아웃 깨짐 대응을 하지 않은 경우, iOS 17에서의 위젯은 위아래로 마진이 생긴다. 그래서 기존에 설정해둔 레이아웃이 깨지게 된다. 다행히 iOS 17 이상에서 이 마진을 무시할 수 있다. Widget의 body, WidgetConfiguration에서 다음과 같이 .contentMarginDisabled()를 적용해주면 마진을 무시하게 된다. var body: some WidgetConfiguration { let configuration = StaticConfiguration(kind: kind, provider: Provid..

올해 9월에 Xcode 15가 정식으로 배포되면서 집에서도 회사에서도 Xcode 버전을 올렸다. 메이저 업데이트를 한 뒤 마이너 업데이트를 앞두고 이슈를 처리하던 중.. 마스터 브랜치를 풀받았는데, 빌드는 성공하지만 Unable to Install 하면서 기기에 앱이 설치되지 않았다. 에러 메시지는 다음과 같았다. the bundle info.plist does not contain a cfbundleversion key or its value is not a string. 버전이 없다니? Info.plist와 프로젝트 Identity 탭을 확인해봤지만 프로젝트 버전은 멀쩡했고 마케팅 버전까지도 잘 살아 있었다. 클린 빌드도 해보고 맥도 재시동해봤지만 문제는 여전했다. 마스터 브랜치에 뭔가 있었던 건 아..

큰 업데이트 전에는 사내 배포 및 외부 고객센터에 앱 배포가 필요한 경우가 있다. iOS의 경우, 앱스토어에 등록되지 않은 개발용 앱인 경우 프로파일에 등록된 기기들만 앱을 설치할 수 있다. 사무실 상근 임직원분들 외에도 직접 만날 수 없는 고객센터 근무자 분들의 폰을 등록해야 하는 경우가 발생한다. 또한 폰을 등록한 후에도 프로비저닝 업데이트 후 사내 배포를 위해 따로 빌드가 필요하다. 이번 주는 사내 배포용 앱을 빌드하고, 외부 고객센터 기기 등록하는 작업을 하다가 난항을 겪었다. 사내 컨플에 공유한 문서인데 좀 더 일반적으로 수정해서 블로그에도 올린다. 오라.. 달콤한 프로비저닝 업데이트여.. 🤯 사무실 외부의 기기 등록 프로파일에 등록되지 않은 iOS 기기들을 등록하는 일은 내가 도맡아 했는데, ..

Observable 구독하는 클로저에서 이벤트가 발생하면 UI를 업데이트해주는 코드가 있었다. 그런데 observe를 메인 스레드가 아니라 다른 스레드에서 하고 있어서 이벤트를 받아 onNext 하면 메인 스레드가 아닌 데서 UI 조작한다고 앱이 강제종료되는 이슈가 생겼다. .observe(on: MainScheduler.Instance)를 체이닝에 추가해서 메인 스레드에서 관찰하도록 변경해줌으로써 이슈는 해결했다. 그런데 문득 궁금해졌다. 그러니까, onNext에서 할 행동을 DispatchQueue.main.async { } 블록으로 감싸줘도 되는 게 아닌가? 이 둘은 퍼포먼스상으로 유의미한 차이가 있을까? 먼저 .observe(on: MainScheduler.Instance) 메소드부터 살펴보자. ..

MVC가 Massive View Controller라는 농담이 있다. 코코아 MVC에서는 뷰컨이 뷰의 역할도 하고 컨트롤러의 역할도 하기 때문에 뷰컨이 하는 일이 너무 많아지기 때문이다. 전통적인 MVC에서 모델, 뷰, 컨트롤러 3가지는 다음과 같은 일을 한다. Model : 비즈니스 로직 수행에 필요한 데이터 구조를 정의하고 담는 역할 View : 유저에게 보일 뷰를 구성하고, 사용자 인풋을 받고 컨트롤러가 주는대로 아웃풋을 그리는 역할 Controller : 뷰와 모델의 중간 다리 역할로, 뷰에서 일어나는 사용자 인풋은 컨트롤러에 전달. 컨트롤러는 인풋으로부터 모델에 반영하고, 모델 변화에 따른 아웃풋을 뷰를 업데이트하는 역할. MVVM은 뷰컨이 뷰의 역할만 할 수 있도록 하고, 뷰모델이 MVC에서 ..

iOS 앱의 아키텍처를 잡는 문제는 아니고, 프로젝트가 있으면 파일을 어떻게 그룹별로 관리하는 게 좋은지에 대한 글이다. 사실 회사 코드의 경우 이미 쓰임새에 맞춰 그룹별로 잘 나눠져 있어 크게 고민할 건 없는데, 개인 프로젝트를 할 때면 고민이 생긴다. 뷰 컨트롤러끼리는 같은 그룹에 둬야 하나? 아니면 같은 화면을 구성하는 것들을 같은 그룹에 둬야 하나? 그룹 구조 잡는 일은 별 거 아니라고 생각할 수도 있지만 화면이 많아지고 파일이 많이 생기다 보니 미리부터 고민을 좀 해둘걸 하는 생각이 들어서 지금이라도 쓴다. 실은 미래의 내가 참고하라고 쓰는 글에 더 가깝다. 서로 연관되어 있거나, 공통점이 있는 것들을 같은 그룹에 넣는다. 예를 들면, 같은 모듈이나 화면 등을 이루는 모델, 뷰모델, 뷰컨트롤러는..

노치 있는 status bar나 home indicator 부분까지 색상이 깔린 디자인을 받을 때가 종종 있다. 폰마다 status bar, home indicator 영역이 조금 다르다. 예를 들어, 홈 버튼이 있는 아이폰 SE 2, 3세대 등의 폰은 아예 home indicator 영역이 잡히지 않는다. 무조건 화면 아래에 constraint를 깔고 constant 34 주는 게 능사가 아닐 수 있다는 이야기다. 우선 status bar 배경색을 주는 방법부터 살펴보자. 2가지 방법이 있다. (1) statusBarManager 사용 첫 번째는 windowScene의 statusBarManager를 사용하는 것이다. UIApplication의 windows 중 첫 번째 window의 windowSce..