SwiftUI 7년 후, 여전히 베타처럼 느껴지는 이유

2019년 Apple 플랫폼의 차세대 UI 프레임워크로 등장한 SwiftUI는 7년이 지난 2026년에도 레이아웃·성능·API 안정성 문제로 프로덕션급 신뢰를 얻지 못함 단일 진실 공급원을 내세운 데이터 흐름은 @State, @Binding, ObservedObject, @Observable로 계속 바뀌었고, 뷰가 언제 왜 다시 그려지는지 예측하기 어려움 Apple 공식 Landmarks 예제의 사이드바도 최신 Xcode와 macOS에서 깨지며, 복잡한 화면에서는 GeometryReader로 좌표를 직접 계산해야 해 선언형 UI의 장점이 흐려짐 오래된 OS를 지원하려면 if #available 분기와 자체 구현을 함께 유지해야 하고, 이미지 갤러리 비교에서는 여러 최적화에도 UIKit이 더 부드럽게 스크롤함 플랫폼별 구성 요소와 동작도 일관되지 않아 “한 번 배우고 어디서나 적용”하기 어려우며, 정확성과 유지보수성을 편리함의 환상과 맞바꾸게 됨 7년째 이어지는 베타 상태 SwiftUI는 2019년 Apple의 발표에서 선언형 문법, 단일 진실 공급원, 내장 애니메이션, 즉시 미리보기, 플랫폼 간 코드 재사용을 약속함 2026년에도 레이아웃 일관성과 성능 문제가 남아 있으며, 새 기능마다 제약이 붙고 한 레이아웃 수정이 다른 부분을 깨뜨리는 상황이 반복됨 7년은 Windows XP에서 Windows 7까지의 기간과 비슷하고 첫 iPhone에서 iOS 7 재설계까지보다 길어, 더 이상 “젊은 프레임워크”라는 이유로 문제를 넘기기 어려움 Apple 공식 SwiftUI Landmarks 튜토리얼의 완성 프로젝트조차 최신 Xcode와 macOS에서 정상적인 레이아웃을 보여주지 못함 SwiftUI가 등장한 이유 2010년대 중반 웹에서 React가 사실상 표준으로 자리 잡고 React Native와 Flutter가 모바일로 확장되면서, Apple도 반응형·선언형 개발 방식에 대응해야 했음 기업은 iOS와 Android에서 같은 코드 기반을 사용하고 웹 구성 요소까지 재활용할 수 있어, 플랫폼별 네이티브 앱을 따로 만드는 방식을 덜 매력적으로 보기 시작함 Mac에서는 많은 앱이 브라우저나 Electron 래퍼로 제공됐으며, SwiftUI에는 개발자를 네이티브 생태계에 남겨 두고 기존 앱의 Mac 이전을 쉽게 만들려는 목적도 있었음 SwiftUI의 핵심 판매 요소는 반응형 데이터 흐름, 선언형 레이아웃, 플랫폼 간 지원이었음...