UIScreen.main을 더는 쓸 수 없나요? 2026년 iOS 27 대체 방법은 어떻게 고를까요

화면 크기를 읽던 UIKit 코드가 창 크기 조정 뒤 레이아웃을 잘못 계산합니다.
iOS 27에서 UIScreen.main 대체 방법은 하나로 통일하지 말고, 데이터 의미에 따라 UIWindowScene, view.bounds, effectiveGeometry, traitCollection으로 나누어 적용해야 합니다.

이 글은 UIScreen.main과 화면 bounds를 많이 사용하는 UIKit 개발자를 위한 글입니다.
팀의 API 선택 규칙을 정해야 하는 아키텍처 담당자, Xcode 27과 iPhone Mirroring, iPad 창 동작을 검증하는 QA와 CI 담당자도 대상입니다.

마지막 업데이트: 2026년 8월 26일. 기술 내용은 Apple Developer의 WWDC26 Session 278과 관련 UIKit 문서를 기준으로 확인했습니다.

먼저 나눠야 할 것은 API가 아니라 데이터 의미입니다

UIScreen.main을 다른 전역 화면 객체로 바꾸는 방식은 가장 빠르게 보이지만, 문제를 그대로 옮길 가능성이 큽니다. 기존 호출이 실제로 요구하는 값은 대체로 다음 네 가지입니다.

• 화면 장치 속성: 실제 화면의 배율이나 장치 관련 정보가 필요한 경우입니다.
• 현재 장면의 기하 정보: 장면에 연결된 창의 유효 영역과 창 관리 상태를 다루는 경우입니다.
• 컨테이너의 사용 가능 공간: 뷰를 어디에 어떻게 배치할지 결정하는 경우입니다.
• 현재 특성 환경: 크기 특성, 표시 배율, 글자 크기 같은 환경에 반응하는 경우입니다.

Apple은 UIScreen.main을 전역 기준으로 사용하는 대신 현재 문맥에서 화면을 얻는 방향을 제시하고 있습니다. UIScreen.main의 현재 상태와 대체 방향을 먼저 확인한 뒤, 호출부가 어느 문맥의 값을 필요로 하는지 판정해야 합니다.

장면과 뷰를 기준으로 선택하는 표

화면 장치가 필요할 때만 UIWindowScene을 따라가세요

다중 창이나 외부 화면이 있는 환경에서는 UIScreen.main이 현재 작업 중인 창을 의미한다고 보장할 수 없습니다. 화면 장치 속성이 정말 필요하다면 다음처럼 현재 객체에서 문맥을 거슬러 올라가야 합니다.

guard let scene = view.window?.windowScene else {
    return
}

let screen = scene.screen
let scale = view.traitCollection.displayScale

여기서 scene.screen은 현재 창이 연결된 화면을 가리킵니다. displayScale은 현재 뷰의 특성 환경에서 읽습니다. 두 값을 같은 대상으로 취급하면 안 됩니다. UIWindowScene 문서는 장면과 화면의 관계를 구분해 설명합니다.

뷰가 아직 화면에 올라가지 않았다면 view.window가 nil일 수 있습니다. 초기화 시점의 도구 코드에서 이 값을 강제로 얻으려 하면 잘못된 기본값을 넣거나, 호출 자체를 실패 처리하게 됩니다.

이때의 우선순위는 다음과 같습니다.

• 화면 장치 정보가 필요하면 화면에 연결된 시점까지 계산을 늦춥니다.
• 연결 전에도 계산해야 한다면 화면 문맥을 함수 인자로 받습니다.
• 전역 헬퍼가 UIScreen.main을 몰래 호출하지 않는지 확인합니다.
• 외부 화면과 다중 장면을 지원하지 않는 코드라면 그 제한을 문서로 남깁니다.

레이아웃은 전체 화면보다 사용 가능 공간을 따라갑니다

다음 코드는 창 크기 조정 환경에서 위험합니다.

let width = UIScreen.main.bounds.width

if width < 600 {
    showCompactLayout()
}

기기 화면의 너비와 앱이 현재 얻은 창의 너비는 다를 수 있습니다. iPad의 조정 가능한 창에서는 분할된 창만 앱에 주어질 수 있습니다. iPhone Mirroring에서도 물리 기기의 화면 크기를 그대로 앱의 배치 공간으로 사용한다고 가정하면 안 됩니다. Apple의 UIView.bounds 문서는 bounds가 해당 뷰의 좌표 공간과 크기를 나타낸다는 점을 기준으로 삼습니다.

뷰 내부 배치는 이렇게 바꾸는 편이 맞습니다.

let width = view.bounds.width

if width < compactThreshold {
    showCompactLayout()
}

compactThreshold 자체를 특정 기기 화면 너비에서 복사하지 마세요. 제품의 실제 레이아웃 요구를 기준으로 정하고, 창 크기 조정 테스트에서 경계값을 찾아야 합니다.

반대로 장면 단위의 창 정책을 다루는 코드는 effectiveGeometry가 더 적합합니다.

guard let scene = view.window?.windowScene else {
    return
}

let sceneFrame = scene.effectiveGeometry

