Boost‐SwiftUI‐2024年04月22日(화).txt

---

• 2025年04月22日 화 오후 9:05 ・ 42분 57초
• 김대황 김인환 유정주 이창준 정종인
• 클로버노트를 이용해 회의 내용을 기록하고, Claude를 이용해 요약, 편집했습니다.

---

• iOS는 의존성 주입(DI)을 수동으로 구현해야 하는 반면, 안드로이드는 자동화 도구 제공

  • 안드로이드는 Hilt나 Dagger와 같은 DI 프레임워크가 잘 갖춰져 있음
  • 스코프와 오너 지정만 해주면 ViewModel이 자동으로 주입되는 편리함

• 안드로이드는 구글에서 개발한 라이브러리 생태계가 풍부함

  • Room(SQLite 추상화 라이브러리)은 Swift의 CoreData와 유사하나 사용이 더 간편
  • 문서화가 잘 되어 있고 자료도 풍부하여 개발이 수월함

• Kotlin은 개발자들에게 매우 좋은 평가를 받는 언어로 인식됨
  • 자바보다 현대적이고 간결한 문법 제공
  • "72와 45보다는 있는 게 낫다"는 의견 공유 (특정 기능 비교 언급)

• 다양한 앱의 최소 지원 버전 사례 공유

  • 크림 앱은 iOS 17을 최소 지원 버전으로 설정 (젊은 층 타겟팅)
  • 일반적으로 iOS 15-16이 현재 많이 사용되는 최소 지원 버전

• 최소 지원 버전 상향에 따른 이점과 도전

  • 버전이 높을수록 최신 API 사용 가능하지만 사용자 범위 제한
  • iOS 15는 동작이 때로 이상하게 작동하는 문제 있음
  • iOS 15, 16, 17, 18 모두 동작이 달라 대응이 어려움

• 개발자들의 실용적 접근법
  • 버전 분기 처리를 통해 유사한 UX 제공
  • 기획자와 타협: "애플의 문제로 완벽 구현이 불가능하니, 최신 버전에 맞춰 구현하고 구버전은 유사하게만 제공"
  • 최소 지원 버전이 상향되면 분기 처리 코드 제거

• iOS 16부터 가능한 기능

  • 모든 뷰에 refreshable 수식어 적용 가능
  • iOS 15에서는 List에만 적용 가능했던 제약 해소

• iOS 16.4의 특정 기능 언급

  • 일부 작은 기능들이 부분 버전에서 추가됨

• iOS 17의 주요 기능

  • Observation 매크로와 Observable 프로토콜 도입

• iOS 14부터 도입된 사용자 활동 추적 동의 시스템

  • 사용자 데이터 추적을 위해 명시적 동의를 요구
  • 코드상으로는 간단하지만 비즈니스 영향이 큼

• iOS와 안드로이드의 핵심적 차이

  • iOS: 평균 동의율 35%, 명시적 팝업으로 동의 요청
  • 안드로이드: 약 90% 동의율, 설정에서 직접 비활성화하지 않으면 기본 동의 상태
  • 이 차이로 인해 광고 단가가 두 배까지 차이남

• 동의율 향상을 위한 방법

  • 공식 ATT 알림 전에 맞춤형 광고의 이점을 설명하는 사전 안내 화면 제공
  • "당신의 선택으로 최적화된 서비스를 제공하기 위함" 같은 설명 추가

• 광고 시스템 작동 방식

  • 실시간 입찰 시스템: 앱이 광고 요청 시 실시간 경매로 낙찰된 광고 표시
  • 시간대별 단가 차이: 점심시간(12:30) 같은 트래픽 많은 시간대는 단가 상승

• 타겟팅 제한

  • 미성년자에게는 주류 광고 등 특정 광고 필터링 필요
  • 사용자 생년월일 기반으로 광고 필터링 로직 구현

• 광고 정책이 비즈니스에 미치는 영향

  • ATT 도입 이후 페이스북 주가 급락 사례
  • iOS와 안드로이드 간 광고 수익 격차 발생

• 강력한 iOS 디버깅 라이브러리 소개

  • Objective-C 기반이지만 Swift 지원
  • 바텀 시트 형태로 UI에 오버레이되어 디버깅 정보 제공

• 주요 기능

  • 뷰 계층 및 뷰 사이즈 실시간 확인
  • 네트워크 통신 모니터링
  • UserDefaults 조회
  • 메모리 사용량 확인
  • 파일 브라우저 제공

• 구현 방법

  • 개발 모드에서만 활성화되도록 #if DEBUG 조건문 사용
  • 흔들기 또는 개발자 모드 버튼을 통해 활성화
  • 프로덕션 빌드에는 포함되지 않도록 설정 가능

• SwiftUI에서 뷰 디버깅의 어려움

  • 계층 구조가 복잡하고 많은 중간 뷰가 자동 생성됨
  • UI 하이어라키 도구가 UIKit보다 덜 직관적

• 대안적 디버깅 방법

  • FLEX를 통한 실시간 뷰 사이즈 및 좌표 확인
  • 자체 디버깅 코드 추가

• 네트워크 요청 모니터링 도구

  • API 통신 내용 확인 용이
  • 무료 버전은 보기 제한 있음 (최신 버전은 2개로 제한)

• 기업 사용 시 라이센스 이슈

  • 기업용 제품을 무료로 사용하면 법적 문제 발생 가능
  • "감사 나오면 차라리 창 밖으로 노트북을 집어던지는 게 더 싸다"는 우스갯소리
  • 월 69ドル의 팀 라이센스 비용

• 개발팀 구조 사례

  • iOS 개발자 10명, 안드로이드 개발자 7명 구성
  • iOS 개발자 수요가 더 많은 상황

• 인력 변동 패턴

  • 안드로이드팀은 인원 변동이 잦은 반면, iOS팀은 상대적으로 안정적
  • 인턴 인력 활용 (특정 팀에서는 iOS보다 안드로이드에 인력이 필요한 상황)

• 교육 관련 앱 개발의 특징적 패턴

  • 학기 전에 신기능 개발로 바쁨
  • 학기 중에는 버그 수정이나 광고 관련 작업으로 상대적으로 여유

• 다중 프로젝트 관리 어려움

  • 3개 이상의 프로젝트 동시 담당 시 업무 과부하
  • 라이브러리 전면 리팩토링 작업의 도전성

• 상태 관리 접근법 다양성

  • iOS용 Redux 라이브러리 사용 사례
  • UIKit 기반 앱에서 TCA(The Composable Architecture) 사용
  • SwiftUI 앱에서 다양한 상태관리 접근법

• 최신 기술 적용 트렌드

  • 채널 앱 사례: SwiftUI 기반 전면 리뉴얼
  • 다양한 아키텍처 패턴의 공존