Search

TIL

Search
All Posts
프로젝트를 진행하면서 WeatherKit을 사용해야될 상황이 와서 Minimum Deployment를 15.0에서 16.0으로 업그레이드 했다. 하지만 iOS Deployment Target도 자동으로 16.0으로 변경될 줄 알았는데 15.0인 것을 발견하였다. 애플은 왜 번거롭게 두 개로 나누어서 버전을 설정하도록 했을까?

iOS Deployment Target과 Minimum Deployment의 차이

먼저, 간단하게 두 개념을 정리해보자.
•
iOS Deployment Target은 앱을 개발할 때 테스트와 빌드에서 사용할 최소 iOS 버전이다. Xcode에서 프로젝트나 각 타겟별로 이 버전을 설정하게 되며 이 설정에 따라 해당 버전 이상의 iOS에서 앱이 실행될 수 있다. 즉, 개발 과정에서 이 버전을 기준으로 앱이 정상 동작하는지 테스트하게 된다.
•
Minimum Deployment는 앱이 배포될 때 실제로 최소 요구되는 iOS 버전을 정의하는 설정이다. 이 값은 앱이 앱 스토어에 올라가면 그 버전 이상의 iOS 기기에서만 앱을 다운로드하고 실행할 수 있도록 하는 제한을 걸어준다. 보통 이 값은 Info.plist나 프로젝트 설정 파일에 기록된다.

왜 두 개로 나누었을까?

