애플 폴더블 아이폰 대응은 발표를 기다리지 말고 지금 시작해야 합니다. 고정된 화면 폭과 절대 좌표를 없애고, 안전 영역과 화면 특성, 상태 복원을 기준으로 앱을 다시 점검하면 됩니다.
이 글은 고정 너비나 절대 위치를 사용하는 iOS 개발자에게 맞습니다. 복잡한 입력 양식, 동영상, 편집 작업을 여러 화면 크기에 맞춰야 하는 제품팀과 폴더블 형태의 호환성 검사 항목을 준비하는 품질 검사 담당자도 대상입니다.
주의: 2026년 9월 5일 기준으로 애플은 폴더블 아이폰의 제품명, 접히는 방식, 화면 크기, 전용 개발 인터페이스를 확인하지 않았습니다. 아래 방법은 소문 속 수치를 기준으로 하지 않고 애플이 공개한 배치와 상태 복원 원칙만 사용합니다. 최신 내용은 애플의 배치 설계 지침과 새 소프트웨어 개발 도구 발표 뒤 다시 확인해야 합니다.
애플 폴더블 아이폰 대응의 첫 점검
가장 먼저 화면 폭이나 기기 이름을 조건문으로 사용하는 코드를 찾습니다. 다음과 같은 방식은 접힘과 펼침뿐 아니라 분할 화면, 창 크기 변경, 글자 크기 변경에서도 깨질 수 있습니다.
- 특정 기기 이름에 따라 고정 너비를 넣는 코드
- 화면 폭이 특정 값일 때만 버튼을 보이게 하는 코드
- 이미지와 입력창에 절대 위치를 지정하는 코드
- 스크린샷의 픽셀 크기를 기준으로 여백을 결정하는 코드
- 회전이 끝났다는 가정 아래 화면을 한 번만 만드는 코드
UIKit에서는 제약 조건과 컨테이너 구조를 먼저 정리합니다. SwiftUI에서는 화면 전체 폭을 직접 읽어 여러 분기문을 늘리기보다 사용 가능한 공간에 따라 배치를 선택하는 구조를 만듭니다. ViewThatFits는 여러 화면 구성을 준비하고 현재 공간에 맞는 구성을 선택하는 데 사용할 수 있습니다. 자세한 동작은 SwiftUI의 ViewThatFits 문서에서 확인할 수 있습니다.
고정 화면 폭을 바꾸는 순서
첫째, 화면 폭을 직접 비교하는 조건을 목록화합니다. 둘째, 각 조건이 실제로 해결하려던 문제를 적습니다. 셋째, 문제를 여백, 콘텐츠 우선순위, 표시 방식으로 나눕니다. 넷째, 고정값 대신 컨테이너와 제약 조건으로 옮깁니다. 마지막으로 좁은 공간과 넓은 공간에서 같은 작업이 끝나는지 확인합니다.
이 과정을 거치면 단순히 모든 요소를 크게 늘리는 실수를 피할 수 있습니다. 넓은 화면에서는 목록과 상세 화면을 함께 보여줄 수 있지만, 입력 양식은 오히려 단계별 흐름이 더 안전할 수 있습니다.
안전 영역과 잘림 검사
접히는 위치나 카메라 구멍의 위치를 미리 추측해 빈 공간을 예약하면 안 됩니다. 그런 전용 분기를 넣으면 실제 제품 형태가 달라졌을 때 화면 낭비와 잘림이 동시에 생길 수 있습니다.
다음 영역을 화면 변화와 함께 확인합니다.
- 상단 탐색 영역과 뒤로 가기 동작
- 도구 모음과 하단 작업 버튼
- 전체 화면 동영상의 자막과 재생 조작부
- 키보드가 올라온 뒤의 입력창과 저장 버튼
- 팝업, 메뉴, 경고창의 가장자리
- 카메라 화면과 촬영 전후의 조작 영역
UIKit 화면은 안전 영역이 변할 때 다시 제약을 계산해야 합니다. viewSafeAreaInsetsDidChange 호출을 기준으로 화면을 갱신하는 방법은 UIKit 안전 영역 변화 문서에서 확인할 수 있습니다.
접근성 글자 크기와 확대 표시도 함께 검사해야 합니다. 화면이 넓어졌다고 해서 글자와 조작부를 작게 만들면 사용성이 나빠질 수 있습니다. 애플의 접근성 설계 지침은 읽기와 조작 가능성을 배치 판단의 기준으로 제시합니다.
좁은 화면과 넓은 화면의 정보 재구성
자기 적응형 배치는 모든 요소를 같은 비율로 늘리는 기술이 아닙니다. 먼저 사용자가 반드시 봐야 하는 정보와 나중에 열어도 되는 정보를 나눠야 합니다.
예를 들어 문서 편집기는 다음처럼 설계할 수 있습니다.
- 좁은 공간: 문서 본문과 저장 상태를 우선 표시합니다.
- 넓은 공간: 문서 목록과 본문을 함께 표시합니다.
- 더 넓은 공간: 속성 패널을 추가하되 본문 폭은 읽기 좋은 범위로 제한합니다.
- 다시 좁아진 공간: 패널을 숨기고 같은 내용을 별도 화면으로 이동합니다.
목록과 상세 화면도 같은 기준을 적용합니다. 단순히 글자와 버튼 사이의 간격만 늘리면 시선 이동이 길어지고, 편집 도중 중요한 동작이 화면 가장자리로 밀릴 수 있습니다. 화면 특성에 따라 구조를 바꾸되, 사용자가 진행 중인 작업은 유지해야 합니다.
결정 도구
| 검사 상황 | 우선 선택할 구조 | 피해야 할 방식 | 통과 기준 |
|---|---|---|---|
| 좁은 공간 | 단일 목록 또는 단계형 화면 | 모든 패널을 한 화면에 표시 | 핵심 작업을 중단 없이 완료 |
| 넓은 공간 | 목록과 상세 화면의 병렬 배치 | 콘텐츠를 무조건 확대 | 선택한 항목과 상세 내용이 일치 |
| 공간이 계속 변함 | 컨테이너 기반 구성과 상태 분리 | 화면 생성 때만 배치 계산 | 화면 변화 뒤 입력과 탐색 상태 유지 |
| 동영상이나 편집 화면 | 조작부와 콘텐츠의 우선순위 분리 | 절대 위치로 버튼 고정 | 자막, 재생, 저장 조작부가 잘리지 않음 |
화면 변화 뒤 상태 복원
폴더블 형태를 가정할 때 가장 위험한 문제는 배치가 아니라 진행 중인 작업의 손실입니다. 화면이 다시 만들어져도 다음 상태는 유지되어야 합니다.
- 입력 중인 문서와 저장되지 않은 변경
- 목록의 스크롤 위치
- 재생 중인 동영상의 위치
- 검색어와 필터 조건
- 선택한 목록 항목
- 탐색 단계와 열린 상세 화면
- 키보드가 열려 있던 입력 맥락
SwiftUI에서는 화면 생명주기에 붙은 임시 값과 장기간 유지해야 하는 값을 분리합니다. 화면이나 장면이 다시 만들어져도 필요한 값은 SceneStorage 같은 상태 저장 수단을 검토해야 하며, SceneStorage 문서의 저장 범위와 복원 조건을 확인해야 합니다.
UIKit에서는 상태 복원 식별자와 복원 경로를 정리합니다. 화면 객체가 다시 만들어지는 상황을 전제로 복원 가능한 상태를 저장해야 하며, UIKit 상태 복원 안내를 기준으로 탐색 계층과 편집 상태를 나눠 검사합니다.
중요한 원칙은 상태를 화면 폭에 연결하지 않는 것입니다. “넓은 화면이면 오른쪽 패널이 열림”은 배치 상태일 수 있지만, “사용자가 어떤 문서를 편집 중인지”는 업무 상태입니다. 두 값을 하나의 화면 변수에 넣으면 접힘과 펼침 뒤 복원이 불안정해집니다.
입력, 미디어, 백그라운드의 복합 고장
단일 화면 검사만으로는 부족합니다. 다음 흐름을 이어서 실행해야 합니다.
첫째, 입력창에 내용을 작성합니다. 둘째, 키보드를 올립니다. 셋째, 화면 방향이나 창 크기를 바꿉니다. 넷째, 동영상을 재생하거나 카메라 화면을 엽니다. 다섯째, 앱을 백그라운드로 보냈다가 돌아옵니다. 마지막으로 저장하지 않은 내용과 탐색 위치를 확인합니다.
키보드 프레임이 변할 때마다 화면을 새로 만들면 중복 요청과 입력 중단이 발생할 수 있습니다. UIKit에서는 키보드 프레임 변화 알림 문서를 참고해 조작 영역만 갱신하는지 확인합니다.
SwiftUI에서는 장면 상태 변화와 네트워크 요청을 분리해야 합니다. 장면이 다시 활성화될 때마다 같은 요청이 반복되지 않는지, 동영상 위치가 초기화되지 않는지 확인합니다. ScenePhase 문서의 장면 변화 처리를 기준으로 복귀 동작을 설계하면 화면 재구성과 업무 상태를 분리하기 쉽습니다.
접히는 아이폰 실물 없이 하는 승인 검사
실물 기기가 없어도 대부분의 배치 결함은 찾을 수 있습니다. 다만 접히는 부분의 촉감, 실제 힌지 주변의 터치 반응, 전용 시스템 동작과 성능은 나중에 별도로 확인해야 합니다.
현재 실행할 절차는 다음과 같습니다.
- 시뮬레이터와 개발 환경에서 창 크기를 여러 방향으로 바꿉니다.
- 기존의 작은 화면과 큰 화면 기기에서 같은 작업을 반복합니다.
- 세로와 가로 방향을 바꾸면서 입력, 동영상, 카메라 흐름을 실행합니다.
- 자동 화면 검사로 버튼 잘림, 겹침, 빈 화면, 잘못된 여백을 찾습니다.
- 앱을 백그라운드로 보낸 뒤 편집 내용과 탐색 계층을 확인합니다.
- 글자 크기와 접근성 설정을 바꾼 뒤 같은 화면을 다시 검사합니다.
- 실물 기기가 나온 뒤에만 접힘 영역, 터치 범위, 전용 시스템 동작을 추가 승인합니다.
자동 화면 검사는 특정 픽셀 이미지와 완전히 일치하는지만 보지 말고, 중요한 조작부가 존재하는지와 콘텐츠가 잘리지 않았는지를 함께 판단해야 합니다. 고정 폭을 제거했지만 버튼 순서가 바뀌어 사용자가 저장 동작을 찾지 못하는 경우도 있기 때문입니다.
iOS 화면 품질 검사를 사내 절차로 만들 때는 개발자 코드 검토와 제품팀의 작업 시나리오를 분리해 기록하는 편이 좋습니다. 화면 폭 조건을 없앤 변경, 안전 영역 처리, 상태 저장, 복귀 뒤 중복 요청 여부를 각각 승인 항목으로 두면 원인을 추적하기 쉽습니다. 관련 운영 문서는 Macstripe의 도움말 센터에서 확인할 수 있습니다.
현재 방식과 Macstripe 테스트 환경의 선택
기존의 실물 기기만 사용하는 방식은 기기 예약에 시간이 걸리고, 화면 크기별 반복 검사가 어렵고, 개발자와 품질 검사 담당자가 같은 장비를 기다려야 한다는 단점이 있습니다. 사내 장비를 늘리는 방식도 초기 구매 비용과 관리 공간, 운영체제 갱신 책임이 남습니다.
반대로 Macstripe를 이용한 원격 Mac 테스트 환경은 당장 필요한 기간에 개발 도구와 자동 화면 검사 흐름을 함께 구성하기 쉽습니다. 장기간 같은 부하로 계속 실행하거나 물리 카메라와 직접 연결해야 하는 팀에는 자체 장비가 더 적합할 수 있지만, 출시 전 호환성 검사나 임시 병렬 검증이 목적이라면 원격 환경이 일정 관리와 반복 실행에 유리합니다.
따라서 먼저 가변 크기 회귀 검사를 실행하고, 화면 변화 뒤 상태 복원까지 통과한 뒤 부족한 실물 검증 범위를 정하는 순서가 안전합니다. 추가 장비를 구매하기 전에 Macstripe의 서비스 안내를 확인해 임시 테스트 환경과 자동화 흐름이 현재 팀의 검사 방식에 맞는지 비교해 보시기 바랍니다.
