빨간색 배경: 삭제 액션을 나타내는 배경 뷰삭제 아이콘: 휴지통 아이콘으로 삭제 의도를 명확히 표시버튼 영역: 실제 삭제 동작을 처리하는 투명 버튼

Git에서 새 브랜치를 만들 때 어느 브랜치에서 갈라내느냐에 따라 이후 PR에 포함되는 커밋이 달라진다. 1\. develop에서 바로 feature/one 브랜치를 만들면 → PR에는 오직 feature/one에서 만든 커밋만 포함된다. 2\. feature/one에

모의면접 회고:Q: View와 ViewModel 간 데이터 흐름을 어떻게 설계했나요?View와 ViewModel 간의 데이터 흐름은 크게 단방향으로 설계되어 있습니다사용자가 View에서 어떤 행동을 하면, 그 이벤트가 ViewModel로 전달됩니다 타이머를 추가하거나

git commit --amend로 메시지만 수정하려 했는데 staging 되어 있던 작업 중 코드까지 같이 들어가 버림.amend는 메시지만 바꾸는 게 아니라 현재 스테이징된 변경까지 커밋에 포함된다는 걸 배움..해결 과정 1\. git reset HEAD^으로 잘못

파일 매핑• Model/Repository• TimerModel(SwiftData @Model)• SwiftDataManager : TimerRepository (CRUD 담당)• View (UIKit)• TimerViewController(리스트 화면), TimerE

TimerModel에 createdAt: Date 필드를 추가하고, SwiftDataManager가 직접 ModelContainer를 생성하도록 리팩터링하면서 발생. 증상 (Symptoms) • 앱 실행 즉시 크래시 또는 fatalError("Failed to cr

목표 시간의 최소값이 5분인데 실제 동작을 빠르게 검증하려면 5분은 너무 김 → QA/개발 속도가 느려짐TimerEditViewController테스트 모드일 때 피커 옵션을 초 단위로 구성(timeOptions = 30~600초)UI 단위 레이블“분/초)도 토글.T

타이머 생성/수정 화면에서 이름이 비었을 때 저장을 막고 시각적으로 에러를 보여줘야 함.타이머 이름은 15자로 제한하고 한글 조합 시 오동작이 없어야 함단순히 text.isEmpty만 체크하면 한글 조합 중에도 에러가 깜빡거릴 수 있음shouldChangeCharact

타이머 생성/편집 화면에서 사용자가 이모지를 선택할 수 있는 기능 구현textInputMode를 오버라이드해서 이모지 키보드를 우선적으로 표시activeInputModes에서 primaryLanguage == emoji인 모드를 찾아 반환이모지 키보드가 없으면 기본 키

UIKit 기반으로 앱 전반에서 재사용 가능한 커스텀 알럿 컨트롤러를 설계/구현시스템 UIAlertController 대신 디자인 가이드를 반영하고 전환 효과/햅틱/접근성까지 고려한 컴포넌트를 만듦modalPresentationStyle = .overFullScreen

한 거TimerRepository 프로토콜 정의→ fetchAll, insert, update, delete 추상화로 CRUD 규격 확립SwiftDataManager 구현→ TimerRepository 채택, @Dependency(.modelContext)를 이용해 M

기본 높이 113pt에서 값만 보이다가 탭하면 312pt로 확장돼서 UIPickerView로 시간을 고르는 UX 필요.분은 고정 라벨, 숫자만 스크롤. 기본 선택은 50분, 항목은 5분 단위.중앙 흰색 밴드(Selection Band) 제거 → 시스템 피커의 중앙 5행

UILabel이랑 뒤에 배경 뷰를 정렬할 때 이모지가 중앙 정렬이 안 되고 좀 치우쳐 있는 일이 있었음이모지가 폰트마다 baseline/ascender 차이가 큰 편이라 center 정렬만 하니까 시각적으로 좀 안 맞는 듯 보였음특히 iOS에서 이모지가 텍스트 글리프

색상, 폰트 스타일을 디자인 시스템으로 분리해서 구조화함기존에는 Asset에 Color만 등록해서 사용했는데 이번에는 Color와 Font 관련 파일들을 만들어 코드로 일관성 있게 관리할 수 있도록 개선해봄색상은 Assets에만 등록해 사용 :폰트도 별도 스타일 없이

사용자가 선택한 외부 계정을 통해 인증로그인 후 발급되는 토큰을 이용해 서버/DB랑 연동보통 백엔드 서버 필요iOS/애플 생태계에 한정되지 않고 안드로이드, 웹, 크로스 플랫폼까지 확장 가능하나의 앱 계정을 여러 기기/OS에서 동일하게 사용 가능사용자 식별이 명확 →

소규모/짧은 일정 : 1–3명, MVP·해커톤·프로토타입. 빨리 찍고 학습이 목적인 경우.도메인 단순 : CRUD 위주, 복잡한 비즈니스 규칙/정책이 거의 없음.변화 범위가 UI 중심 : 뷰/상호작용이 자주 바뀌지만, 핵심 규칙은 얕음.테스트 범위가 제한적 : 핵심 1

1. 데이터 모델 설계 Alarm 구조체 struct Alarm: Codable, Equatable, Identifiable { let id: UUID var time: String // "오전 7:00" 형태 var subtitle: String // "주중",

iOS질문 : Hot Observable과 Cold Observable의 차이는 무엇인가요?나의 답변 : Cold Observable은 구독을 시작해야 데이터 흐름이 발생하는 Observable이고, Hot Observable은 구독 여부와 관계없이 데이터가 흘러가고

Swift:질문 : @escaping 클로저가 무엇이며, 언제 사용하나요?나의 답변 : swift에서 클로저는 기본적으로 non-escaping이라 함수의 스코프 내에서 실행이 끝나야 하는데 클로저가 함수의 실행이 끝난 이후에도 실행될 수 있는 경우에 @escaping

Alarm 모델을 정의하여 알람에 필요한 정보를 담는다CoreData로 저장알람 리스트 화면 (UITableView or UICollectionView)각 셀에는 알람 시간, 설명, 스위치알람 추가 화면UIDatePicker로 시간 설정요일 선택 (반복 설정)알람 라벨