The Swift SDK for Android

Original Article ↗ Hacker News Discussion ↗

What the Swift Android SDK Actually Provides

  • Not a “build iOS app, click Android” solution. It’s a Swift toolchain for Android: compiler + standard libraries + interop with Android (via NDK/JNI and a Swift–Java bridge).
  • Current focus is on sharing business logic and libraries, not full UI parity with iOS. SwiftUI/UIKit are not available on Android.
  • Swift code is compiled to native Android binaries, not transpiled (except when using third‑party tools like Skip in their “Lite” mode).
  • Example projects mostly show Kotlin/Jetpack Compose UI calling into Swift for logic.

Xcode, Android Studio, and Dev Experience

  • You can write Swift in Xcode, VS Code, or any editor, but Android builds/debugging are currently Android Studio/Gradle territory, not Xcode-driven.
  • Several commenters stress that first‑class debugging, package management, and CI for Android targets will make or break adoption.
  • Some find the JNI-style interop examples awkward; others point to higher-level swift‑java bindings that hide JNI details.
  • Ongoing complaints about Swift compiler errors (“expression too complex to type-check”) and Xcode stability; Android Studio/Gradle also viewed as painful, just in different ways.

Shared Logic vs Shared UI

  • Strong consensus from experienced mobile devs: sharing complex UI across platforms tends to be a “write once, debug everywhere” nightmare.
  • Many prefer: native UI per platform (SwiftUI/UIKit on iOS, Compose/other on Android) + shared business logic (now potentially in Swift instead of C/C++/Rust).
  • Skip is highlighted as a bridge: SwiftUI to Jetpack Compose (via transpilation and/or native Swift-on-Android), but some say the resulting Android UI feels like an iOS impostor.

Comparisons: React Native, Flutter, KMP, Rust, JS, etc.

  • React Native: praised for hot reload, OTA updates, rich JS tooling; criticized for npm pain, non‑native feel on Android/iOS, performance quirks.
  • Flutter: good DX and performance for many, but long‑standing iOS interaction/latency issues and clearly non‑native look on iOS.
  • Kotlin Multiplatform: seen as the most mature “shared logic” story today; Kotlin generally considered ahead in ecosystem and multiplatform tooling.
  • Some teams use Rust or JavaScript (via embedded runtimes) for shared logic; trade‑offs include interop overhead and language ergonomics.

Adoption, Ecosystem, and Strategy

  • Enthusiasm that Swift can now be a realistic shared-language option for iOS‑first teams; skepticism that it’s “too little, too late” versus React Native/Flutter/KMP.
  • Concerns about ecosystem size (e.g., only ~25% of Swift packages building for Android so far) but recognition that this is a very new ecosystem.
  • Debate over whether iOS‑first economics (especially in US/Western markets) make Swift-on-Android attractive mainly as a way to “port down” logic once an iOS app succeeds.