Search

TIL (28)

Search
All Posts

What I Learned

왜 DM 대화방에 상태 머신 패턴을 적용했는가?

DM은 단순히 “있다/없다”가 아니라 여러 상태를 거친다.
상태를 enum으로 정의하면 불가능한 상태 전이를 컴파일 타임에 방지할 수 있다.
만약 상태를 Bool 여러 개로 관리했다면?

왜 DirectMessage에 불변 객체 + 복사 패턴을 적용했는가?

iOS DM 기능 구현 - 상태 머신과 불변 객체 패턴
TIL

What I Learned

1. 왜 Message 모델에 isFromCurrentUser를 계산 프로퍼티로 만들었는가?

메시지를 생성할 때 isFromCurrentUser: true를 직접 넣으면 두 가지 문제가 생긴다.
1.
데이터 불일치: P2P로 받은 메시지를 변환할 때 실수로 true를 넣으면 남의 메시지가 내 메시지로 보임
2.
중복 로직: 메시지 생성하는 모든 곳에서 senderNumber == myNumber 비교를 해야 함
계산 프로퍼티로 만들면 senderNumber만 정확하면 항상 올바른 값이 나온다. 단일 진실 공급원(Single Source of Truth) 원칙

2. 왜 P2PPayload에서 Message로 변환하는 생성자를 만들었는가?

P2P로 데이터를 주고받을 때는 P2PPayload를 사용하고 UI에서는 Message를 사용한다. 두 모델의 역할이 다르기 때문
•
P2PPayload: 네트워크 전송용 (type, targetNumber 등 포함)
•
Message: UI 표시용 (displayName, isFromCurrentUser 등 포함)
변환 로직을 Message 내부에 두면 변환이 필요한 곳에서 Message(from: payload) 한 줄로 끝난다.

3. 왜 메시지 라우터를 별도로 분리했는가?

iOS 퍼블릭 채팅 기능 구현
TIL

What I Learned

왜 Singleton 패턴을 사용했는가?

UserSession은 앱 전체에서 단 하나의 사용자 정보만 관리해야 한다. 여러 인스턴스가 생기면 사용자 번호, 닉네임, 연결 상태가 서로 다른 값을 가질 수 있어 데이터 불일치가 발생한다.
왜 final class인가? 상속을 허용하면 자식 클래스에서 또 다른 인스턴스를 만들 수 있다. final로 막아야 진정한 Singleton이 보장된다.
왜 private init()인가? 외부에서 UserSession()을 호출하면 새 인스턴스가 생긴다. 이를 막아야 shared만 사용하게 강제할 수 있다.
왜 private(set)인가? userNumber는 외부에서 읽을 수는 있어야 하지만, 변경은 UserSession 내부에서만 해야 한다. 외부에서 마음대로 바꾸면 P2P 통신에서 다른 기기와 번호가 맞지 않게 된다.

왜 didSet으로 자동 저장을 구현했는가?

설정 값을 변경할 때마다 save() 함수를 수동으로 호출하면 개발자가 실수로 빼먹을 수 있다. 앱을 재시작했을 때 설정이 저장되지 않은 버그가 발생한다.
왜 Key를 enum으로 관리하는가? 문자열 키를 직접 사용하면 오타가 나도 컴파일러가 잡지 못한다. “user_nicknam” 같은 오타는 런타임에 데이터가 안 불러와지는 버그로 이어진다. enum을 사용하면 컴파일 타임에 오타를 잡을 수 있다.
iOS 사용자 세션 관리 구현
TIL

What I Learned

1. MultipeerConnectivity 프레임워크 이해

iOS에서 Wi-Fi, Bluetooth를 통한 근거리 P2P 통신을 구현할 때 MultipeerConnectivity 프레임워크를 사용한다.

핵심 컴포넌트

연결 흐름

2. iOS 17+ @Observable 매크로

기존 ObservableObject + @Published 대신 @Observable 매크로를 사용하면 보일러플레이트가 크게 줄어든다.
장점:
•
@Published 키워드 불필요
•
View에서 @ObservedObject 대신 일반 변수로 사용 가능
•
성능 향상 (필요한 프로퍼티만 추적)

3. Thread Safety in MultipeerConnectivity

iOS P2P 연결 서비스 구현 (MultipeerConnectivity)
TIL

목차

