Swift on Android: Full Native App Development Now Possible
Key topics
The Swift programming language just leveled up its Android game with the release of Swift Stream IDE v1.17.0, enabling full native Android app development without requiring XML, Java, or Kotlin. As developers dig into the details, they're exploring how SwiftPM dependencies are handled and how Java/Kotlin code is bound to Swift, with some pointing to existing libraries like jni-kit and swift-java as potential solutions. The conversation is sparking interesting discussions around interoperability, with some commenters drawing parallels to similar efforts in Rust and Flutter, and others raising concerns about the long-term viability of certain approaches due to Google's track record on Java support. As the community weighs in, the threshold question remains: what's the crossover cost for Swift and Android developers looking to collaborate?
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
N/A
Peak period
101
0-12h
Avg / period
22.9
Based on 160 loaded comments
Key moments
- 01Story posted
Jan 3, 2026 at 6:39 PM EST
5d ago
Step 01 - 02First comment
Jan 3, 2026 at 6:39 PM EST
0s after posting
Step 02 - 03Peak activity
101 comments in 0-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Jan 8, 2026 at 1:59 AM EST
17h 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.
Under the hood, projects are powered by SwifDroid, a framework I built that handles the Android application lifecycle, activities, fragments, and UI widgets (Android, AndroidX, Material, Flexbox) while automatically managing Gradle dependencies. The IDE compiles Swift, generates a full Android project ready for Android Studio.
This is the first public release. Both tooling and framework are open-source and MIT-licensed.
(we're trying to do something very similar with Rust instead of Swift)
https://github.com/swiftlang/swift-java
On top of that, the IDE also auto-generates required Java/Kotlin classes on the fly, for example, for Activities.
I was looking into something similar, on Flutter it uses FFIgen and JNIgen, might be something to look into on the Rust side. From what I've seen, it's quite difficult from pure Kotlin to Rust, as I was looking for the equivalent of the flutter_rust_bridge package when experimenting with Compose Multiplatform, as I have some crates I need to use, but I ultimately gave up because it was not straightforward at all.
Then the questions is: roughly what percentage of Kotlin or Flutter apps could be writable in Swift? Today and next year?
Gradle can be a pain, but if I look at what our neighbors at the iOS team experience (constantly having to manually merge project files, not being able to simply import some libraries, ...) it's hardly a nightmare.
Specifically adding dependencies is super easy? Just specify which repo they're in (mavenCentral or Google or whatever) and add dependencies under "dependencies". When running or syncing, Gradle does the rest.
I find that IntelliJ IDEs are fine, but not nearly as amazing as they're often hyped up to be, and similarly while Xcode has problems it's not nearly as bad as is often claimed.
My experience is somewhat colored by Android Studio and JVM ecosystem stuff like gradle and proguard though, which have been more cumulative pain for me than anything Apple-side in a long time (Cocoapods was pretty gnarly but SwiftPM has fixed that).
[0] https://archive.org/details/mac-osx-mojave-iso
It allows you to easily install and maintain several versions of Xcode (beta / RC versions).
And, more importantly, uses aria2 for HTTP download, which has resumability.
Xcode is so sluggish it's slower than an electron app despite being native, the xcode app upload is so broken even Apple released a third party tool to bypass their own IDE and its undocumented config files look like from the 90s and do not work well with git.
The UI is sort of okay but that's not going to cut it. You can feel the decades of cruft in this IDE, it feel like using Borland.
react native flutter ionic
and now swift.
it seems dart + flutter still is the only way to do all targets (cli/web/iOS/android/desktop) though. react native being very close (albeit needs electron).
it surprises me that this hasn't been perfected. surely some big company would look at their balance sheet and see it's worth it even if you take a 10% performance hit on each platform, assuming you can share 90% of the code.
There's been a trend of improved DX for languages used in app development:
ObjC -> Swift
Java -> Kotlin
Javascript -> Typescript
...Dart feels like the before with no after, even though it got traction in the era of the Afters.
> if you have an `enum Color { red, blue }` and a function takes `Color`, you can just do `f(.red)` not `f(Color.red)`
Dart is getting new features pretty fast, they really started focusing on the DX more after Dart 2 and now especially after Dart 3. Macros were supposed to ship but it was incompatible with the goals of fast compilation, so other sorts of smaller features will ship instead.
Also, statement based instead of expression based, and not immutable by default are kind of a drag; not the end of the world but a bit unpleasant, IMO.
It's aged like the recent languages but feels clunkier like a language that's much much older.
And I just checked the Dart release notes from all of 2025: https://dart.dev/resources/whats-new
Great progress! But smells a lot like the language I had it pegged for when "underscore as a wildcard" lands in February 2025, 2 years after pattern matching lands.
How did they ship pattern matching in 2023, with a million examples of how to do it right already hashed out and in the wild... and then not figure out a wildcard symbol for 2 years?
-
* Dart was awful, lost to Javascript because no one rated it highly enough to justify moving off Javascript, and was practically dead until Flutter dusted off the corpse and pivoted away from their browser goals... so super weird revisionism to act like we're talking about some beloved evergreen language.
Dart wasn’t awful. It wasn’t adopted at the time because it had a distinct runtime that would require splitting web in two which nobody wanted. On top of that it gave Google too much power, because now they would control both runtime (V8) + language (Dart).
TypeScript won and became king because it was pretty much JS 2.0 instead of JS++ like Dart.
I'm sure that's a really cozy idea, but doesn't pass the "common sense" test: a bit like your random misuse of the term FUD.
-
The simple reality is it wasn't very good, so no one was rushing to use it, and that limited how hard Google could push it. ES6 made Javascript good enough for the time being.
Dart 1.x had a weak type system, and Dart 2 was adding basics Kotlin already had almost 2 years earlier: that was also around the time I first crossed paths with Flutter, and honestly Flutter by itself was also pretty god awful since it was slowly reinventing native UI/UX from a canvas.
(It was a lot like Ionic: something you used when you had a captive user-base that literally couldn't pick a better product. Great for Google!)
"In my version of history"
It takes two seconds to find this if you weren't there when it happened. Google had a fork of Chromium with Dart VM called Dartium, it wasn't a matter of resources. Industry flipped Google off, plain and simple.
Educate yourself before making such claims, the decision to not adopt Dart wasn't because of its technical merits as a language.
The rest of your comment is just your opinion, so you do you. I'm not a Dart or Flutter devrel team to sell you their product.
To understand just enough to regurgitate what happened, but miss why it happened... and then assume someone who's pointing at the much more relevant why is just plain wrong.
Because the why requires actually understanding of things like developer mindshare rather than regurgitating search results.
-
The hint I'll leave if you're willing to consider maybe you don't know everything ever... look at who's feedback is being promoted when Chrome wants to do obviously unpopular things on the web: https://github.com/webmachinelearning/prompt-api/blob/main/R...
https://github.com/mozilla/standards-positions/issues/1213
And model for yourself what happens if developer interest exceeds vendor refusal in magnitude, so Google just ships the thing, without a feature flag, to a massive percentage of the web-going world.
We shipped support for `_` as wildcards in patterns with Dart 3.0 when pattern matching first shipped.
However, prior to Dart 3.0, `_` was already a valid identifier (as it is in most other languages). The feature you're mentioning from last year was to remove support for uses of `_` as an identifier outside of patterns. This way `_` consistently behaves like a wildcard everywhere in the language. We didn't ship that in 3.0 because it's a breaking change and those are harder to roll out without causing a lot of user pain.
It's OK to not like Dart. There are multiple popular languages for a reason. But it is helpful when communicating about a language to others to be accurate so that they can make their own informed opinions.
It also inherits all of the bad parts of the JVM. Crappy build tooling (gradle), and then the slow startup and high memory usage.
Currently Kotlin is far and away my favorite language but I also haven't looked into the newer languages recently and am interested in hearing pain points people have. Especially if it isn't annoyances with Gradle
There's also things like Swift's guard statements that can help make intent clearer and read a bit more nicely.
The main thing though is that Dart has pub.dev and a CLI that makes it extremely easy to add packages, via `dart pub add`. If I do want to go more of a functional route I'll just use Rust instead, it has all of what Kotlin has and more, plus a similar streamlined package management as Dart in the form of `cargo add`.
You have other platforms like Google earth who when it was time for a proper rewrite went with flutter and dart along with a bunch of Google cloud stuff and Google Ads.
The "layoffs" were not any of the core team, it was just an offshoring, of infrastructure devs at Google that happened to work on Flutter builds, to Europe where they rehired for the same positions there.
Google's wildly popular NotebookLM is a recently released Flutter app, for example.
> Google is throwing their weight in on KMP
Hahah.
And what exactly orchestrates the process of compilation (invoking Kotlin compiler + fetching dependencies)?
My point is that the fundamental difference between Flutter and KMP is not at all Gradle.
Last time I checked, Flutter was relying on messaging. KMP leverages FFIs. Flutter is a framework, KMP is not. If all you see is the command line you invoke to run the build, I think you're missing a lot.
Regarding KMP specifically, I didn't find it much use to only write business logic in one language, while still having to rewrite the UI up to 6 times (mobile, web, desktop), I'd rather have everything all in one.
Compose Multiplatform looks promising as it's Flutter-like in that it renders its own UI but it's still quite early, I know they say it's "stable" but when I used it, it really didn't seem so, plus the package support is extremely lacking compared to Flutter and of course the behemoth that is React (and Native)'s npm.
These days I'm looking forward to Dioxus, they're making their own native renderer similar to Flutter but especially for web, they are not doing the canvas trick, because they actually use plain HTML and CSS as their markup languages so they can compile directly to browser standards sites while still having a non-webview experience on mobile and desktop.
Flutter is still bad on iOS and macOS. No Liquid Glass (except some weird hack attempts that look and behave badly). Liquid Glass isn't an optional decoration, it's the name of the new system-wide UI. Leaving it out of your app is like committing to iOS 6-era skeuomorphic design after iOS 7.
Edit: Several cross-platforms frameworks can do Liquid Glass:
- SwiftUI by using Skip for Android
- SwiftCrossUI
- React Native
I'm glad to see that I can finally target iOS as the first-class citizen, using Apple technologies, and then run that code on other platforms. Instead of having to use frameworks that treat iOS as secondary when it is by far the biggest money-maker for most apps.
No cross platform stack can do Liquid Glass yet. You have to wonder if that was one of design goals.
This is pretty funny because you just listed SwiftUI three times but in different configurations. They're not truly cross platform, they just wrap Apple's native design code. In contrast, I can (and do) use a package like liquid_glass_renderer to get Liquid Glass everywhere, on all my devices, with one codebase.
Maybe it will get there... Meanwhile I would rather use technologies that provide the full experience on the platform where it matters, and would never want those liquid components on platforms like Android or Windows anyway.
> and would never want those liquid components on platforms like Android or Windows anyway.
That's where we disagree then, I like the design itself but don't like it stuck on only one platform. I make apps with wholly custom UI designs, not following any particular OS' "native" design, and that's why Flutter is so powerful, because I am not constrained to what pixels I can render to a screen, nor should I be.
Of course it’s optional. Some of the most popular apps on the planet ignore the local UI conventions of their parent OSes entirely.
TikTok is a Flutter app. It looks identical on iOS and Android. It uses basically no native UI elements.
It’s a pretty well-known strategy to create apps that look identical on all platforms so that you lessen your customer confusion and your support burden. The fact that Spotify, Facebook, Uber, and Reddit look exactly the same no matter what platform you’re on is more important than complying with OS design guidelines and UI elements.
And I hate every one of those apps (well, back when I used Facebook, years ago, I did), because they’re just bad iOS citizens. I, as most iOS users do, don’t care what apps look on Android. For Android users, it’s the same with iOS. Making shitty cross platform apps is all about branding and saving some money for developers, nothing about the users.
What does “bad iOS citizen” even mean?
It’s not even about saving money for developers, it’s about the fact that your users expect a consistent experience.
Imagine if you watched an NFL game in NBC and the on-screen graphics were different if you were watching on a Samsung TV versus an LG TV. That’s the issue with native app UI elements (and it would quite literally be an issue with smart TV app platforms which are way more fragmented than iOS versus Android).
1. Spotify, Uber etc are popular because of their product, not the pure quality of their apps. People use Uber because they want to cheaply get somewhere, and Spotify cause that’s there all their shared playlists are.
2. People buy whatever tv is on sale when their old one breaks, but the vast majority will stay with their phone platform, so couldn’t care less what their apps look on the other platforms out there.
So, native experience does matter, but obviously only as one of multiple deciding factors.
> What does “bad iOS citizen” even mean?
Doesn’t look like native apps, doesn’t feel like native apps (come on, most multi platform frameworks don’t even get the scrolling right, one of the most basic forms of interaction), doesn’t use all of the platforms features to their fullest, as applicable for the type of app.
But it really doesn’t matter either way. The point is that TikTok doesn’t follow any OS conventions.
Disclaimer: I have seen teams writing mobile apps in Qt, and it was systematically a lot slower to develop, with a lot of pain, and resulting in worse apps. Even if you only have C++ devs, I would argue that it may be worth giving them the time to learn a modern language and write the mobile app with it.
I'd love if you could also contact me (my socials are in my profile) as I'm developing a set of components to help exactly in that situation.
They were developing non-trivial mobile apps. The kind where you use your fingers on a touch screen, but that are more complex than just showing a text and an image. Say Google Maps, or WhatsApp.
The problem was not the lack of components: the problem was that it was C++. C++ is more complex to write correctly than Swift or Kotlin and harder to debug. Which made those teams measurably a lot slower. It's just the wrong technology for the use-case, IMO.
> in C++ you can write performant code
This almost certainly does not matter for a mobile app, and definitely not for the UI part. In case your app has to do something that may need C++ (e.g. computer vision), then you can just call a C++ library over FFI.
> C++ isn't that complicated these days
I didn't mean that it is complicated. I can totally write C++. What I meant is that it is more complicated to get it right than modern languages. If users complain about a segmentation fault, it's often pretty tricky to debug. In Java/Kotlin, you will get an exception that tells you exactly which line crashed.
On top of that, C++ is slower to write. Again I have been able to compare teams working on the same app both in C++ and in Java/Kotlin/Swift (Java is not exactly a modern language, but still it's a lot faster to develop with).
And after all those disadvantages of using C++ for a mobile app, you end up with a UI that doesn't feel native to the platform.
No, in the mobile space I've only used React Native and QML with C++.
> This almost certainly does not matter for a mobile app, and definitely not for the UI part.
I disagree. For example, I expect block editors to handle large texts efficiency - both in terms of power draw and performance. Writing in a non-compiled language already puts you in a disadvantage in both aspects. But this is just the standard I set to myself - the entire industry clearly has different priorities.
> I didn't mean that it is complicated. I can totally write C++. What I meant is that it is more complicated to get it right than modern languages. If users complain about a segmentation fault, it's often pretty tricky to debug. In Java/Kotlin, you will get an exception that tells you exactly which line crashed.
Yep, I generally agree, tho with good debugging tools and LLMs I have found this to not be a problem anymore.
> On top of that, C++ is slower to write. Again I have been able to compare teams working on the same app both in C++ and in Java/Kotlin/Swift (Java is not exactly a modern language, but still it's a lot faster to develop with).
I write in TypeScript at my day job and C++ for my side projects and I don't feel like I'm slower in C++. Again, I'm using the subset I'm conformable with.
> And after all those disadvantages of using C++ for a mobile app, you end up with a UI that doesn't feel native to the platform.
That has certainly been the case, and what I'm trying to fix - because I've proven that it is fixable by caring about UI/UX. QML is great for UI, it's just that Qt developers (both the developers of Qt and those using it) don't care much about those things. But it's definitely posiible to get good results. For example, I'm working on SwipeStackView like other iOS apps have in QML, and I'm liking what I've made so far: https://rubymamistvalove.com/notes-mobile-swipe-stack-view.M...
> Even for writing a Desktop app, I don't understand why people use Qt instead of e.g. Java. Kotlin/Compose seem to be coming on Desktop too, which makes a lot of sense to me. And maybe even Flutter.
Again, I can't stretch how FUN, easy, and overall a great experience to develop with QML and C++ together, it's just HOW GUI should always been. I'm thinking of creating some Youtube tutorials that will try to present this feeling.
> Finally, I don't understand writing a cross-platform UI for Desktop and mobile. On mobile, I have a big finger and a small touch screen. On Desktop, I have a big screen, a mouse and a keyboard. Those require different UIs. Sharing the logic is fine, but the UI needs to be written for the platform.
100%. Completely in agreement. The fact that you can develop both Desktop and mobile apps in QML doesn't mean you must make them share the same code (at least, not fully). I think Kirigami have gone the wrong way with their 'adaptable' UI (I've also thought about doing that until I realized it's the wrong approach). One should always start with the UX that the end result should be - never start from tech considerations.
[1] https://develop.kde.org/frameworks/kirigami//
Both Kotlin and Swift are compiled.
> But this is just the standard I set to myself - the entire industry clearly has different priorities.
I think you just underestimate the performance of Java/Kotlin/Swift, languages that you admitted you don't have any experience with.
> tho with good debugging tools and LLMs I have found this to not be a problem anymore
Again: try modern languages with good debugging tools and LLMs :-). I think your bias is that this is all you know.
> because I've proven that it is fixable by caring about UI/UX
It requires care, which means more effort. All that for being at best similar to the native tools, but probably never exactly the same. And it cannot be better, because the native ones are the ones defining how it should be.
> I can't stretch how FUN, easy, and overall a great experience to develop with QML and C++ together, it's just HOW GUI should always been
But you said you don't have experience with the native Android/iOS way. I personally have used QML/C++, Flutter, Android (Java/Kotlin, the old XML way and the new Compose way) and SwiftUI. QML/C++ is by very far the worst.
I would advise that you try either Kotlin/Compose or Swift/SwiftUI to get an idea. You can still use C++ to share some code (say you write a complex library in C++, no need to rewrite it in Kotlin and Swift), but starting a new mobile UI with QML these days is just madness IMHO :-).
I only said that because you said performant code "does not matter for a mobile app". I think writing apps in native frameworks is awesome! I'm all for it. BTW, I've heard some reports that SwiftUI/Swift are slow[1][2][3]. Again, I haven't explored SwiftUI and Kotlin, but I'd like some day. What do you love about them so much?
> All that for being at best similar to the native tools, but probably never exactly the same. And it cannot be better, because the native ones are the ones defining how it should be.
I agree, the best apps would almost always be those written in the framework the OS provides - kinda make sense - cross platform GUIs will always fall under the lowest common denominator issue - I've written about it in my blog post[4]. You also forget tho, that Linux does exist with a growing popularity - I think it's important to target it as well (I've started GUI development because I was on Linux and most apps had horrible UI/UX).
> but starting a new mobile UI with QML these days is just madness IMHO :-)
Follow my mad adventure (:
[1] https://notes.alinpanaitiu.com/SwiftUI%20is%20convenient,%20...
[2] https://x.com/daniel_nguyenx/status/1734495508746702936
[3] https://danielchasehooper.com/posts/why-swift-is-slow/
[4] https://rubymamistvalove.com/block-editor#9-aesthetics
It shouldn't. It's never really been perfected across native GUI APIs after 40+ years: just various degrees of "good enough," plus fobbing it off to web stacks.
Anyhow, I've been playing with gioui, which is golang rendering in a lightweight <canvas>-like. Really nice: fast, small, cross platform GUI with just Go. Scale expectations appropriately.
https://openwebf.com/en/blog/announcing-webf
I see - compared with SwiftCrossUI and Skip, this is SwiftUI-like but only for Android. The other two allow you to write SwiftUI or SwiftUI-like, and run on both Apple platforms + Android (or elsewhere).
SwifDroid is about native Android development in Swift. You’re not writing cross-platform UI. You’re writing Android-specific UI in Swift, using Android’s own view system and APIs directly. The goal is to enable full, idiomatic Android apps entirely in Swift, including activities, fragments, AndroidX, and Material, without touching Java, Kotlin, or XML.
While the others focus on “write UI once, run anywhere,” often with trade-offs in UX, SwifDroid focuses on writing natively for Android and having full control from Swift.
Also, given <waves hands at everything>, I’d never consider becoming even more dependent on some big bad corp. And even if one is to put that aside somehow, Swift is a painful language … would be such a self own to have to use it even in places you’re not forced to.
Also picture this. Every time you run swift build, you get a mental image of Cook dining with Trump. It's very hard to stay focused and creative in that ecosystem rn.
Weird how Tim Cook gets so much hate, when the rest of them didn't. He didn't say anything notable except a bit of ring-kissing: "I want to thank you for setting the tone such that we can make a major investment ..."
Then Sergey Brin starts talking about how he's happy about Trump pressuring Maduro:
You're applying a lot of pressure to Maduro and I think that's phenomenal for an American president to actually be applying pressure there uh in Venezuela and then hopefully in Cuba and so forth. So there's a lot of um civil rights work that you're leading. we didn't get a chance to mention. Um I also just wanted to mention um we don't have to get into all the uh details talked about in the Oval Office, but uh I think it's a real incredible inflection point right now in AI and the fact that your administration uh is uh supporting our companies instead of fighting with them."
So, reading between the lines a little, i.e. Google looking depose dictators and burn lots of oil to keep their AI slop churning is totally fine:
https://www.youtube.com/watch?v=MvbKA-Te8QE
You’re welcome to replace Cook with your favourite billionaire. I’m not gonna list them all every time and you’re not obliged to defend Apple’s “honour” - they will deny your digital freedoms and make you pay a lot of money either way.
> Indeed, but it doesn't hurt to be a bit more selective and future thinking when choosing a stack or tools.
So if Microsoft, Apple, Google and Facebook are off the table, what's your stack looking like?
One of the most revered programmers in my circle, who's been coding since the early 1970's asked me once, "how many programming languages do you know?". I started rattling off a few, and he stopped me. He said "I only really know the last 2 languages I used".
Jack of all trades, master of none. If someone asked me to code in PHP, Perl or any of the dozens of languages I've used in the past today, just no way. No thank you. Yeah, I used to be very proficient with lots of languages, but no way am I going dust off those brain cells. Assembly is probably the only language I can really get into on different platforms without a huge cognitive context switch, because it's just straight forward, no kooky abstractions.
That said, I've used Javascript for front-end, back-end as well as database (mongo), and it was absolutely great to not have to context switch constantly. I've also done lots of different systems with a wide variety of other languages glued together, and it hasn't been as effortless as using one language for everything. YMMV.
I do agree a lot of people over estimate how much they know, but I work with multiple people who know at least 5 languages well.
For me myself, only counting things I’ve shipped at scale, I’d know C, C++, Swift, JavaScript, Python, Rust, MSL, HLSL, GLSL, MEL. There’s enough in common between them that I think it’s quite doable.
Every language has thousands of papercuts. It is hard to know many languages proficiently beyond surface syntax level, period.
> I’d know C, C++, Swift, JavaScript, Python, Rust, MSL, HLSL, GLSL, MEL
Shipped !== know. I've touched dozens of languages over my career and every time I've had my ass kicked by some esoteric knowledge of specific quirk in std of %lang%. We have a different definition of "know".
You initially said beyond a surface level and now you’re talking about esoteric quirks.
Pick one.
You don’t need to know every aspect of a languages corners to be proficient in it. If that were true, there’s only a handful of people on this planet who’d be proficient in a single language let alone multiple.
This was indeed my point from the start.
By your definition, then you likely don’t know any programming languages as well at a sufficient level either if there are bits of esoterica that “kick your ass”?
Is there a language you’d feel comfortable saying you know every single aspect of, without exception?
It is common practice to be thrown at random projects regardless of the programming project.
What is valued is the soft skills, and the ability to swim when thrown into the cold water, no matter how.
Yes it kind of sucks, however the Pandora box is long open and only an implosion of the capitalist enterprise culture would fix it.
Contrary to product companies you also get to jump technologies without having an HR department sending the application into the garbage because one doesn't tick all the boxes on a specific stack.
The only framework i found that really bridges the gap is B4X, but you still need to have two separate projects, because of services, and #if blocks for the things the framework doesn't abstract (which, to be frank, is really just advanced uses of peripherals and libraries)
The two OS' are just so fundamentally different.
I'm leaning towards Swift being the 'better' language, but even in this case, something like KMP has been around longer and is more stable.