Show HN: Skip – Build native iOS and Android apps from a single Swift codebase

Original Article ↗ Hacker News Discussion ↗

Overall reception and positioning

  • Many commenters find Skip “magical” and appealing, especially for Swift/iOS‑first teams wanting Android without learning another UI stack.
  • Others are skeptical, seeing it as another cross‑platform layer that moves rather than removes complexity, with concerns about long‑term maintenance and code quality vs. React Native, Flutter, and Kotlin Multiplatform.

How Skip works / Developer workflow

  • Core model: write Swift (often SwiftUI), transpile to Kotlin/Jetpack Compose via an Xcode build plugin that runs on every build.
  • iOS remains fully native Swift; Android uses generated Kotlin that is not meant to be edited directly.
  • Both iOS and Android emulators can run side‑by‑side from Xcode; Android debugging is done in Android Studio/IntelliJ.

Platform capabilities and limitations

  • Limitations in Swift transpilation (e.g., advanced generics) only affect Android; iOS can use any Swift/SwiftUI/UIKit features.
  • Coverage is good for Foundation and for SwiftUI→Compose, but many Apple frameworks (e.g., MapKit, StoreKit, CryptoKit, UserNotifications) are not yet bridged.
  • Skip creators emphasize it is not a “lowest common denominator”: iOS is unconstrained; Android gaps require explicit Android‑specific code paths.

Use of native and third‑party libraries

  • Each side can depend on native ecosystems: SwiftPM packages on iOS, Gradle/Maven deps on Android.
  • Platform‑specific features (e.g., Firebase) are handled by wiring Swift and Kotlin equivalents under conditional code.
  • An FFI module allows shared C code on both platforms; C++ interop on Android via JNA is acknowledged as rough.

Migration, customization, and debugging

  • New projects are easier; integrating into existing iOS apps is described as “way harder,” especially if they rely on unimplemented frameworks or unsupported patterns.
  • Customization uses conditional compilation (#if blocks) and the ability to inline Kotlin/Compose alongside Swift/SwiftUI.
  • Commenters ask how to handle divergence in platform UX (back behavior, visual styling, “iOS‑y” layouts); answer is “mostly handled by SwiftUI/Compose semantics,” plus platform‑specific branches when needed.

Pricing and licensing concerns

  • Pricing for “indie” tiers is seen as confusing and potentially exclusionary; some worry about friction compared to free alternatives.
  • Libraries are LGPL; Skip team stresses this does not force app source disclosure.

Debate on strategic value / target users

  • One camp: this is ideal for small or iOS‑heavy teams, or for iOS‑first products where revenue is concentrated.
  • Another camp: in Android‑dominant or “global south” markets this makes less sense; better to start with true cross‑platform or native Android.
  • Disagreement arises over whether performance, “native feel,” and ecosystem maturity are still differentiators versus RN/Flutter/KMP.

Miscellaneous / unresolved questions

  • Requests for more “built with Skip” showcase apps; currently there’s a single Showcase app plus some open‑source bridges.
  • Questions about camera support, LiveView Native integration, and direct use of pure SwiftPM dependencies on Android remain unclear or “not yet.”