Neoself의 기술 블로그

이 글은 제가 개발한 TyTE 앱의 캘린더 위젯 구현 과정을 공유하기 위해 작성한 글입니다. WidgetKit을 처음 사용하고자 하는 개발자에게 도움이 되었으면 합니다.    1. WidgetKit의 핵심 구성요소 이해 struct CalendarWidget: Widget { let kind: String = "CalendarWidget" var body: some WidgetConfiguration { ... }}가장 먼저 위젯을 구현하기 위해서는 아래 요소들로 구성된 Widget 프로토콜을 최상단 뷰에 상속해야합니다.- 필수) WidgetConfiguration을 반환하는 body 속성- 필수) kind 속성: 위젯의 고유 식별자 역할 / 인스턴스 구분, 상태 관리, 업데이트 처..

이 글은 SwiftUI 관련 WWDC 세션들의 주요 내용을 기초부터 심화까지 포괄적으로 다루고 있습니다. SwiftUI를 처음 접하시거나, 익숙치 않은 분들에게 도움이 되었으면 합니다. 0. 목차더보기1. SwiftUI 소개1.1 SwiftUI의 핵심 특징1.2 저수준 API1.3 앱 정의에도 사용되는 SwiftUI2. 선언형 UI의 특성2.1 예측 가능한 상태 관리2.2 스레드 안정성2.3 성능 저하 요소 최소화2.4 넓은 범위의 적응성(Adaptivity)3. SwiftUI의 상태 관리3.1 상태 기반 UI 뷰 업데이트 사이클3.2 Property Wrapper와 의존성 관리3.3 Single Source of Truth (SSOT)3.3.1 데이터 모델과 UI(ViewModel)의 분리3.3.2 데..

