2019년 애플이 SwiftUI를 공개했을 때 개발자들에게 던진 약속은 분명했다. 선언형 문법, 단일 진실 공급원(single source of truth), 내장 애니메이션, 즉시 프리뷰, 그리고 애플 전 플랫폼에 걸친 코드 재사용. Auto Layout과 씨름하고 사소한 변경마다 앱을 다시 빌드하던 시대를 끝내겠다는 선언이었다. 그러나 7년이 지난 2026년 현재, 원문 필자는 SwiftUI가 여전히 '영구 베타' 상태에 머물러 있으며 레이아웃 일관성과 성능이라는 오래된 문제를 해결하지 못했다고 진단한다. 업계에서 7년은 첫 아이폰과 iOS 7 리디자인 사이보다도 긴 시간이라는 점을 감안하면, '아직 젊은 프레임워크'라는 변명은 더 이상 유효하지 않다는 것이다.
왜 SwiftUI가 존재하는가
필자는 SwiftUI의 탄생을 애플의 순수한 선의보다 경쟁 압박의 산물로 본다. 2010년대 중반 웹에서는 페이스북의 React가 사실상 표준이 되었고, React Native와 구글의 Flutter가 모바일로 세력을 넓혔다. 둘 다 반응형·선언형이며, 기업 입장에서는 iOS와 안드로이드에 같은 코드베이스를 쓰고 웹 컴포넌트까지 재활용할 수 있으니 네이티브 개발의 매력이 줄어들었다. 여기에 맥 생태계 문제가 겹친다. 맥 앱스토어는 사실상 방치됐고, 상당수 앱이 브라우저나 Electron 래퍼로만 동작했다. 30% 수수료 기반의 서비스 사업을 지키려면 개발자를 네이티브 안에 붙잡아 두고 기존 앱의 맥 이식을 쉽게 만들어야 했고, SwiftUI가 그 해법으로 제시됐다는 분석이다.
데이터 흐름과 레이아웃의 예측 불가능성
가장 큰 불만은 데이터 흐름이다. 처음엔 @State, @Binding, ObservedObject로 시작했지만 뷰가 끊임없이 리렌더링되는 성능 문제가 드러나자 애플은 Observation 프레임워크와 @Observable 매크로를 도입했다. 컴파일러 트릭으로 해결하려 했으나 충분치 않았고, 뷰가 몇 번이나, 왜 갱신되는지 개발자가 확신할 수 없는 상태가 이어진다. 문서화되지 않은 디버깅 API로도 전모를 파악하기 어렵다는 것이다. 레이아웃 엔진 역시 크기 협상(size negotiation) 개념 위에 서 있어 키노트에서는 그럴듯하지만, 플로팅 뷰나 커스텀 사이드바를 만들려는 순간 예측 불가능성이 드러난다. 필자는 애플 공식 SwiftUI 튜토리얼의 데모 프로젝트조차 최신 Xcode로 빌드해 최신 macOS에서 실행하면 표준 사이드바가 깨지며, 2년 넘게 이 문제가 방치돼 있다고 지적한다. 결국 모든 것을 GeometryReader로 감싸게 되는데, 이는 좌표를 수동 계산하며 Auto Layout보다 더 장황해지는 '패배 선언'이자 선언형의 이점을 스스로 포기하는 행위라는 것이다.
API 파편화와 후방 배포의 부재
API 안정성과 기능 완성도도 도마에 오른다. 현대 SwiftUI 코드베이스는 if #available 체크로 가득하다. 스크롤 시 키보드 내리기는 iOS 7부터 되던 기능인데 SwiftUI에선 iOS 16이 필요하고, 네트워크 이미지를 표시하는 AsyncImage는 iOS 15에야 등장했으며, 이미지 캐싱 API는 2026년 7월 현재까지 베타 상태라 아예 불가능하다고 필자는 전한다. 버그가 많던 NavigationView는 수정 대신 NavigationStack으로 교체되면서 구·신 버전용 분기를 각각 유지해야 하는 부담을 남겼다. 핵심은 애플이 최신 API를 구형 iOS로 후방 배포(back-deploy)하도록 허용하지 않는다는 점이다. 안드로이드의 Jetpack Compose가 의존성 관리자로 받아 실행 파일에 번들되고 2014년 기기에서도 동일한 UI를 내는 것과 대조된다. 그 결과 개발자는 여러 구현을 병행 유지하며 사실상 애플의 QA 업무를 대신하는 셈이 된다.
성능 역시 필자가 물러서지 않는 지점이다. 애플이 늘 최신 하드웨어에서만 시연한다는 점을 꼬집으며, 자신이 직접 만든 이미지 갤러리로 UIKit과 SwiftUI를 비교한 결과 배경 스레드 디코딩 같은 최적화를 넣어도 SwiftUI 그리드 스크롤이 확연히 덜 매끄러웠다고 밝힌다. 구형 아이폰을 일부러 썼다지만, JPEG 몇 장을 보여주는 데 최고사양 칩이 필요하다면 아키텍처 자체에 문제가 있다는 지적이다. 마지막 약속인 크로스플랫폼도 '한 번 작성해 어디서나'가 아니라 '한 번 배워 어디에나 적용'에 가깝고, iOS에서 익힌 레이아웃 지식이 맥에는 거의 통하지 않아 컴포넌트와 설정이 크게 달라진다고 정리한다.
한국 실무자에게 주는 시사점
다만 이 글은 한 시니어 엔지니어의 강한 주관이 담긴 비평이며, 벤치마크 조건이나 재현 절차가 엄밀하게 공개된 것은 아니라는 한계를 함께 읽어야 한다. 그럼에도 국내 iOS 팀에는 현실적 함의가 있다. 지원 최소 버전을 높게 잡을수록 if #available 분기와 셰임(shim) 유지 비용이 줄어든다는 점, 캐싱·복잡한 사이드바처럼 아직 약한 영역은 초기부터 자체 구현이나 UIKit 병행을 전제로 설계하는 편이 안전하다는 점, 성능 검증은 반드시 구형 실기기에서 확인해야 한다는 점이다. SwiftUI를 배척할 필요는 없지만, 마케팅의 '견고함'을 그대로 신뢰하기보다 프레임워크의 성숙 곡선을 기술 부채 계획에 반영하는 냉정함이 요구된다.