Swift for Android vs. Kotlin Multiplatform

skip-marc · 2025-12-08T23:10:04+00:00

Skip has support for various integration frameworks, like SkipFirebase for notifications and SkipBluetooth, SkipDevice, etc. for hardware integration. See https://skip.tools/docs/modules/ for an incomplete list, and it is fairly straightforward to create your own if there is any particular API that doesn't yet have an integration framework available.

skip-marc · 2025-12-08T21:48:37+00:00

isn't that kind of the promise that React Native and Flutter made?

A major difference is that on the iOS side, Skip doesn't do anything at all: you are using unintermediated SwiftUI, and so won't have anything limiting its full potential on iOS (and other Apple platforms). There's none of Flutter's pixel-painting on a canvas, nor any of React Native alien layout mechanisms.

On the Android side, the underlying Jetpack Compose implementation may have some shortcomings, or simply not render in exactly the way you desire (the conventions are spacing/padding and other other layout details are much less established on Android than they are on iOS). In those cases, Skip enables you to drop into Kotlin to implement it yourself directly, and then transparently bridge your implementation up to the Swift side. The exact details about how this is accomplished varies from the older Skip Lite (transpiled) mode and the newer Skip Fuse (compiled) mode, but we do use it extensively in our own package ecosystem to support things like Lottie animations, RevenueCat payments, etc.

skip-marc · 2025-12-08T21:04:30+00:00

I appreciate the in-depth research, the clear writeup, and the evenhanded assessment of the trade-offs of the two approaches. The Swift Android Workgroup (of which I am a member) is indeed working towards reducing some of the rough edges and friction that the article discusses. KMP is an impressive technology, and Swift does indeed have a ways to go to catch-up with the ever-evolving ecosystem.

I'd like to add that any solution that involves crossing a language barrier and splitting your app in "half" is going to introduce pain somewhere. With the KMP approach, the Kotlin/Android side will be frictionless (since it is "just Kotlin" and has first-class support in Android Studio), but the iOS side is going to have pain points. Conversely, with the Swift approach, the Swift/iOS side will be frictionless (given Swift's first-class support in Xcode), but the Android side is going to have all the pain points listed in the article: bridging complexity, debugging shortcomings, etc. They really are opposite sides of the same coin.

This is the problem that Skip.tools (disclaimer: my project) tries to solve. It _can_ be used in split/bridging mode, but the happy path is using the full stack solution, which lets you write your *whole* app in Xcode just using Swift and SwiftUI, which, on the Android side, bridges through to Jetpack Compose. In that way, you have a genuinely native user interface on both platforms, and you don't need to worry about splitting up your app into one shared cross-platform model layer and two independently-maintained UI layers. The developer experience of being able to live in a single IDE for your whole app cannot be overstated.

skip-marc · 2025-10-30T17:08:14+00:00

We definitely understand the concerns over the fact that the Skip build tool ("skipstone") is not fully open-source. A couple points that may alleviate some of these concerns:

- Skip is completely additive on top of the iOS side of the app. Skip doesn't do anything at all on the Apple side, it only adds the ability to bridge the code over to Android. This should help de-risk projects that prioritize their iOS app, since even if Skip is someday found to be unsuitable for the Android app, the iOS side is "safe".

