# 안드로이드를 위한 Swift SDK 발표 > Clean Markdown view of GeekNews topic #23905. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=23905](https://news.hada.io/topic?id=23905) - GeekNews Markdown: [https://news.hada.io/topic/23905.md](https://news.hada.io/topic/23905.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-10-25T11:33:14+09:00 - Updated: 2025-10-25T11:33:14+09:00 - Original source: [swift.org](https://www.swift.org/blog/nightly-swift-sdk-for-android/) - Points: 10 - Comments: 1 ## Summary Swift가 **Android용 SDK**를 공개하며 **크로스플랫폼 개발**의 지형을 넓히고 있습니다. 이번 프리뷰 빌드는 **Swift Android 워크그룹**의 협업 결과로, 개발자가 Swift로 **안드로이드 네이티브 앱**을 직접 빌드할 수 있게 합니다. **swift-java 프로젝트**를 통해 Swift와 Java 간 **양방향 상호운용성**을 제공해, 기존 Swift 패키지와 비즈니스 로직을 Android 네이티브 환경으로 손쉽게 이식할 수 있습니다. Windows 설치 프로그램과 Linux·macOS용 배포판이 함께 제공되며, 이는 Swift가 **모바일·서버·임베디드를 아우르는 통합 언어 생태계**로 진화하는 중요한 전환점으로 평가됩니다. ## Topic Body - Swift 언어가 **클라우드, Windows, 브라우저, 마이크로컨트롤러**까지 확장되며 성숙해진 가운데, 이제 **Android용 Swift SDK**가 공개됨 - 이 SDK는 **Swift Android 워크그룹**의 수개월간 노력의 결과로, 개발자가 Swift로 **안드로이드 네이티브 앱**을 개발할 수 있게 함 - SDK는 **Windows 설치 프로그램에 포함**되거나 **Linux·macOS용으로 별도 다운로드** 가능하며, 예제 코드와 가이드도 함께 제공됨 - **swift-java 프로젝트**를 통해 Swift와 Java 간 **양방향 상호운용성**을 지원, 자동 바인딩 생성으로 성능과 안전성을 확보함 - 이번 공개는 Swift의 **크로스플랫폼 생태계 확장**을 가속화하며, 모바일 개발의 새로운 가능성을 여는 전환점으로 평가됨 --- ### Swift SDK for Android 개요 - Swift 언어가 지난 10년간 **클라우드 서비스부터 Windows, 브라우저, 마이크로컨트롤러**까지 확장된 배경에서, 이제 Android 플랫폼으로의 진출이 공식화됨 - Swift의 **상호운용성(interoperability)** 덕분에 여러 플랫폼 간 코드 공유가 용이함 - **Android 워크그룹(Android workgroup)** 은 누구나 참여 가능한 오픈 그룹으로, Swift를 Android로 확장하는 것을 목표로 함 - 이번 발표는 **Swift SDK for Android의 나이트리(preview) 빌드 공개**를 의미하며, 커뮤니티의 오랜 협업 결과물임 ### SDK의 주요 기능과 배포 방식 - 개발자는 이제 Swift를 사용해 **Android 네이티브 애플리케이션**을 직접 개발할 수 있음 - 이를 통해 **크로스플랫폼 개발**의 새로운 가능성이 열림 - SDK는 **Windows 설치 프로그램에 번들**되어 제공되며, **Linux 및 macOS용으로 별도 다운로드** 가능 - Swift.org는 **“Getting Started” 가이드**를 통해 Android 기기에서 Swift 코드를 설정하는 방법을 안내 - GitHub의 **Swift for Android Examples** 저장소에서 **엔드 투 엔드 앱 워크플로우**를 시연 ### 패키지 호환성과 커뮤니티 확장 - Swift SDK를 통해 기존 **Swift 패키지를 Android로 포팅** 가능 - Swift Package Index의 **25% 이상 패키지**가 이미 Android 빌드를 지원 - **Community Showcase** 페이지에서 Android 호환 여부를 표시 - 이러한 확장은 Swift 생태계의 **멀티플랫폼 지원 강화**로 이어짐 ### swift-java 프로젝트와 상호운용성 - **swift-java 프로젝트**는 Swift와 Java 간 **상호운용성(interoperability)** 을 제공하는 **라이브러리 및 코드 생성기**임 - Swift와 Java 간 **양방향 통합**을 자동으로 처리하며, **안전하고 고성능의 바인딩**을 생성 - 개발자는 이를 통해 **비즈니스 로직을 Android로 이식**할 수 있으며, 관련 내용은 **Swift Server Side Meetup** 발표 영상에서 확인 가능 ### 커뮤니티 참여와 향후 로드맵 - 이번 프리뷰 릴리스는 **도구 개선과 생태계 확장**을 위한 새로운 기회를 열었음 - Swift 포럼의 **Android 카테고리**에서 경험, 아이디어, 도구, 앱을 공유하도록 권장 - 본 발표는 포럼의 **공식 스레드**에서도 논의 중 - Android 워크그룹은 현재 **비전 문서(vision document)** 를 작성 중이며, Swift on Android의 **우선순위 영역과 향후 방향성**을 제시할 예정 - **프로젝트 보드**를 통해 주요 진행 현황을 추적하고, **공식 CI 시스템**으로 SDK 품질을 관리 - Swift 팀은 커뮤니티의 참여를 독려하며, **Android 생태계 내 Swift의 입지 강화**를 목표로 함 ## Comments ### Comment 45447 - Author: neo - Created: 2025-10-25T11:33:15+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45698570) - 모든 **크로스플랫폼 프레임워크**의 핵심 질문은 UI를 어떻게 처리하느냐임 Adobe의 Flex Builder처럼 각 플랫폼에서 이질적으로 느껴지는 디자인 시스템을 쓰면, 결국 **네이티브 감성**을 직접 구현해야 했음 Flutter는 iOS의 **Cupertino 테마**를 완벽히 재현하려 하고, React Native는 플랫폼의 기본 위젯을 활용해 스크롤 같은 요소가 자연스럽게 느껴지게 함 블로그 글에서는 이 중요한 부분이 언급되지 않아 아쉬움 Apple이 Android용 Swift를 내놓더라도, Apple 특유의 디자인 철학 때문에 Android에서 어색하게 느껴질 가능성이 있음 이 프로젝트가 Apple이 직접 주도하는지, 아니면 커뮤니티 중심의 **오픈소스 시도**인지가 향후 방향을 결정할 것 같음 - 나는 UI 공유보다 **네이티브 UI 작성**이 가능한 프레임워크를 선호함 그래서 KMP가 좋음. iOS에서는 SwiftUI로, Android에서는 Kotlin으로 UI를 짜면서 비즈니스 로직만 공유할 수 있음 UI를 공유하려 하면 “한 번 작성하고 모든 곳에서 디버깅”하는 악몽이 생김 Swift for Android도 이런 식으로 **언어 단위의 로직 공유**를 가능하게 해줄 것 같음 - Swift SDK for Android는 UI 방식을 강제하지 않음 예시에서도 Jetpack Compose를 그대로 쓰면서 Swift 로직을 호출함 Swift의 **참조 카운팅 메모리 모델**과 동일한 구조를 유지해 일관성이 높음 Apple에서 개발자 도구를 담당하는 입장에서, 이 기술이 새로운 혁신의 발판이 되길 기대함 - Browser Company가 SwiftUI를 Windows에 포팅한 사례처럼, Android에서도 SwiftUI가 Jetpack Compose로 매핑될 가능성이 있음 SwiftUI는 본래 “네이티브 UI”가 아니라, 시스템이 해석해 **UIView나 NSView를 생성하는 선언적 언어**임 - 이번 릴리스에는 SwiftUI나 UIKit이 Android로 이식된 내용이 없음 Flutter처럼 직접 복제하지 않는 이상, Apple UI를 Android에서 그대로 쓰는 건 불가능함 - Swift SDK는 UI 기술을 지정하지 않음 대신 [Skip.tools](https://skip.tools/blog/fully-native-android-swift-apps/) 같은 프로젝트가 SwiftUI를 Jetpack Compose로 브리징해줌 [Skip Showcase 앱](https://skip.tools/docs/samples/skipapp-showcase-fuse/)에서 그 예시를 볼 수 있음 나는 Skip 제품과 Swift Android Workgroup의 멤버로, 이번 SDK 릴리스 매니저로 참여했음 - 공식 프로젝트로 발표돼서 정말 반가움 RN이나 Flutter를 써봤지만 항상 **네이티브 감성 부족**이 문제였음 KMP도 있지만 대부분의 개발자는 iOS부터 시작해 Android로 확장함 Swift Package로 코드를 공유하면 이 흐름이 훨씬 자연스러워짐 - Android 개발자는 훨씬 많고, 배포도 간단함 반면 Swift/Objective-C 개발자는 훨씬 적음 미국 외 지역에서는 iPhone 점유율이 낮아, 기업들은 **Windows나 브라우저 중심**으로 생각하는 경향이 있음 - “iOS부터 시작한다”는 건 **미국 중심적 시각** 같음 KMP는 이미 Google Workspace 같은 대형 앱에서 쓰이고 있고, Kotlin과 JetBrains의 투자로 **성숙도**가 높음 Flutter는 릴리스 주기가 너무 빨라 따라가기 힘들었음 - **JavaScript 기반 비즈니스 로직**도 무시할 수 없음 JavaScriptCore나 QuickJS로 iOS, Android, Web에서 모두 동작하고, **핫 리로드**가 가능함 다만 앱스토어 정책상 큰 기능 변경은 어렵고, 버그 수정 정도에 적합함 모바일 배포 주기가 느린 현실에서 이런 접근은 큰 기회라고 생각함 - Proton에서는 **Rust로 80% 이상**의 로직을 공유하고, 나머지는 플랫폼별로 구현함 - 사실 이런 구조는 이미 .NET과 MvvmCross로 가능했음 공유 코어 라이브러리 + 각 플랫폼의 네이티브 UI 프로젝트 구조로 잘 동작함 - [Skip.tools 블로그](https://skip.tools/blog/bringing-swift-to-android/)에서 본 SKIP 트랜스파일러와 관련된 프로젝트인지 궁금했음 SwiftUI 앱을 Android로 옮기고 싶었는데 RN은 피하고 싶었음 - 맞음, Skip은 1년 넘게 Swift SDK 프리뷰 버전을 사용해왔고, **Fuse 모드**로 완전한 네이티브 SwiftUI 앱을 Android에 빌드함 Skip에는 두 가지 모드가 있음: Swift 코드를 Kotlin으로 변환하는 **Lite 모드**, 그리고 Swift를 직접 Android용으로 컴파일하는 **Fuse 모드** 두 모드를 함께 써서 Kotlin 생태계(Lottie, Firebase 등)와 통합 가능함 자세한 비교는 [Skip Docs](https://skip.tools/docs/status/)에서 볼 수 있음 공식 SDK가 나와서 이제 자체 빌드 대신 공식 버전을 쓸 수 있게 되어 기쁨 - Skip은 이번 노력의 주요 기여자 중 하나임 - 이제 트랜스파일러 없이도 **네이티브 Swift 실행**이 가능해졌고, 호환성도 훨씬 높음 - Swift Embedded처럼 단순한 **개념 증명 수준**으로 끝나지 않길 바람 Swift는 언어적으로 아름답지만, 커뮤니티 리더십에 대한 불안한 분위기가 있음 - guard let self = self else { return } — Swift 개발자라면 익숙한 농담임 - RN과 Flutter는 이제 그만 보고 싶음 **각진 UI**와 느린 터치 반응에 지침 - Flutter에서도 코너 반경을 조절할 수 있고, 성능도 빠름 반응이 느린 건 앱 구현 문제일 가능성이 큼 - 나도 RN과 Flutter를 좋아하진 않지만, Swift on Android가 그들보다 나을 거라는 보장은 없음 Apple이 금방 **관심을 잃을** 수도 있음 - “You got Kotlin in my iOS.” “You got Swift in my Android.” — 재치 있는 표현임 - 완벽한 비유임. 진짜 Reese’s 광고처럼 Kotlin과 Swift가 섞인 하이브리드가 나올지도 모름 - Kotlin on iOS는 **정적 컴파일**되고 Swift/ObjC와 네이티브로 상호운용됨 [Kotlin Native 개요](https://kotlinlang.org/docs/native-overview.html) 참고 - 이번 발표는 새로운 **Swift SDK 시스템의 성공 증명**으로 보임 예전엔 다른 플랫폼 지원이 CMake 얽힘으로 복잡했지만, 이제 SDK 규칙만 따르면 어떤 플랫폼에도 포팅 가능함 Android 외에도 Linux, wasm, embedded, 곧 Windows까지 확장될 예정임 JVM과의 상호운용은 아직 완전하지 않지만, **플랫폼 독립성**이 커진 건 분명함 - 나는 Kotlin Multiplatform을 좋아하지만, Swift for Android도 흥미로움 메모리 민감한 작업에 **Swift 네이티브 라이브러리**를 공유하는 건 유용할 듯 다만 전체 비즈니스 로직을 Swift로 옮기기엔 KMP가 아직 더 성숙함 - KMP로 데스크톱 앱도 만든 적이 있는지, 전체적인 **성숙도**가 궁금함 - 비즈니스 로직 공유는 이미 해결된 문제였음 진짜 고통은 **UI를 두 번 작성**해야 하는 부분이었음 React Native처럼 불편하지 않은 공통 UI 프레임워크가 필요함 - React Native는 최근 **New Architecture**로 전환되면서 꽤 좋아졌음 Expo와 함께 쓰면 개발 경험이 많이 개선됨 - Android와 iOS 간 코드 공유를 오래 해왔지만, **UI 공유는 악몽**이었음 복잡한 로직만 C/C++/Rust로 공유했는데, 결국 언어가 세 개나 됨 KMP와 Swift for Android는 Kotlin/Swift로만 공유할 수 있게 해줘서 훨씬 깔끔함 이런 접근이 UI를 억지로 공유하는 프레임워크보다 훨씬 **현실적이고 효율적**임