이 값으로 자식 뷰의 모든 배치를 계산하면 안 됩니다. effectiveGeometry 공식 문서가 설명하는 것처럼, 이 API는 장면 수준의 유효한 기하 정보를 다루는 선택지입니다.

확대율, 크기 특성, 방향은 서로 다른 지표입니다

오래된 코드에는 다음과 같은 혼합 판단이 자주 남아 있습니다.

if UIScreen.main.scale == 3 && UIDevice.current.orientation.isPortrait {
    usePhoneLayout()
}

이 한 줄에는 세 가지 문제가 있습니다.

• 전역 화면에서 확대율을 가져옵니다.
• 기기 방향을 창의 방향처럼 사용합니다.
• 확대율을 레이아웃 분기의 기준으로 사용합니다.

올바른 기준은 목적에 따라 달라집니다.

• 그림이나 픽셀 단위 캐시가 목적이면 현재 특성 환경의 displayScale을 사용합니다.
• 뷰 배치가 목적이면 view.bounds와 제약 조건을 사용합니다.
• 환경 변화에 반응해야 하면 현재 traitCollection을 관찰합니다.
• 창 관리가 목적이면 장면의 기하 정보를 사용합니다.
• 방향 값은 카메라, 센서, 회전 애니메이션처럼 정말 방향이 필요한 기능에만 남깁니다.

Apple의 특성 환경 변화 대응 문서는 특성이 바뀔 때 현재 환경에 맞춰 인터페이스를 갱신하는 흐름을 설명합니다. 세로 방향이라고 해서 반드시 좁은 창이라는 뜻은 아닙니다. 넓은 세로 창과 좁은 가로 창이 모두 가능하므로 방향을 크기 특성의 대체값으로 쓰면 안 됩니다.

자주 묻는 이주 판단

iOS 27에서 UIScreen.main은 무엇으로 바꿔야 하나요?

하나의 API로 바꾸면 안 됩니다. 화면 장치의 정보가 필요하면 현재 UIWindowScene의 screen을 사용합니다. 뷰 배치에는 view.bounds나 부모 컨테이너의 크기를 사용합니다. 확대율과 크기 특성은 현재 뷰 또는 뷰 컨트롤러의 특성 환경에서 읽습니다. 장면 전체의 창 관리가 목적일 때만 effectiveGeometry를 선택합니다.

창에서 실제로 쓸 수 있는 크기는 effectiveGeometry와 view.bounds 중 무엇으로 읽나요?

일반적인 화면 배치에는 view.bounds가 우선입니다. 이 값은 해당 뷰가 실제로 배치되는 좌표 공간을 나타냅니다. 반면 effectiveGeometry는 UIWindowScene 수준에서 창의 유효한 기하 정보를 다룰 때 적합합니다. 부모 뷰 안의 자식 배치를 장면 전체의 값으로 계산하면 여백과 분할 창에서 오차가 생길 수 있습니다.

iPhone Mirroring에서 displayScale은 어디서 읽어야 하나요?

현재 화면 장치의 확대율을 직접 알아야 한다면 화면에 연결된 뷰에서 traitCollection.displayScale을 읽는 편이 안전합니다. 장면이나 뷰가 아직 window에 연결되지 않았다면 먼저 연결 시점을 보장해야 합니다. iPhone Mirroring의 사용 조건을 확인하고, 미러링 화면의 표시 크기를 기기 화면의 고정값으로 가정하지 마세요.

이전 프로젝트에서 UIScreen.main을 잠시 남겨 둬도 되나요?

화면 장치의 공통 정보만 읽는 코드라면 단기간에 동작이 유지될 수 있습니다. 그러나 창 크기, 방향, 레이아웃 분기에서 계속 사용하면 iOS 27의 다중 창과 크기 조정 동작을 잘못 계산할 위험이 있습니다. 호출부를 먼저 분류하고, 문맥을 전달하기 어려운 전역 유틸리티부터 별도 인터페이스로 감싸는 방식이 안전합니다.

Xcode 27에서 API를 바꾼 뒤 창이 찌그러지지 않는지 어떻게 확인하나요?

고정된 기기 화면만 확인하지 말고 Xcode 27의 창 크기 조정 테스트에서 넓은 창과 좁은 창을 직접 만들어야 합니다. iPhone Mirroring과 iPad 창에서도 같은 화면을 반복합니다. 레이아웃뿐 아니라 확대율 기반 그림, 캐시 크기, 터치 좌표 변환도 함께 확인합니다. 실패한 창 크기와 특성 환경을 기록하면 재현 가능한 회귀 항목이 됩니다.

호출부의 의미에 따라 이주 비용을 다르게 계산하세요

모든 UIScreen.main 호출을 같은 난이도로 잡으면 일정이 틀어집니다. 다음 네 등급으로 나누면 리뷰와 작업 배정이 쉬워집니다.