iOS Deployment Target을 따로 설정함으로써 개발자가 더 낮은 iOS 버전을 지원하는 코드 작성과 테스트가 가능하다. 예를 들어, 앱이 새로운 기능을 위해 iOS 16.0을 필요로 하더라도 iOS 15.0에서의 호환성을 유지하고 싶은 상황이 있을 수 있다. 이때, Xcode에서는 iOS 15.0에서도 정상적으로 빌드가 되게끔 처리하면서 실제 배포 시에는 16.0 이상의 버전만 지원하도록 제어할 수 있다.
이렇게 하면 새로운 API나 기능을 도입하면서도 기존의 더 낮은 iOS 버전을 지원하는 코드를 유지하거나 조건부 코드(if #available(iOS 16.0, *))를 추가하여 iOS 버전별로 동작을 다르게 구현할 수 있다.
프로젝트 안에 여러 타겟(Target)이 있을 수 있다. 예를 들어, 동일한 코드베이스에서 일반 사용자용 앱과 테스트용 앱을 따로 빌드할 때 각각의 타겟에 따라 지원하는 최소 iOS 버전이 다를 수 있다.
이때, 각 타겟마다 iOS Deployment Target을 따로 설정하여 타겟별 맞춤 설정이 가능하게 만들 수 있는 것이다. 즉, 타겟마다 테스트 환경이나 지원 버전을 다르게 설정할 수 있어 유연성을 극대화할 수 있다.
iOS Deployment Target vs Minimum Deployment
TIL
Xcode
Git에서 파일 크기 제한으로 인해 fatal: the remote end hung up unexpectedly 오류가 발생한 문제를 해결한 방법을 정리해보았습니다.

문제 상황

git push를 실행했을 때, fatal: the remote end hung up unexpectedly 오류가 발생했습니다. 이는 원격 저장소에서 허용하는 최대 파일 크기 또는 전체 push 크기 제한을 초과했기 때문에 발생한 오류였습니다.

해결 방법

이 문제를 해결하기 위해 Git의 http.postBuffer 설정을 변경하여 push 데이터를 압축하고 크기를 줄였습니다. 이 설정은 Git이 HTTP 프로토콜을 통해 데이터를 push할 때 사용하는 버퍼 크기를 조정해줍니다.
위 명령어를 실행하면 버퍼 크기가 500MB로 설정되어 push할 수 있는 데이터의 크기가 늘어나게 됩니다.
이 설정을 적용한 후, 다시 git push를 시도했을 때 오류 없이 성공적으로 원격 저장소에 데이터를 push할 수 있었습니다.

교훈

Git Push 시 파일 크기 제한 초과 오류 해결하기

Just

just 연산자는 단일 요소를 방출한 다음 완료되는 Observable을 생성한다. 매우 간단하고 직관적인 방식으로 단일 값을 Observable로 변환할 수 있게 해준다.
출력 결과
장점
•
단일 요소를 방출하기에 매우 간단한 연산자임. 이를 통해 특정 값 하나를 방출해야 할 때 직관적으로 사용할 수 있음.
•
단일 값을 방출하고 완료한다는 명확한 목적을 가지고 있기 때문에 코드를 읽기 쉬움.
•
항상 동일한 값과 동일한 순서로 동작하기 때문에 예측 가능성이 높아 테스트와 디버깅에 용이함.
단점
•
단일 값만 방출할 수 있기 때문에 여러 값을 방출해야 하는 경우에는 다른 연산자를 사용해야 함.
•
고정된 값만 방출할 수 있기 때문에 동적 데이터나 조건에 따른 데이터 방출에는 적합하지 않음.

Of

of 연산자는 여러 개의 요소를 순차적으로 방출하는 연산자이다. 주로 짧은 시퀀스를 테스트하거나 특정 값들을 한 번에 방출해야 할 때 유용하다.
RxSwift Operators #1: Creating Operators
TIL
RxSwift

Subjects

Subjects는 Observable이자 Observer 역할을 한다. 따라서 Subject는 데이터를 방출(emit)하고 다른 Observable에서 데이터 이벤트를 받아들일 수 있다. RxSwift에서 제공하는 주요 Subject는 다음과 같다.
1.
Publish Subject
2.
Behavior Subject
3.
Replay Subject
4.
Async Subject

Relays

Relays는 RxCocoa에 포함되어 있으며 기본적으로 Subjects와 비슷하게 동작하지만 onCompleted나 onError 이벤트를 방출하지 않는다.

Publish Subject

Publish Subject는 새로운 구독자가 기존에 발행된 이벤트를 받을 수 없고 구독한 시점 이후의 이벤트만 받을 수 있다.
출력 결과
Publish Subject는 구독 시점 이후의 이벤트만 구독자에게 전달한다. 따라서 “Hello” 이벤트는 구독자가 없어서 아무도 받지 못했다. “World” 이벤트는 첫 번째 구독자가 수신했고 두 번째 구독자는 “World” 이벤트 이후에 구독했기 때문에 “RxSwift” 이벤트만 수신했으며 “RxSwift” 이벤트는 모든 구독자가 수신했다.
장점
Subject와 Relay
TIL
RxSwift
Swift에서 API로부터 JSON 데이터를 받아와 앱 내에서 사용하기 위해 우리는 종종 Decodable 프로토콜을 구현하는 모델을 정의한다. 오늘은 Decodable 구현 시에 매우 유용한 CodingKeys 열거형에 대해 자세히 알아보고자 한다.

CodingKey란?

CodingKey는 Decodable 또는 Encodable 프로토콜을 사용할 때 JSON 키와 Swift 모델의 프로퍼티가 서로 일치하지 않을 경우 이를 연결하기 위해 사용하는 열거형이다. 예를 들어, 서버로부터 받은 JSON 데이터 내에는 stargazers_count라는 키가 있지만 Swift 코드 내에서는 stargazersCount라는 프로퍼티로 사용하고 싶은 경우가 이에 해당한다.

사용 예시

Repository라는 구조체를 정의하고 이를 Decodable 프로토콜에 따라 구현해보자. 이 구조체는 GitHub의 리포지토리 정보를 담고 있으며 다음과 같이 구성된다.
여기서 CodingKeys 열거형은 JSON 키 값인 stargazers_count를 Swift 모델의 stargazersCount 프로퍼티에 할당하도록 명시한다. 이런 방식은 데이터의 키와 프로퍼티 이름이 다를 때 유용하게 사용된다.

CodingKey 사용의 이점

•
명확성
•
유지보수성
•
타입 안정성
데이터와 모델 간의 연결이 명확해지므로 다른 개발자가 코드를 볼 때 이해하기 쉬우며 모델의 프로퍼티 이름이나 JSON 키가 변경되어도 쉽게 대응할 수 있다. 또, 컴파일 시점에 프로퍼티 매핑 오류를 발견할 수 있어 런타임 에러의 가능성을 줄여준다.

결론

Swift에서 JSON 키와 모델 프로퍼티 매핑하기 - CodingKey
TIL
CodingKey

기본 설정 및 UISearchController 구성

•
searchResultsUpdater 프로퍼티를 현재 클래스(self)로 설정하여 사용자가 검색 바에 입력할 때마다 결과 업데이트
•
검색 중에 배경을 흐리게 하지 않음
•
내비게이션 바를 숨기지 않음
•
자동 대문자 비활성화
•
자동 수정 비활성화
•
맞춤법 검사 비활성화

검색 모드

이 계산 속성은 사용자가 검색 중인지 아닌지를 파악하여 해당 상태에 따라 테이블 뷰에 표시될 데이터를 결정한다.
inSearchMode가 true일 때 사용자는 검색을 활성화하고 검색어를 한 글자 이상 입력한 상태이다. 이 경우, SearchController는 filteredUsers 배열을 사용하여 테이블 뷰를 채운다. 이 배열에는 사용자의 검색 조건에 부합하는 사용자 데이터만 포함되어 있다.

사용 이유

이 속성을 사용하는 이유는 사용자가 어떻게 데이터를 보고 싶어하는지, 즉 전체 목록을 보고 싶은지 아니면 특정 조건을 만족하는 항목만 보고 싶은지를 파악하기 위함이다. 이를 통해 앱은 사용자 경험을 개선하고 필요한 정보만을 효율적으로 제공할 수 있다.

isSearchMode를 활용한 동적 테이블 뷰 데이터 처리

검색 및 필터링 기능 구현하기
TIL
UISearchController
filtering
MVVM

Firestore를 통한 비동기적 사용자 데이터 로딩

Firestore 데이터베이스에서 사용자 데이터를 비동기적으로 가져오는 역할을 한다. 이 메서드는 완료 핸들러를 파라미터로 받아 데이터베이스에서 데이터를 성공적으로 로드한 후 필요한 동작을 실행할 수 있게 해준다.
•
타입 메서드(static)로 정의함으로써 UserService의 인스턴스를 생성하지 않고도 호출할 수 있다.
•
COLLECTION_USERS.getDocuments는 Firestore에서 ‘users’ 컬렉션의 모든 문서를 가져오는 비동기적으로 가져온다.
•
guard let 구문을 사용하여 snapshot 객체가 nil인 경우 함수를 더 이상 진행하지 않고 종료한다. 이는 데이터가 없거나 조회에 실패했을 때의 안전한 처리를 위함이다.
•
snapshot.documents.map을 사용하여 각 문서를 User 모델 객체로 변환한다. 여기서 User(dictionary: $0.data())는 Firestore 문서의 데이터를 이용하여 User 객체를 초기화한다.
•
completion(users)는 변환된 사용자 배열을 완료 핸들러를 통해 반환한다. 이를 통해 함수를 호출한 곳에서 사용자 데이터를 사용할 수 있게 된다.
다음 코드는 UserService를 통해 사용자 데이터를 가져오고 UI를 업데이트한다.
fetchUsers 메서드는 UserService를 통해 사용자 데이터를 비동기적으로 가져온다. 이 과정에서 몇 가지 주요 단계를 거친다.
•
데이터 로딩 시작: fetchUsers는 네트워크를 통해 사용자 데이터를 요청한다. 이때 users 배열은 초기 상태에서 빈 배열로 시작된다.
•
데이터 로딩 완료: 비동기적으로 데이터가 로딩 완료되면 이 데이터는 users 배열에 저장된다. 배열은 비어 있던 상태에서 새로운 사용자 정보로 채워진다.
•
UI 업데이트: 데이터가 users 배열에 성공적으로 저장되면 reloadData를 통해 UI를 최신 상태로 갱신해야 한다.
사용자 데이터 처리 및 표시 방법
TIL
@escaping
UITableView
MVVM
delegate는 다른 클래스에 특정 이벤트가 발생했을 때 알리기 위해 사용된다. 예를 들어, LoginController와 RegistrationController 클래스에서 사용자 인증 관련 이벤트를 처리한 후, 이를 앱의 다른 부분에 알리는 데 delegate가 사용된다.
weak 키워드는 객체를 참조할 때 참조 카운트를 증가시키지 않아 강한 순환 참조를 방지하는 데 유용하다. 강한 순환 참조란 두 객체가 서로를 강하게 참조하면서 서로가 메모리에서 해제되지 못하는 문제를 발생시키는 것이다. 따라서 weak로 선언된 delegate는 더 이상 필요하지 않을 때 자동으로 nil이 되어 메모리 누수를 방지할 수 있는 것이다.
1.
신규 회원 등록 화면 전환
회원가입 버튼을 눌러 RegistrationController로 이동할 때 두 컨트롤러는 같은 delegate 객체를 사용하게 되어 회원가입 완료와 로그인 성공와 같은 인증 관련 이벤트를 같은 delegate를 통해 관리할 수 있게 된다. 예를 들어, 어느 한 컨트롤러에서 사용자 인증이 완료되면 설정된 delegate를 통해 앱의 다른 부분에게 이를 알리고 필요한 조치를 취할 수 있다. 이렇게 delegate가 공유되면 코드의 중복을 줄이고 유연성을 제공하며 각 컨트롤러의 관리를 더욱 효율적으로 할 수 있다.
2.
인증 완료 알림
위 메서드에서 사용자가 성공적으로 로그인을 마친 경우, authenticationDidComplete 메서드를 호출한다. 이는 delegate를 통해 다른 컨트롤러에게 인증이 완료되었다는 것을 알린다. 예를 들어, 다음 코드와 같이 메서드를 통해 사용자를 앱의 메인 화면으로 이동시키는 등의 동작을 할 수 있다.
로그인이나 회원가입 등의 인증 과정이 성공적으로 마무리되면 authenticationDidComplete 메서드가 호출된다.
•
이 메서드 내에서 첫 번째로 실행되는 것은 fetchUser 함수를 호출하는 것이다. 이 함수는 서버나 데이터베이스로부터 최신의 사용자 데이터를 불러오는 역할을 수행한다.
•
사용자 정보를 갱신한 후, dismiss를 통해 현재 표시된 로그인 창을 닫고 메인 인터페이스로 돌아간다.
delegate의 역할과 중요성
TIL
delegate
MVVM
1.
FormViewModel 프로토콜
UI 요소가 데이터 변화에 맞춰 어떻게 갱신될지 정의한다. 예를 들어, 다음과 같이 사용 가능하다.
로그인 버튼의 활성화 상태나 배경 색상을 사용자가 입력한 데이터의 유효성에 따라 업데이트할 때 사용하다.
2.
AuthenticationViewModel 프로토콜
인증 관련 뷰 모델의 기본 구조를 정의한다. 이 프로토콜은 로그인이나 회원가입 폼의 유효성을 판단하고 버튼의 배경 색상과 텍스트 색상을 결정하기 위한 속성을 포함한다.
LoginViewModel은 이메일과 비밀번호의 입력 여부에 따라 폼의 유효성을 판단하고 해당 유효성 결과에 따라 버튼의 색상을 변경한다.
3.
AuthenticationDelegate 프로토콜
이 프로토콜을 통해 인증 과정이 성공적으로 끝난 후에 어떤 동작을 할지를 결정할 수 있다. 예를 들어, 사용자가 로그인 버튼을 누르고 인증이 성공적으로 완료되면 authenticationDidComplete 메서드에가 호출되어 앱에서는 해당 사용자를 메인 화면으로 이동시킬 수 있다.
프로토콜의 역할 이해하기
TIL
protocol
MVVM
오늘은 앞으로 시작할 프로젝트를 위해 미리 탭 바와 다크 모드만 간단하게 구현해 봤다. 그동안 MVC 패턴만 사용해 왔지만 최근에 MVVM 패턴을 공부하면서 프로젝트가 커질수록 View의 코드가 너무 복잡해지고 무거워지는 것을 느꼈다. 이에 MVC 패턴처럼 View를 다시 View와 Controller로 나누어 MVC with VM 아키텍처 패턴을 시도해 봤다. 인터넷에서 이 아키텍처 패턴에 관한 글을 찾을 수 없었지만 어쩌면 많은 사람들이 이미 이 패턴을 생각했을지도 모른다. 아마 그럴만한 이유가 있어서 채택되지 않았겠지만 내 성격상 직접 부딪쳐보지 않고서는 알 수 없고 이 과정에서 또 새로운 무언가를 발견하고 탄생시킬지도 모른다고 생각한다. 그리고 아직 아키텍처 패턴에 익숙하지 않은 나에겐 좋은 공부법이 될 거라고 생각한다. 또, UserInterfaceStyle을 토글 버튼으로 제어하고 UserDefaults를 활용하여 앱을 재시작해도 설정값과 버튼 상태가 유지되도록 구현하는 방법에 대해 공부했다.

Model

앱의 다크 모드 활성화 여부를 저장하고 불러오는 역할을 담당한다.
get절에서는 UserDefaults.standard.bool(forKey: "DarkModeEnabled")를 호출하는 것을 볼 수 있다. 이는 DarkModeEnabled 라는 키를 사용하여 다크 모드가 활성화 되어 있는지의 여부를 Bool 값으로 불러온다. 만약, 해당 키에 대한 값이 설정되어 있지 않으면 false를 반환하는 코드이다. set절에서는 UserDefaults.standard.set(newValue, forKey: "DarkModeEnabled")를 호출하는데 이는 newValue로 전달된 값을 DarkModeEnabled 키에 연결하여 UserDefaults에 저장한다. 이 값은 앱을 종료하고 다시 시작해도 유지된다.

View

코드의 간결성을 위해 CocoaPods을 통해 SnapKit을 들고왔다. UISwitch() 클래스로 스위치 버튼을 쉽게 만들 수 있었다. View 코드는 딱히 볼게 없으니 패스.

ViewModel

Properties: 다크 모드의 활성화 상태를 관리하는 모델 인스턴스를 설정하고 이 모델 인스턴스의 isDarkModeEnabled 값을 가져와 isDarkModeEnabled라는 변수에 저장한다. Initialization: ViewModel을 초기화할 때 모델의 인스턴스를 내부 속성으로 설정한다. Actions: 사용자가 다크 모드 버튼을 토글할 때 toggleDarkMode 메서드가 호출된다. isDarkModeEnabled 속성 값을 토글하고 updateInterfaceStyle 메서드를 호출하여 UI 스타일을 업데이트한다. Helpers: updateInterfaceStyle 메서드는 연결된 모든 뷰의 UI 스타일을 현재 모드 설정에 맞게 압데이트한다. 그리고 애니메이션 적용 여부는 매개변수를 통해 결정할 수 있도록 했다.
이렇게 뷰 모델은 모델과 뷰 사이에서 데이터를 관리하고 전달하는 역할을 해준다.

Controller

마지막으로 이 코드는 사용자의 다크 모드 설정을 실시간으로 반영하여 앱의 모든 뷰에 적용하여 보여준다. 애니메이션을 통해 부드러운 전환을 제공하여 사용자 경험을 개선시켰다. 그리고 Controller와 View를 분리함으로써 프로퍼티가 가벼워져 코드가 더 깔끔해 보인다.
다크 모드 토글 버튼 + MVCVM 패턴?
TIL
overrideUserInterfaceStyle
MVCVM