의존성 주입이란?

클래스나 구조체가 필요로 하는 외부 객체(의존성)를 직접 생성하지 않고 외부에서 전달받는 방식을 말합니다. 쉽게 말해서, 내가 필요한 것을 직접 만들지 않고 누군가에게 받아서 사용한다는 개념입니다. 간단한 예시로 커피 주문 시스템을 통해 알아보겠습니다. 의존성 주입이 없다면 다음과 같이 코드를 작성하게 됩니다.
이렇게 작성하면 CafeCounter와 Americano가 강하게 결합되어 다른 음료로 변경하기 어렵고 테스트하기도 어려워집니다.

Property Injection

Dependency Injection
TIL

목차

세션과 토큰이란 무엇인가?

세션은 사용자가 서버에 로그인할 때, 서버 측에 저장되는 사용자 정보의 임시 저장소이다. 세션을 통해 사용자가 로그인된 상태를 유지할 수 있다. 예를 들어, 사용자가 로그인을 하면 서버는 세션 ID를 생성하고 이를 통해 해당 사용자가 로그인한 상태를 인식하게 된다.
세션과 토큰
TIL
Network

목차

Override란?

Override는 클래스의 메서드, 프로퍼티 또는 서브스크립트를 하위 클래스에서 재정의하는 개념입니다. Override는 주로 상속받은 기능을 커스터마이징하거나 확장할 때 사용되며 다형성(polymorphism)을 구현하는 중요한 수단 중 하나입니다. 메서드나 프로퍼티를 재정의할 때는 override 키워드를 사용하여 명시적으로 나타내야 합니다.

Override의 특징

Override
TIL
override
Swift에서 Equatable, Hashable, Comparable은 자주 사용하는 기본 프로토콜입니다. 이 프로토콜들은 객체 간의 비교 및 고유 식별이 필요할 때 활용되며 컬렉션 타입에서 객체의 정렬, 검색, 중복 확인 등을 쉽게 할 수 있게 합니다.

목차

Equatable

Equatable 프로토콜은 두 객체의 동일성을 확인하기 위한 프로토콜입니다. Equatable을 준수하는 타입은 == 연산자를 통해 두 인스턴스가 같은지 비교할 수 있습니다. 주로 객체의 속성 값이 같은지 확인하여 동일성을 판단합니다.

특징

장단점

Equatable, Hashable, Comparable
TIL
protocol
Swift를 배우면서 프로퍼티(Property)에 대해 접하게 될 텐데, 프로퍼티는 클래스, 구조체, 열거형 등에 속하는 값들을 의미합니다. 크게 Stored Property(저장 프로퍼티), Computed Property(연산 프로퍼티), Type Property(타입 프로퍼티)로 나뉩니다. 이 글에서는 이 세 가지 프로퍼티의 차이점을 설명하고 메모리 상에서 어떤 차이가 있는지 알아보고자 합니다.

목차

Stored Property

저장 프로퍼티는 말 그대로 값을 저장하는 역할을 하는 프로퍼티입니다. 클래스나 구조체의 인스턴스에 해당 값을 저장하고 그 값을 메모리에 유지합니다. 쉽게 말해, 우리가 변수를 선언하고 값을 할당할 때와 같은 역할을 합니다.

예시 코드

Stored, Computed, Type Property
TIL
Property
개발을 하다 보면 특정 객체가 앱 전역에서 하나만 존재해야 하는 경우가 있습니다. 그럴 때 사용하는 디자인 패턴이 바로 '싱글톤(Singleton)'입니다. 싱글톤 패턴은 객체의 인스턴스가 하나만 생성되도록 보장하고 이를 전역적으로 접근할 수 있게 합니다. 이 글에서는 싱글톤 패턴이 무엇인지, 왜 사용하는지, 그리고 실제로 어디에 적용할 수 있는지 알아보도록 하겠습니다.

목차

싱글톤 패턴이란?

싱글톤 패턴은 특정 클래스의 인스턴스가 오직 하나만 생성되도록 보장하는 디자인 패턴입니다. 이 패턴은 주로 전역 상태를 관리하거나 자원의 중복을 방지하고 싶을 때 사용됩니다. 예를 들어 네트워크 매니저, 데이터베이스 연결 객체 등은 애플리케이션 전체에서 하나의 인스턴스로만 존재해야 합니다. 여러 인스턴스가 생성된다면 리소스를 낭비하거나, 데이터를 일관성 있게 유지하는 것이 어려울 수 있습니다.
싱글톤 패턴의 주요 특징은 다음과 같습니다.
싱글톤 패턴의 이해와 활용
TIL
Singleton