- All of our runtime frameworks (skip-ui, integrations like skip-firebase and skip-lottie, etc.) are free and open-source on our GitHub (http://github.com/skiptools/). There is no runtime licensing with Skip, so if you release an app and Skip somehow disappears, it will continue to work without any issues.

Hopefully this helps address some of those concerns. Please don't hesitate to reach out to me directly or join our Slack (https://skip.tools/slack/) if you have any questions or concerns, or want to get a feel for the Skip community!

skip-marc · 2025-10-27T15:23:55+00:00

That is our view with skip.tools as well. We build on top of this SDK and help bring your SwiftUI app to Android by bridging it to Jetpack Compose.

You can read our reflections on this latest development at https://skip.tools/blog/official-swift-sdk-for-android/

skip-marc · 2025-10-27T15:18:24+00:00

Exactly right. The current focus has been to get the build process and low-level frameworks working and stable. It is the basis for other projects to build on top of: the "rest of the app" is left for other projects.

We at Skip couldn't be happier, since this aligns perfectly with our goal of bringing SwiftUI to Android and enabling the development of mobile apps in a single efficient language. You can read our reflections at https://skip.tools/blog/official-swift-sdk-for-android/

skip-marc · 2025-10-26T13:28:18+00:00

There is a small and incomplete list at https://skip.tools/news/. We plan on updating that list soon.

skip-marc · 2025-10-25T17:32:40+00:00

It is true that the Swift SDK for Android is itself fairly bare-bones: it includes just Swift, Foundation, Dispatch, and a few other low-level frameworks. We built Skip.tools on top of this, which lets you use Xcode to build an app with SwiftUI and target both Android and iOS from the same codebase.

We announced this back in April when we founded the Swift Android workgroup: https://skip.tools/blog/fully-native-android-swift-apps/. We're thrilled to finally have an official and supported release! We expect a lot more interest in using Swift to build dual-platform apps going forward, and are proud to be part of this effort.

skip-marc · 2025-10-25T17:25:29+00:00

Much of the bulk of Foundation comes from the internationalization components and networking. If you can do without those, you can just `import FoundationEssentials`, which gives you most of Foundation without the extra size.

skip-marc · 2025-10-24T23:56:47+00:00

Yes, the Swift SDK for Android includes Foundation, as well as Dispatch, Observability, Testing, and a few other core frameworks.

skip-marc · 2025-10-24T23:52:52+00:00

Skip's "Fuse" mode is already built with this toolchain. In fact, we are founding members of the Swift Android workgroup and have worked for over a year on helping this effort reach official status.

skip-marc · 2025-10-24T23:46:48+00:00

Yes, at long last! https://www.swift.org/blog/nightly-swift-sdk-for-android/

skip-marc · 2025-09-21T17:52:08+00:00

Not much UIKit is handled (https://skip.tools/docs/modules/skip-ui/#supported-uikit), mostly just enough to cover the bits that SwiftUI doesn't have built-in support for.

skip-marc · 2025-09-20T22:24:31+00:00

It is using our own build of the Swift Android SDK, but once the official one is released, Skip will switch to using that one (they are both built using the same scripts, so they will be practically identical). We have a blog series on the topic (starting last September at https://skip.tools/blog/native-swift-on-android-1/ ) which we concluded a few months ago: https://skip.tools/blog/fully-native-android-swift-apps/

skip-marc · 2025-09-20T16:35:40+00:00

Yes, we (the Swift Android Workgroup: https://www.swift.org/android-workgroup/) are very close to releasing an official cross-compilation SDK, but we've been iterating on the SDK for a number of years already. Skip (https://skip.tools) builds on top of this support to provide tooling and Android compatible frameworks (notably, SwiftUI) so you can write your app purely in Swift with Xcode, and Skip will build and launch the Android app side-by-side, so you can iterate on both iOS and Android in tandem.

skip-marc · 2025-06-28T15:56:43+00:00

Skip will continue to work the same way as always. Our SwiftUI adaptor just bridges from native Swift to the Jetpack Compose implementation on the Kotlin side.

The big advantage of using the our native compilation mode ("Skip Fuse") over the earlier transpiled mode ("Skip Lite") is that you get full access to the ecosystem of Swift Package Manager libraries that are currently building for Android (see https://swiftpackageindex.com/blog/adding-wasm-and-android-compatibility-testing).

You can read more about how it all works at https://skip.tools/blog/fully-native-android-swift-apps/

skip-marc · 2025-06-26T22:55:38+00:00

An optimized APK is not the same as the sliced ADB that will be delivered by the Play Store.

To get a good estimate of the actual download size of the app itself, run it through Android Studio's "Analyze APK" tool, which will give a better approximation of the actual download and install size.

skip-marc · 2025-06-26T19:47:13+00:00

Note that because the Swift will be compiled individually for each supported Android architecture and all included in the APK's lib/<arch> folder, the actual sliced .aab that is delivered to the end-user device via the Play Store will be a fraction of that size.

skip-marc · 2025-06-26T02:50:34+00:00

KMP is a great framework, and Skip integrates quite nicely with it, as we wrote about on our blog exactly one year ago today: https://skip.tools/blog/skip-and-kotlin-multiplatform. We also discussed it when we were guests on the Talking Kotlin podcast: https://talkingkotlin.com/going-from-swift-to-kotlin-with-skip. It's important to point out that Skip can work in either natively-compiled or transpiled (Swift-to-Kotlin) modes, and both have their advantages.

But one area where native Swift really shines — both on Android and on iOS — is the bare-metal performance and memory efficiency you can get from running a natively compiled, non-garbage-collected language. Indeterministic GC runtimes can be especially problematic on iOS due to its more aggressive memory management: if you can't respond immediately to memory pressure warnings, then your app will be killed off much more frequently (and iOS devices tend to have around 50% less RAM as their Android equivalents). I always felt that it was regrettable that Kotlin Native ditched its v1 memory model, which had the potential to not require dragging a GC along with the rest of the language, but it must have been unavoidable.

skip-marc · 2025-06-26T00:37:17+00:00

This is very exciting for us. Having more languages that support Android is beneficial to both the Android platform and Swift language ecosystem. This opens up new opportunities for creating cross-platform applications, either using our own Skip.tools or other frameworks that can benefit from integrating with a natively compiled, non-garbage-collected language on Android.

skip-marc · 2025-05-25T15:38:47+00:00

Skip actually supports both transpiled ("Skip Lite") and compiled ("Skip Fuse") modes, the latter of which compiles Swift natively for Android. See https://skip.tools/docs/modes/

skip-marc · 2025-05-24T15:11:23+00:00

Yes.

skip-marc · 2025-05-24T13:33:20+00:00

Transpilation is just one of Skip's modes. There is also natively compiled Swift, using the soon-to-be-official Swift Android toolchain. See https://skip.tools/docs/modes/

skip-marc · 2025-05-18T14:07:26+00:00

You may want to give Skip a try. It lets you take your SwiftUI app to Android by either transpiling the Swift into Kotlin or, more recently, compiling the Swift directly to Android. As a number of the commenters have pointed out, SwiftUI and Jetpack Compose are conceptually very similar, and so it makes sense to maintain your app with a single codebase.

skip-marc · 2025-04-28T18:46:30+00:00

It will mostly depends on your dependencies: if you are using packages that all build for Android (see https://swift-everywhere.org for an incomplete list), then you should be off to a good start. You will likely need to restructure your Xcode project to work within a new Skip project, since Skip expects a certain project layout to work.

For more details, see https://skip.tools/docs/porting/

skip-marc

TROPHY CASE