The Swift SDK for Android
116 comments
·October 24, 2025bsimpson
palata
> The most important question for every cross platform framework is what happens to the UI?
I kindly disagree. The first feature I want from a cross-platform framework is that it lets me write a native UI. That's why I like KMP: I can just share a framework with an iOS app built with SwiftUI.
Sharing business logic makes a lot of sense in a ton of cases and has been done forever (C/C++/Rust/Go libraries, etc). Sharing UI in complex apps, in my experience, always ends up being a "write once - debug everywhere" nightmare.
What KMP (and I'm hoping Swift for Android) bring is the possibility to share a Kotlin (respectively Swift) library instead of sharing code with C/C++/Rust/Go. So that an Android/iOS team can keep using Android/Swift without having to introduce a third language for sharing logic.
virtue3
Having worked a long time with client teams as a lead - this is always the biggest pain in the ass.
At one of my last phase startups I started shifting all our business logic stuff into our graphql server and treated it like it was part of the client teams. (we had ios/android/web as independent full apps with a very small team of devs).
Business logic is the real killer. Have one person suck it up and do it in typescript (sorry y'all) on the GQL/apollo server and all the clients can ingest it easy.
Send down viewmodels to the clients not data models. etc etc.
This helped DRAMATICALLY with complexity in the clients.
null
timsneath
It's worth noting that this doesn't add any expectations for how your UI is built. The example shown in the screenshot continues to use Jetpack Compose (Android's native UI) with Kotlin invoking Swift business logic. You can also use other UI frameworks on Android, of course, including some that are written in Swift.
One nice thing about this implementation is that it shares many of the same characteristics as Swift on other platforms: unlike some common alternatives, it's not garbage collected but uses reference counting; it uses the same underlying libraries, concurrency primitives and memory model.
Excited to see how folk use it... it's technology that will hopefully springboard some other interesting innovations.
[Disclosure: I work on developer tools and frameworks at Apple.]
wffurr
How does transpiration work without GC? I would think all the Kotlin equivalents would be GC heap allocated objects.
timsneath
This doesn't transpile. It cross-compiles to Android architectures using the NDK. You can see a very simple "hello world" example at the bottom of this article:
https://www.swift.org/documentation/articles/swift-sdk-for-a...
kridsdale3
The Browser Company did an amazing job of porting SwiftUI to Windows, where the element primitives in the language map to native Windows UI C++ classes under the hood.
Perhaps the future of Swift for Android is similar, where SwiftUI will map to Jetpack elements. That would be cool.
Remember on iOS and MacOS, SwiftUI is not "native". It's a description language that system frameworks interpret and create NSViews and UIViews and CGLayers etc out of.
mikeocool
> It's possible that Apple/Swift's mindshare among developers will lead to a significant number of apps shipping the Swift version for Android even if it means using Apple's UI
It doesn’t sound like this release includes bringing SwiftUI or UIKit to android, so unless you did a ton of work to replicate it (ala flutter) using Apple’s UI on android probably still isn’t really possible.
trevor-e
Very excited to see this as an official project!
I've been toying around with multiplatform frameworks like RN and Flutter for a side project of mine but they never feel right. I'd rather use the native UI per platform and have a nice way to share business logic. KMP exists but I think for most developers wanting to build an app it's more common to build for iOS first, and then port to Android later if the app gets traction. With a little foresight of keeping shared code in a Swift Package, it seems like that's getting more and more possible which is great to see.
a3w
> but I think for most developers wanting to build an app it's more common to build for iOS first, and then port to Android later if the app gets traction.
Is it? There seem to be a hundred million Java developers out there, that can do an Android app, plus even release that in-house or with minimal registration fees if single dev/sideproject.
For Objective-C/Swift, there seem to be ten percent as many devs.
I always only tinkered with Android apps in my spare time, but never managed to deploy anything to iOS.
Also, outside the US, iPhones are a 10 % niche product in private hands, but companies might use a lot of iPads or provide iPhones as work phones, so perhaps companies do think of both platforms as second class citizens (behind windows/browser as two other "OS-like" primary platforms)
cosmic_cheese
It probably varies from area to area, but in the US iOS first is common.
Having developed both, it makes sense.
iOS is by far the more profitable of the two platforms and its support burden is substantially lower — far fewer versions to think about with the bulk of users running 0-2 versions behind, single form factor (only size variants), zero manufacturer skin quirks/bugs to deal with. It’s a more fertile environment for getting up and running and getting the core product shaken out.
Android can come later when you’re out of rapid iteration and have the bandwidth to deal with the idiosyncrasies of the Android world.
twof
It's not really about the number of developers. If you're running a company in the US at least, most of your revenue is going to come from iOS users.
makeitdouble
The US still has a strong iOS market share, shipments just never go below 50%
https://counterpointresearch.com/en/insights/us-smartphone-m...
disiplus
for us its pixel phones, you can choose iphone if you want but most of us want pixel. so for me its macbook + pixel. I think the iphone only is unique to US.
frankus
I think business-logic-in-JavaScript is something cross-platform folks shouldn't snooze on either, with the usual caveats of not doing anything performance-critical or where an asynchronous API would be awkward (to be clear, using JavaScriptCore or QuickJS or the like, not just running in a WebView)
But it'll run on iOS (v7.0+), Android (I think more recently) and of course web and server-side. And most importantly, it's hot-reloadable, as long as you don't run afoul of platform gatekeepers (i.e. use it for bug fixes and minor behavior changes, not like whole new features).
One of the frustrating things about mobile development is that once you ship a version, that version will almost certainly be running on at least someone's device indefinitely without being upgraded. My day job is even on step further back in that we have to get our customers to update the version of our SDK that they're integrating (which for many of them means contracting out because they don't have an in-house mobile dev team), before they ship an app update, which then needs to be installed by end-users, whose device might not even support the new deployment target…
(I've been trying to sell this to the bosses for the last 9 years or so, and never gotten the go-ahead, so there could be aspects I'm missing, but it always seemed like a huge missed opportunity).
trevor-e
OTA updates are definitely nice to have and I'm surprised there's not a way to do so with native iOS since RN and Flutter already support it. Technically it is possible with dynamic frameworks.
In practice though it's somewhat easy to workaround the lack of OTA with dynamic server configuration for clients.
bpavuk
yes. there is an aspect you are missing.
no one in their right mind wants to bundle Chromium with every app install, and every Discord user hates mobile Discord app, which is, guess what? uses Chromium!
NSUserDefaults
For JS driving the business logic you do not need a browser to run it. On iOS there is JavaScriptCore and there are other Javascript runtimes out there that are quite small.
That said, it is true that Javascript may not be the right choice for every app and some developers may be used to better language features and performance than that.
iknowstuff
Your profile is full of incorrect assertions about software. What do you do for a living
cyberax
React.Native doesn't use Chromium.
palata
> KMP exists but I think for most developers wanting to build an app it's more common to build for iOS first
This sounds US-centric to me.
The advantage of KMP is that it is pretty mature and it is used in big apps like Google workspace (Google Docs etc), so it feels like it may be in a really good position.
I used to be exited about Flutter when it started, but the speed of major releases (by the time I had rewritten my app for Flutter 2, Flutter 3 was out, or something like that) and it did not seem to get so much traction (Dart is fun, but well).
KMP builds on top of Kotlin, with big investment from JetBrains and Google. That looks extremely promising to me.
icar
At Proton they use Rust for shared logic (their claim is more than 80% of the codebase iirc), and platform specifics for the rest.
bbkane
https://proton.me/blog/authenticator-rust - I think this is what you're referring to? Looks really nice
pzo
react native do uses native UI per platform in contrast to flutter or compose multiplatform. React Native improved a lot - it's not the same technology that has been 5 years ago. Especially this year there were plenty of improvements also regarding speed but in react native and community plugins (new architecture rolled in, react compiler, hermes v1, nitro modules, flash list v2, legend list, react native skia, react native webgpu, expo use dom) Tooling in JS/TS ecosystem also improved a lot.
trevor-e
Yes it uses native UI by wrapping the underlying frameworks, but that still means there is a layer in between that has to be updated with fixes and new features. Every RN project I've tried in the past turned into a dependency mess since you find edge cases that are not supported by the framework.
It's definitely gotten better like you said but I just prefer to work with the native platform code even if it's a bit of extra effort.
ivm
This is already possible with .NET and MvvmCross: a shared core library plus native UI projects for each platform. UIKit feels great in C# and it’s all been working quite well since Xamarin times, with access to the Nuget ecosystem.
trevor-e
Xamarin with .NET and MvvmCross falls into the same bucket as RN and Flutter IMO, unless something changed since the last time I looked.
ivm
Not at all, but it’s important not to mix up Xamarin (nowadays just .NET) which is basically native bindings for C# and Xamarin.Forms UI framework (nowadays MAUI) which is write-once approach like RN.
The former is exactly what you are talking about: building native UIs twice and then sharing the common logic.
w10-1
I read this announcement mainly as proving the success of the new support for SDK's. Previously, supporting another platform required invasive hodge-podge of CMake tangles at best.
Swift SDK's are a way for anyone to support any platform, as proven by the Android guys doing it on their own. There are also SDK's for Linux, wasm, and embedded (and soon, windows?). So long as you play by SDK rules, Apple won't stop you from porting Swift to a new platform, even on competitive platforms like Android.
(The inter-op story with the JVM languages is still being written; it reduces to either the C/C++ FFI or the two incomplete duals of Java's legacy JNI and newer FFI/Memory interfaces. Prototypes work fine when the semantics are the same, but beyond that, there be dragons. Cross-platform UI frameworks are similarly (and likely eternally) afflicted with bright and dark spots.)
mosura
I hope they actually stick with this. Swift embedded, for example, is a sort of proof of concept more than viable platform, and you end up battling that more than the problem you are trying to solve.
It is a shame because aesthetically Swift is easily the nicest of the modern safe languages, but there have been really odd noises in the community about project leadership that sour things.
null
ls-a
Thank you. Please kill RN and Flutter already. I'm done with square UI apps that handle touches after two days
turtlebro
You can set the corner radius to whatever you like in Flutter, also the framework is quite fast, if an app doesn't respond to touches it's likely a poorly made app
ryeights
Flutter has a long-standing issue where every interaction is subject to a 1-frame delay on iOS (P2 since 2022)…
https://github.com/flutter/flutter/issues/110431
Not to mention the stuff with shader compilation lag
rumori
I’m curious to hear where you think this is a showstopper. I’ve been testing some Flutter apps lately and other than some mismatches in platform UI elements they have been smooth. I wonder what you would think of apps like Kagi News.
turtlebro
Sure you can find some issues if you look at it hard enough. In the real world scenario, it's very possible to ship a performant, functional app in Flutter and has been for some time now. It also brings some of the best development experiences with Dart, consistent declarative paradigm & hot reload. Like all things, it's a trade off, for me it's very hard to merit maintaining 2x native apps.
There are many, many people out there shipping Flutter apps, and many, many users using those apps. So please stop the hate maybe?
bitpush
I have no love for RN and Flutter, but what makes you think Swift on Android will be even remotely close to what Flutter and RN has?
If anything, Apple will launch this and quickly forget this exist.
bpavuk
although Apple has tremendous influence over Swift, Swift for Android is a grassroots effort, as said in the link. if community needs it, community will maintain it, and Apple won't get in the way. why would they?
bitpush
I guess that goes to the larger point then. OP was saying Swift for Android will finally solve all the issues of Flutter & RN, presumably meaning Apple with its $$ and might will do it.
If it is a grassroots project, it has even bleaker outlook then? I wish them success however.
palata
I have been sharing code between Android and iOS for a long time. Sharing the UI has always been a nightmare for non-trivial apps.
What makes sense to share is complex libraries, and usually I have been doing that with C/C++/Rust libraries. But it means that the team now deals with Kotlin, Swift and one (or more) of those "sharing" languages.
What I believe KMP and Swift for Android bring is that teams will be able to share libraries in Kotlin/Swift, so that they can keep writing in their preferred language without having to introduce C/C++/Rust.
I believe this approach is vastly superior to any kind of framework that tries to share the UI. Mobile devs, in my experience, want to use the native tools: Kotlin for Android and Swift for iOS.
TheJoeMan
Does this project tie in to the SKIP transpiler? https://skip.tools/blog/bringing-swift-to-android/
I have an existing Swift / SwiftUI app that I am looking to port to Android, and have been not wanting to move to React Native.
marcprux
Yes, Skip has been using our preview release of the Swift SDK for Android in our Fuse mode for over a year, and it has proven to be very popular! You can see our blog post about using it to build a completely native SwiftUI app for Android at https://skip.tools/blog/fully-native-android-swift-apps/
To clarify a couple of other comments about transpilation vs. compilation, Skip has two modes: Skip Lite, whereby your Swift code is transpiled into Kotlin, and Skip Fuse, whereby Swift is compiled natively for Android using the Swift SDK. Skip Fuse and Skip Lite work side-by-side, where Skip Lite is used to provide bridged integration to many popular Kotlin frameworks on Android (Lottie, Firebase, Stripe, etc.). You can read about the comparison between the two modes at https://skip.tools/docs/status/ and see a subset of our available modules at https://skip.tools/docs/modules/
We are very excited that the Swift SDK for Android is now official and we can switch over from using our own preview build of the SDK to the officially supported one.
joanniso
Yes, Skip is a major contributor to this effort!
wahnfrieden
You don't need to use the transpiler anymore. Skip added native Swift execution on Android recently. It has much greater compatibility than the transpiler (though they maintain both).
jajuuka
"You got Kotlin in my iOS."
"You got Swift in my Android."
bradleyy
Perfectly delivered, the Reese's commercial that keeps on giving. Although to fully match the analogy, there'd need to be some form of Kotlin+swift hybrid with a crinkly wrapper.
ignoramous
Kotlin on iOS is statically compiled and interops with Swift/ObjC natively. Don't think KMP on iOS is even running a VM like Flutter has to with Dart?
null
oblio
How solid is Kotlin on iOS?
tomovo
If you mean Kotlin Multiplatform, it works pretty well. Not easy to debug, the GC is a bit weaker than the Android implementation and optimized builds can get crazy slow as the app grows. The interface uses auto-generated ObjC headers which are very verbose. Native Swift API is in beta. Overall still worth it for a commercial app, I think.
afavour
This is really interesting. I’ve made cross platform mobile libraries before and ended up using Rust… which was fine. But there’s a huge built in advantage to using a language one half of the problem is already fluent in. Curious to see how well it combines with Swift/Webassembly.
guelo
Less necessary to be fluent nowadays with LLMs.
lukko
I would love if I don't have to port my whole iOS app to Android manually. How exactly would this integration work if say business logic is handled by Swift - I'm guessing UI and SwiftUI would not be supported initially?
My app [0] uses a lot of metal shader code - I'm guessing there's no easy way to bring that across?
fooker
It'll take you thirty minutes to port the shaders with a modern LLM.
I am not joking. I have done this. Shaders are pretty simple. You'll have some weird artifacts but thats more because of platform differences than translation errors.
seivan
[dead]
joanniso
Metal cannot be used on Android. Your business logic can be ported - if it's separated as a library. If you don't want to separate it, Skip can handle bridging a lot of Apple libraries including SwiftUI.
lukko
Thanks - I see, so swift packages for everything.
What would be the equivalent shader / GPU language on Android? OpenGL?
thomspoon
OpenGL or Vulkan, you might be able to have some luck transpiling metal shaders to spirv-cross at a cursory look
rahkiin
Vulkan with glsl to spirv compiler would be equivalent
hoppp
Yeah I would also like to see SwiftUI but its apple ecosystem only.
wahnfrieden
https://skip.tools ported SwiftUI to Android.
outadoc
I'm a big lover of Kotlin Multiplatform, but I think this is pretty cool anyway. I could imagine making a native Swift library shared between the platforms for memory-sensitive work. I'm not sure about using it to write an app's entire business logic, KMP is going to be more mature for a while for this.
oblio
Do you build desktop apps, too, with Kotlin Multiplatform? How mature is it overall?
icar
I want to know this as well. My only interaction with a Kotlin Multiplatform app is Jetbrains Toolbox, and it's slow to start, has a lot of input lag and overall feels sluggish.
mr7uca
Jvm desktop is honestly the target with the best support. I always build on desktop during mobile dev first because I don't need to deal with connecting a phone or emulator. Second resizable windows by default is so helpful when building for many screen sizes. Also it has hot-reload now
orliesaurus
Interesting to see excitement around this release...
BUT beyond cross‑platform hype there's a practical question... what developer tooling will look like... Are we getting first‑class debugging, package management, continuous integration for Android targets...
ALSO adoption often comes down to licensing and governance... open SDKs thrive when the steering group is transparent and responsive...
And it's worth remembering that bridging two ecosystems isn't just about code... it's about aligning design idioms, APIs and expectations... Without that you end up with uncanny valley apps...
The most important question for every cross platform framework is what happens to the UI?
Adobe products (both the Creative Suite, and their Flex Builder environment for Flash app) had their own design system that felt foreign on every platform it shipped on. If you wanted something that felt native, you had to reimplement e.g. Apple Aqua in Flash yourself.
Flutter goes out of its way to do that work for you, aiming for a "Cupertino" theme that looks-and-feels pixel-perfect on iOS.
React Native tries to delegate to platform primitives for complex widgets, so scroll views still feel like Apple's when on Apple's platform.
Just about every top-level comment here is talking about that in one way or another; yet the blog post doesn't mention it at all.
It's possible that Apple/Swift's mindshare among developers will lead to a significant number of apps shipping the Swift version for Android even if it means using Apple's UI, simply because they can't be bothered to make something bespoke for Android. Then again, Apple takes so much pride in its design language that it might not be willing to implement anything that feels good on a platform they don't own. If they were to ship an API-compatible widget toolkit, it might e.g. use intentionally bad spring physics to remind you you aren't on an iPhone.
I wonder how big the community part of this is. Is this an open source project of non-Apple people who are trying to break Apple's platform out of its walled garden? Is a lot of it funded by Apple? Ultimately, that's going to shape a lot of how this plays out.