최근 iOS 앱의 소셜 기능 개발 과정에서 복잡한 API 호출 체인을 다루게 되었습니다. 사용자의 피드를 구성하기 위해 여러 API를 순차적으로 호출하고 데이터를 조합해야 했는데, Combine을 사용한 기존 접근 방식에서 여러 한계점을 경험했습니다. 이 글에서는 우리가 겪은 문제점들과 Swift Concurrency로의 전환을 통해 이를 해결한 과정을 공유하고자 합니다. 1. 기존 코드의 구조와 한계점소셜 피드를 구현하기 위해 다음과 같은 연쇄적인 API 호출이 필요했습니다:func fetchFriendsWithCalendarData(yearMonth: String) { isLoading = true // 1. 친구 목록 가져오기 socialService.getFriends() ..

앱의 QA 과정 도중, TagEditView에서 태그를 수정하게될 경우, 로딩 인디케이터가 무한히 표시되며 다른 상호작용이 동작하지 않는 특이한 현상을 발견했습니다. 로딩 인디케이터가 표시된 이후, 다른 상호작용에 의한 뷰업데이트가 진행되지 않았던 것을 미루어 보았을때, UI 업데이트를 책임지는 메인쓰레드를 다른 작업이 항시 점유하고 있다는 것을 예상해볼 수 있었습니다. 따라서 XCode에서 제공하는 Instrument 도구의 Time Profiler 기능을 활용해 메인쓰레드를 점유하는 작업이 무엇인지 프로파일링해보았습니다.1. XCode Instrument 툴을 활용한 뷰 재구성 이슈의 시작점 파악1.1 쓰레드 점유 작업 확인그 결과, TagEditView에서 태그정보에 대한 변경이 완료되는 17초 ..

기존 TyTE 앱의 회원가입 플로우에서는 영어 username만을 사용할 수 있도록 하였는데요. MVP 모델 출시 이후, 한글 닉네임도 허용할 수 있게 해달라는 피드백을 반영해, 이번 1.1버전 업데이트를 통해 사용자 이름에 한글도 허용하도록 정책을 변경하게 되었습니다.이를 위해 사용자 이름의 유효성을 판단하는 usernamePredicate를 수정하였는데, 이 변경이 회원가입 플로우에 영향을 주지 않는지 확인하기 위해 XCTest를 활용, 단위 테스트를 작성 및 검증해보고자 했습니다. 1. 테스트 설계 접근 방식OnboardingView의 핵심기능인 회원가입 플로우를 검증하기 위해, 테스트가 필요한 핵심요소들을 정의했습니다. 1.1 검증 대상 정의1. 필드별 유효성 검사- Username- Passwo..

본 게시글은 Keychain, UserDefaults를 활용하여 로그인 여부를 영구적으로 관리하고 Combine을 통해 뷰를 업데이트하는 로그인 플로우 고도화 과정을 공유하고자 작성된 글입니다. 로그인 플로우 파악에 더 나아가, 자동로그인 및 자동 로그아웃 기능을 고려하시는 개발자 분들께 도움이 되시리라 생각합니다.1. 기존 로그인 플로우의 한계우선 제가 여태껏 구현해왔던 로그인 및 로그아웃 플로우를 간단하게 소개드리겠습니다.AppState라는 싱글톤 패턴 기반의 클래스를 환경객체로 앱에 적용한 후, 로그인 여부 불린값 isLoggedIn을 통해 보이는 뷰를 관리하였습니다. class AppState: ObservableObject { static let shared = AppState() ..

XCode에서는 애플워치, 아이폰 등, 애플 생태계에 있는 기기들을 Simulator로 테스트 및 디버깅이 가능합니다. 하지만, 애플워치에서의 심박수 측정, WCSession 통신 등의 동작은 Simulator만으로는 테스트가 힘듭니다. 따라서 저는 여태껏 TestFlight로 앱을 배포하여 내부 테스트를 통해 로직 검증을 반복해왔었습니다... 이러한 과정을 반복하면서 디버깅을 하다보니, 아래 문제점들이 있었습니다.매번 앱스토어에서의 앱 처리 절차와, 테스트 플라이트 업데이트 등 많은 시간이 불필요하게 소요이미 배포가 된 앱을 테스트하는 것이기에 콘솔 출력을 통한 디버깅 불가능func syncPendingData(forced: Bool = false) { // 디버깅을 위한 메시지 iOS로 전송 ..

Testflight를 통해 실제 뮤지컬관람환경에서 실시간 심박수 측정 기능을 사용한 결과, WatchOS에서 전송한 분간 최대 심박수 데이터들에 대한 로그기록을 서버를 통해 확인할 수 있었습니다.(사실 가독성은 구려서 안 보시는게 눈건강에 더 나을 수도 있습니다. 백엔드는 잘 몰라서, 구현하기에 바빴습니다... )더보기보시면 아시겠지만, 오후 9시 35분부터 오후 10시 6분 사이의 데이터가 누락이 되는 이슈가 있었습니다. 당시 타임라인을 추적해본 결과, 심박수 데이터를 측정하는 전체 2시간 반동안 애플워치의 배터리를 16% 소모하였으며, 9시 35분부터는 배터리가 10% 이하로 떨어지면서 애플워치가 저전력 모드로 전환돼, 앱 내부 로직이 아예 막혀 서버로 데이터 전송이 되지 않았음을 확인할 수 있었..

최근에 UIKit + MVC 아키텍처 패턴으로 작은 프로젝트를 만들게 되었습니다. 이를 만들어보면서 고민했던 아키텍처 구성 과정을 적어보았습니다.MVC는 뭐죠??MVC 패턴의 사전적 의미를 먼저 보겠습니다.디자인 패턴중 하나로, Model, View, Controller의 약자입니다. 사용자가 Controller를 조작하면, Controller는 Model 레이어를 통해서 데이터를 가져오고, 그 정보를 바탕으로 View를 업데이트하는 과정을 통해 앱이 동작하는 구조라고 이해하면 됩니다. Model: 애플리케이션의 정보, 데이터를 처리하는 레이어데이터베이스 혹은 Core Data 프레임워크를 활용한 데이터 처리 CRUD 메서드와 같이 정보들의 가공을 책임지는 컴포넌트가 이에 해당됩니다.View: 앱 사용자..

오픈소스를 활용하지 않고 iOS 앱 개발 시, 내부에 데이터를 저장하여 활용하는 방법은 크게 2가지가 있습니다.UserDefaultCoreData비밀번호나 사용자 이메일 주소와 같은 단순한 키-값을 저장하는 데에는 이전에 말씀드렸던 UserDefaults나 Keychaion이 더 적합합니다. 하지만, 복잡한 데이터 관계가 필요하거나, 데이터의 변경에 대한 롤백, 즉 변경 추적이 필요한 경우에는 Core Data가 더 적합한 프레임워크가 됩니다.Core Data가 그래서 뭐죠?Core Data는 객체 그래프 관리자로서, iOS 어플리케이션에서 데이터를 구조화하고 유지하기 위한 프레임워크입니다. 여기서 Core Data는 DB 그 자체가 아닌, 객체 그래프, 즉 아래와 같이 객체들 간의 관계를 나타내는 연결..