▲

안드로이드를 위한 Swift SDK 발표

 (swift.org)
6P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • 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의 입지 강화를 목표로 함
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • 모든 크로스플랫폼 프레임워크의 핵심 질문은 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 같은 프로젝트가 SwiftUI를 Jetpack Compose로 브리징해줌
      Skip Showcase 앱에서 그 예시를 볼 수 있음
      나는 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 블로그에서 본 SKIP 트랜스파일러와 관련된 프로젝트인지 궁금했음
    SwiftUI 앱을 Android로 옮기고 싶었는데 RN은 피하고 싶었음

    • 맞음, Skip은 1년 넘게 Swift SDK 프리뷰 버전을 사용해왔고, Fuse 모드로 완전한 네이티브 SwiftUI 앱을 Android에 빌드함
      Skip에는 두 가지 모드가 있음: Swift 코드를 Kotlin으로 변환하는 Lite 모드, 그리고 Swift를 직접 Android용으로 컴파일하는 Fuse 모드
      두 모드를 함께 써서 Kotlin 생태계(Lottie, Firebase 등)와 통합 가능함
      자세한 비교는 Skip Docs에서 볼 수 있음
      공식 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 개요 참고

  • 이번 발표는 새로운 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를 억지로 공유하는 프레임워크보다 훨씬 현실적이고 효율적임

답변달기