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