• 바로 바꿀 수 있는 호출: 현재 뷰나 컨트롤러가 이미 있고, 그 뷰의 확대율만 필요합니다.
• 장면 계층으로 올려야 하는 호출: 외부 화면, 창 위치, 장면 단위의 정책을 판단합니다.
• 뷰 계층으로 내려야 하는 호출: 화면 너비로 계산하던 배치, 간격, 줄바꿈을 결정합니다.
• 업무 판단을 다시 설계해야 하는 호출: 방향이나 기기 종류를 사용해 상품 흐름, 권한, 기능 노출을 나눕니다.

호환되는 이전 시스템을 함께 지원한다면 문맥 접근을 작은 래퍼로 감싸는 방법이 좋습니다. 새 전역 싱글턴을 추가하는 방법은 피해야 합니다. 래퍼의 이름보다 중요한 것은 반환값의 소유 문맥입니다. 코드 리뷰에서 다음 질문에 답하지 못하면 교체가 끝난 것이 아닙니다.

• 이 값은 어느 장면에 속합니까?
• 어느 창에 연결되어 있습니까?
• 어느 뷰의 좌표 공간입니까?
• 특성 환경이 바뀌면 다시 계산합니까?
• 연결 전 상태를 어떻게 처리합니까?

코드 리뷰에 바로 쓰는 판정표

Xcode 27 검증은 창 크기와 렌더링 결과를 함께 보세요

Xcode 27에서 창을 조정할 수 있다는 사실만 확인해서는 부족합니다. WWDC26 Session 278에서 설명한 현재 문맥 기반 접근을 실제 회귀 항목으로 바꿔야 합니다.

다음 목록을 이주 완료 조건으로 사용하세요.

• [ ] UIScreen.main.bounds가 레이아웃 분기에 남아 있지 않은지 검색합니다.
• [ ] UIScreen.main.scale 사용부를 현재 특성 환경의 확대율과 비교합니다.
• [ ] 모든 화면 장치 조회가 현재 UIWindowScene과 연결되어 있는지 확인합니다.
• [ ] 뷰 배치 계산이 해당 뷰 또는 부모 컨테이너의 크기를 사용하는지 확인합니다.
• [ ] 장면 기하 정보와 자식 뷰 좌표 공간을 분리합니다.
• [ ] 뷰가 window에 연결되기 전 호출되는 경로를 테스트합니다.
• [ ] Xcode 27에서 창 폭을 바꾸며 제약 조건, 줄바꿈, 스크롤 영역을 확인합니다.
• [ ] iPhone Mirroring에서 확대율 기반 그림과 캐시를 확인합니다.
• [ ] iPad 창에서 방향과 폭을 독립적으로 바꾸어 봅니다.
• [ ] 터치 좌표, 자필 입력, 팝오버 위치가 창 크기 변화 뒤에도 맞는지 확인합니다.
• [ ] 실제 기기 경로에서 외부 화면 연결과 장면 전환을 확인합니다.
• [ ] 실패한 창 크기와 특성 환경을 CI 로그에 남깁니다.

검증 환경을 나누는 세 가지 선택

현재 Mac에서 모든 경로를 동시에 열기 어렵다면 먼저 MacHTML 콘솔에서 사용 가능한 환경 확인을 하세요. 팀의 인증서, 저장소 접근, Xcode 설치 상태를 확인하는 절차는 개발 환경 도움말과 함께 검토하면 됩니다.

이주 순서를 정하기보다 판정 규칙을 먼저 고정하세요

이번 변경의 핵심은 UIScreen.main을 얼마나 빨리 지우느냐가 아닙니다. 같은 호출이 어떤 곳에서는 scene.screen, 다른 곳에서는 view.bounds, 또 다른 곳에서는 traitCollection으로 가야 한다는 규칙을 팀 전체가 공유하는 것입니다.

현재 방식은 단일 개발 Mac에서 순서대로 확인하기 쉽지만, iOS 27 창 크기와 iPhone Mirroring, iPad 창을 동시에 재현하기 어렵습니다. 장면 문맥이 빠지고, 특정 기기에서만 통과한 레이아웃을 배포할 위험도 있습니다. 반대로 MacHTML을 이용한 임시 병렬 환경은 테스트 경로를 분리할 수 있지만, 프로젝트 전달과 인증서 관리 절차를 먼저 정해야 합니다.

먼저 위 선택표로 코드를 분류하세요. 그 뒤 현재 Mac으로 초기 수정과 단위 테스트를 진행하고, Xcode 27 창 조정과 iPhone Mirroring, iPad 회귀가 겹치는 릴리스라면 다중 창 테스트 환경의 운영 방법을 확인해 부족한 검증 공간을 보완하는 편이 현실적입니다. 장기간 같은 프로젝트를 안정적으로 무겁게 실행하거나 물리 포트와 전용 주변 기기가 꼭 필요한 경우에는 직접 Mac을 운영하는 편이 더 적합합니다. 반대로 단기 회귀, 출시 전 추가 용량, 팀 간 환경 분리가 목적이라면 MacHTML의 Mac 환경이 기존 단일 Mac보다 확인 범위를 넓히기 쉽습니다.

더 읽기: iOS 27 개발자 베타 설치와 호환 기기 확인하기 iOS 27에서 시리 인공지능 앱과 기기 간 연속성 살펴보기