The Swift SDK for Android
Key topics
The Swift SDK for Android has been released, allowing developers to share code between iOS and Android platforms, but the discussion revolves around its implications, limitations, and comparisons with other cross-platform frameworks.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
21m
Peak period
127
0-12h
Avg / period
26.7
Based on 160 loaded comments
Key moments
- 01Story posted
Oct 24, 2025 at 4:06 PM EDT
2 months ago
Step 01 - 02First comment
Oct 24, 2025 at 4:27 PM EDT
21m after posting
Step 02 - 03Peak activity
127 comments in 0-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 30, 2025 at 3:34 PM EDT
2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
No. The vision document[1] lays out the direction of travel. Currently the focus is on shared business logic and libraries, rather than full native applications (although that's certainly a goal, albeit a very long term one).
[1]: https://github.com/swiftlang/swift-evolution/pull/2946/files
This doc you linked is from August.
The blog post from today includes, in fact at the very top an XCode Swift project emulating a Pixel 9.
The docs include a detailed Getting Started for Android and they even have an Android examples repo.
Hence the SDK.
By all means, it very much is possible to build Android Swift apps in XCode.
https://www.swift.org/documentation/articles/swift-sdk-for-a...
You can build the Swift part in Xcode, VSCode or your favorite editor. But the Android builds don't work with Xcode today.
(disclaimer: I work on the Skip.tools product)
Same way there are C compilers for Windows and Linux, but that does not mean binary compatibility.
But it's not there yet
The example Activty I saw is pretty rough ergonomically, but I have no doubt an ergonomic, SwiftUI-like library could be built on top of what’s currently there and/or on the roadmap.
Without Skip, you can still share other code through JNI - similar to Kotlin Multiplatform.
Is Swift now going to be the de facto language for Mobile (and maybe Desktop) development?
React Native is popular because there’s a thousand times more React devs than native devs.
And people like to use what they know.
Also React dev experience makes anything Swift related look like stone age technology
How so?
If the project is simple to port over then it should have just been a website.
- OTA updates, skipping Apple review for every little thing. Really speeds up builds too.
- Repack and module federation aren’t even possible on native
- running tests on iOS - 2 minutes minimum and having to boot the simulator in most cases. RN - seconds
- IDE with all sorts of plugins, that are impossible on Xcode, Rozenite
- AI trained on lots more React code, where they usually struggle to use Swift 6 properly
and a bunch more things
Exactly this. And they come cheaper. JS dominance in development stems from business logic, not from quality of development environment or tools, or developers preference.
Please share what Kotlin has that Swift doesn't
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.
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.
How miserable it would be trying to write Java or kotlin targeting iOS apps. I think this will be the same.
Just use the native tools and languages for the platform. Swift/Objc/xcode for iOS. Java/Kotlin/Android Studio for Android.
You will be so much happier.
Android studio is way better than XCode though
I’m more mixed on Android Studio. It’s fine I guess, but I wish its UI were more deeply customizable. Many of its design decisions irritate me.
I’m mostly in Neovim writing typescript (react native) luckily.
With Android Studio, I'd say the ways that it being an IntelliJ IDE puts it above Xcode are cancelled out by other aspects of Android development, which can be abysmal. Swift Package Manager and Clang/llvm code stripping have never made me want to tear my hair out the way that Gradle and Proguard have for example.
I agree that other than JetBrains everything else about it sucks ass.
Browsers are pretty much the gold standard here, ironically. You might have to care if it's Firefox or Chrome but it's very rare for you to have to care if it's Firefox on Windows or Mac or Linux. It's exactly why React is simultaneously horrible and everywhere.
So it can be done, it's just a question of whether that framework has done it well, ideally while also doing other things well (unlike React).
What happens in the Java/Kotlin case?
My app [0] uses a lot of metal shader code - I'm guessing there's no easy way to bring that across?
[0] https://apps.apple.com/app/apple-store/id1545223887
What would be the equivalent shader / GPU language on Android? OpenGL?
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.
That's... not encouraging.
"You got Swift in my Android."
https://kotlinlang.org/docs/native-overview.html
We're looking forward to native swift export to go stable - it's currently experimental / beta.
> looking forward to native swift export to go stable - it's currently experimental
What are the timelines given for a stable release?
And when it does, what else would you say are the next big things annoying/missing in terms of devex?
The other big problem is debugging. It's impossible to breakpoint kotlin when debugging from swift, so some bugs that are realised only from the swift client side can be tricky and time consuming to fix.
In fact, you can even link native frameworks into your Dart code.
[1] https://dart.dev/overview#native-platform
[2] https://dart.dev/interop/c-interop
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.
You use this construct for unwrapping nullable fields, for example something like this:
guard let httpResult else { return }
Note that you don't need to assign the value to itself in modern Swift. This line takes an optional (httpResult?) and returns early if null. If not, you can use it with strong guarantees that it's not nullable, so no need for ? or ! to unwrap it later in the scope.
It is, when `self` is captured weakly in a closure, and that closure is outliving the instance.
The big problem with swift is “expression has ambiguous type” and “expression took too long to type check”. Those don’t trade in code aesthetics but are problems I’ve never had in another language.
Yet Apple has managed to create WatchOS. I don’t know what is the portion of Swift, however.
https://github.com/flutter/flutter/issues/110431
Not to mention the stuff with shader compilation lag
There are many, many people out there shipping Flutter apps, and many, many users using those apps. So please stop the hate maybe?
Flutter apps on iOS just do not feel native, that’s a fact. It doesn’t mean you’re a bad person for using Flutter.
Flutter has a secondary problem which is (IMO) a dearth of well-made libraries and showcase apps. Most everything feels half-baked.
The Kagi News app, which I have just installed, doesn’t seem to fall into this category. But like most Flutter apps the fully Material design makes it feel very out of place on iOS. Flutter typography is still broken, with characters tracked out way too far. And the scrolling and touch interaction feels, well, Flutter-y. It’s inherent to the platform
If anything, Apple will launch this and quickly forget this exist.
If it is a grassroots project, it has even bleaker outlook then? I wish them success however.
React isn't going anywhere but I expect 5 years from now KMP will be the tool of choice for native app startups.
Just No. Nobody will kill >30% of apps on the iOS store. Flutter is simply a massively superior development experience overall compared to the horrifying disaster that is SwiftUI. SwiftUI is so utterly pathetic that more than a third of all apps are now being written in Flutter.
"The compiler is unable to type-check this expression in reasonable time" -> one of the most atrocious and common errors that increases cortisol levels and reduces life expectancy amongst mobile developers.
Please kill SwiftUI already. For the sake of Humanity.
The app build and upload process is painful enough as it is, I don't want more of it.
Disclaimer: I work on RN nowadays.
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.
The former is exactly what you are talking about: building native UIs twice and then sharing the common logic.
Otherwise, I’ve been working with it since 2018, my app now has around 500k installs on both stores, and I’ve encountered very few issues related to the stack itself. Mobile .NET has been steadily improving, and LLMs have made the two-native-UI approach much easier: after building an iOS UI, I ask Claude to repeat it on Android for the same view model and get about 80% done instantly.
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).
In practice though it's somewhat easy to workaround the lack of OTA with dynamic server configuration for clients.
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!
And Discord mobile app on iOS doesn’t even use RN, it’s a native application.
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.
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)
https://counterpointresearch.com/en/insights/us-smartphone-m...
Global revenues on the iOS app store have always been significantly larger than Google play, even with only ~30% of the global smartphone market.
> https://sqmagazine.co.uk/iphone-vs-android-statistics/
For instance, if you're Netflix, do iOS user bring you more revenue in the US ? What if you're Hertz ? What about Walmart or Costco ? The only factor will be how many of your users are on iOS vs android. It's a different story if you're a gaming company and target whales of course.
Notably, that's a situation that actually matters for cross-compatibility. There's no web client for SnapChat. Hertz & Costco could point Android users to the web with few repurcussions, IMO
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.
Having worked at multiple companies making apps in the US and the company I work at right now which is a company almost everyone knows the name of and the vast majority of our revenue comes from our native apps - practically every feature we build is iOS and web first and only if it performs well do we even consider adding to android most of the time. And it's primarily because product/execs know iOS users are more likely to pay for things.
It's sad as an android user myself, but android is very much a second class citizen in the US
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.
I've talked with colleagues in several companies and the story is always the same: the iOS repository is a patchwork of horrible patterns that shatters when you update to the latest iOS target.
At my current employer it takes 4 iOS devs longer to implement things than it takes 1.5 Android devs (0.5 because the other .5 is spent being Team Lead and architecting, planning, endless meetings etc).
When I talked with the KMP team at Google they were mentioning that their most enthusiastic user base at Google was iOS developers, begging to be saved from their tooling nightmares.
I'm sure some defensive devs will show up here but I've been at 5 different places over my decade at work and every single one of them has had endless struggles hiring iOS devs, maintaining iOS projects etc.
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.
120 more comments available on Hacker News