SwiftUI 7년 후: 평범함의 이야기

2019년 발표로부터 7년이 지나, SwiftUI는 Apple 플랫폼을 위한 크로스플랫폼 UI 개발의 성숙하고 프로덕션 등급인 미래를 목표로 했습니다. 그러나 많은 시니어 엔지니어들은 이제 이를 정확한 공학을 편의성의 환상과 교환하는 영구 베타 상태의 프레임워크로 보고 있습니다.

예측할 수 없는 데이터 흐름과 반응성

SwiftUI의 데이터 흐름은 예측 가능한 행동을 달성하기 거의 불가능한 "블랙 박스"로 특징지어집니다. 종이 위에서는 매력적인 "단일 진실의 원천" 개념이지만, 구현은 혼란스러운 속성 래퍼와 매크로의 배열로 진화했습니다.

상태 관리 진화: 프레임워크는 @State, @Binding, 그리고 ObservedObject로 시작했습니다. 성능 문제와 과도한 재렌더링으로 인해 Apple은 Observation 프레임워크와 @Observable 매크로를 도입했습니다.
투명성 부족: 개발자들은 문서화되지 않은 디버깅 API인 Self._printChanges()를 사용하더라도 뷰가 정확히 몇 번 업데이트될지 또는 특정 업데이트가 왜 트리거되었는지 알 수 없다고 보고합니다.

레이크 엔진 취약성과 GeometryReader 함정

SwiftUI의 레이아웃 시스템은 크기 협상을 기반으로 하며, 특히 커스텀 사이드바나 플로팅 뷰와 같은 복잡한 인터페이스를 구축할 때 예측 불가능하고 취약하다고 자주 묘사됩니다.

레이아웃 불일치: 최신 macOS 버전에서 실행될 때 nawet 첫 번째 파티 Apple 튜토리얼도 레이아웃이 깨졌다고 인용됩니다.
GeometryReader 우회 방법: 선언적 시스템이 실패할 때, 개발자들은 종종 수동으로 좌표를 계산하기 위해 GeometryReader에 의존합니다. 이는 선언적 이점을 제거하고 레거시 Auto Layout 시스템보다 더 장황해지기 때문에 "항복의 인정"으로 간주됩니다.

API 불안정성과 기능 parity 격차

SwiftUI는 UIKit과 AppKit과 같은 레거시 프레임워크와 기능 parity에서 계속 어려움을 겪고 있습니다. 이로 인해 하위 호환성을 유지하기 위해 코드베이스에 if #available 검사가 가득 차 있습니다.

지연된 기능 구현: 기본 기능—예를 들어 스크롤 시 키보드 닫기 (iOS 16) 또는 AsyncImage를 통한 네트워크 이미지 표시 (iOS 15)—는 레거시 프레임워크에서 수십 년 동안 존재했음에도 불구하고 SwiftUI에 수년이 걸려 도착했습니다.
컴포넌트 교체: 버그가 있는 컴포넌트를 수정하기보다는 Apple이 때때로 완전히 대체하기도 합니다(예: NavigationView를 NavigationStack으로 대체), 이로 인해 개발자는 다양한 OS 버전에 대해 별도의 코드 브랜치를 유지해야 합니다.
캐싱 제한: 2026년 7월 기준으로, 특정 중요한 이미지 캐싱 API는 여전히 베타 상태에 있어, 개발자는 맞춤형 페처와 캐싱 레이어를 구축해야 합니다.

성능 차이

대면 비교 결과, SwiftUI의 성능은 데이터가 많은 뷰에서 특히 UIKit보다 뒤처지는 경우가 많습니다.

스크롤 성능: SwiftUI의 간단한 이미지 갤러리와 큰 그리드는 고사양 하드웨어에서도 UIKit counterpart보다 덜 부드럽게 느껴집니다.
최적화 오버헤드: 허용 가능한 성능을 달성하려면 종종 프레임워크의 단순함 약속과 모순되는 난해한 최적화 비법이 필요합니다.

"한 번 배우면 어디서나 적용"이라는 신화

Apple은 SwiftUI를 "those tools를 한 번 배우고 überall 적용"하는 방법으로 마케팅하지만, 현실은 6인치 전화기의 UI 설계가 27인치 데스크톱과 근본적으로 다르다는 것입니다.

플랫폼 차이: iOS에서 배운 개념은 종종 macOS 레이아웃에 직접 적용되지 않아 "이질적인" UI가 발생하며, 이는 포팅된 iPad 앱처럼 느껴집니다.
구현 불일치: 동일한 뷰는 종종 다른 Apple 플랫폼에서 일관되지 않은 구현을 가지며, 이로 인해 "한 번 배우고, 두 번 배우고, 어딘가에 적용하고, überall 디버그"하는 워크플로우가 발생합니다.

"충분히 좋은" 방향으로의 철학적 전환

SwiftUI가 Apple에서 타협 없는 장인정신에서 "속도"와 "충분히 좋은" 제품 문화로의 체계적 전환을 대표한다는 우려가 커지고 있습니다.

버그의 정상화: 이 전환은 첫 번째 파티 앱에서 지속되는 버그(예: Apple Music 큐 점프, 중복 홈 화면 아이콘, Logic Pro의 현지화 누락)에서 evidencia됩니다.
레거시 시대와의 비교: 이는 원래 Cocoa와 Aqua 시대와 대조되며, 당시에는 이러한 시각적 결함과 불안정성이 용납되지 않을 것으로 간주되었습니다.

커뮤니티 관점과 반론

개발자 토론에서는 SwiftUI를 실패로 보는 사람들과 강력하지만 불완전한 도구로 보는 사람들 사이에 분열이 드러납니다.

"SwiftUI는 쉬운 일은 더 쉽게 만들고 어려운 일은 더 어렵게 만드는 프레임워크 유형입니다. 이는 초보자 함정입니다."

"저는 주요 성능 문제 없이 SwiftUI를 사용해 왔습니다... 저는 필요에 따라 프로파일링하고 수정합니다. 제가 처음 일했던 스튜디오 중 하나는 모든 게임을 프로토타입으로 UIKit으로 작성했습니다... 성능이 떨어지면 적절한 도구로 전환했습니다."

"작업의 90%에서는 SwiftUI가 좋지만, 10%에서는 AppKit이 필요합니다. 제 앱에서는 채팅 항목의 대량을 목록에 로드하고 표시해야 하는데, SwiftUI는 이 작업에서 정말 나쁩니다."

일부 개발자들은 불만이 "UIKit 고수" 사고방식에서 비롯된다고 주장하며, 간단한 앱에서는 SwiftUI가 레거시 프레임워크의 보일러플레이트-heavy 특성보다 훨씬 생산적이라고 말합니다.