목차

클로저란?

클로저는 코드의 일부분을 캡슐화하여 나중에 호출할 수 있는 기능입니다. 흔히 익명 함수나 lamda로 알려져 있으며 함수와 매우 유사하지만 더 간결한 형태로 사용할 수 있습니다. 예를 들어, 배열의 정렬이나 비동기 작업 등에 자주 사용됩니다.

배열 정렬 예시 코드

비동기 작업 예시 코드

Swift의 클로저에 대해 알아보기
TIL
Closure
@escaping
Computer Science
UILabel의 줄바꿈 동작과 관련이 있음.

numberOfLines = 0

•
UILabel은 줄 수에 제한이 없다는 것을 의미함.
•
텍스트가 한 줄에 모두 들어갈 경우에도 UILabel은 줄바꿈을 지원할 수 있도록 약간의 추가 여백을 제공할 수 있음.
•
텍스트가 여러 줄에 걸쳐 있을 때 줄 수 제한 없이 자유롭게 높이가 늘어나므로 레이아웃 시스템이 이를 고려하여 추가 여백을 남길 수 있음.

numberOfLines = 1

•
UILabel은 텍스트를 한 줄로 제한함.
•
텍스트가 한 줄을 초과할 경우 자르고 여백이 최소화됨.
•
한 줄에 딱 맞게 레이아웃이 잡히며 추가적인 줄바꿈을 고려하지 않기 때문에 여백이 최소화되어 더 컴팩트한 레이아웃을 제공함.
numberOfLines = 0과 numberOfLines = 1의 여백 차이
TIL
UIKit
UILabel
스레드는 프로그램이 동시에 여러 작업을 처리할 수 있게 해주는 중요한 개념입니다. 스레드를 사용하면 프로그램이 여러 일을 동시에 처리할 수 있으며 성능을 크게 향상시킬 수 있습니다.

목차

스레드란?

운영 체제가 프로세스 내에서 실행되는 가장 작은 단위입니다. 모든 프로그램은 최소 하나의 스레드를 가지고 있으며 이를 메인 스레드라고 부릅니다. 스레드는 프로세스 내에서 동시에 여러 작업을 처리할 수 있으며 프로세스가 자원을 여러 스레드 간에 공유하면서 작업을 수행합니다.
프로레스를 ‘회사’라고 생각하면 스레드는 ‘직원’이라고 볼 수 있습니다. 회사는 여러 직원이 각기 다른 작업을 병렬로 수행하게 하여 더 많은 일을 할 수 있습니다. 마찬가지로 프로세스도 여러 스레드를 생성해 다양한 작업을 동시에 처리할 수 있습니다.
Thread
TIL
Thread
Computer Science
앱의 생명 주기는 앱이 실행되면서 겪는 상태 변화를 의미합니다. 이 생명 주기는 iOS 시스템에 의해 관리되며 앱이 사용되거나 백그라운드로 이동할 때마다 특정 이벤트가 발생합니다. 이를 통해 앱이 적절한 시점에 필요한 작업을 수행할 수 있도록 도와줍니다.

목차

앱의 생명 주기 상태

앱은 크게 다섯 가지 상태로 다음과 같이 나눌 수 있습니다.
•
Not Running
•
Inactive
•
Active
앱의 생명주기
TIL
UIKit
Lifecycle

목차

뷰 컨트롤러의 생명주기
TIL
UIKit
Lifecycle
앱 스토어에 심사를 제출하니 1분 이내에 다음과 같은 메일이 날라왔다.
App Store 검토를 위한 제출이 성공적으로 완료되었더라도 다음 번 App Store 검토 제출 시 다음 문제를 수정하는 것이 좋습니다. 문제를 수정한 후 App Store Connect에 새 바이너리를 업로드하세요.

4. 보안성 강화

ITMS-91061: Missing privacy manifest - Privacy manifest? / 해결 방법
TIL
Xcode
CocoaPods
프로젝트를 진행하면서 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
UIKit

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
UIKit
Load more