I just released Swift Stream IDE v1.17.0, which now supports full native Android app development entirely in Swift. You can build apps without touching XML, Java, or Kotlin.
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.
The threshold question is crossover: what Android development experience is required for Swift developers, and what Swift experience is required for Android/Kotlin developers? By saying "without touching XML, Java, or Kotlin", are you implying that Swift developers without Android experience could be successful?
Then the questions is: roughly what percentage of Kotlin or Flutter apps could be writable in Swift? Today and next year?
One thing useful for Swift is it's native interop with C / C++ libraries. These are often presented as SwiftPM or Bazel dependencies. How do you handle SwiftPM dependencies?
Using a common language between platforms, whether it’s Swift or Kotlin always sounds great on the surface but I don’t think adds the expected efficiencies when it comes to the crunch. I expect teams would always still end up with two codebases, with enough differences and workarounds to make it that you might as well just enjoy using Kotlin or Swift as you need to. Knowing two languages isn’t all that bad. Most developers learn many languages during their careers and switch between them without a thought. Just my opinion tho, I’m sure this is a good project.
But it does allow engineers, trained on one platform, to work on the other.
Long ago, I took a few months, and learned Android programming (using Java, which was the native choice, back then). I ended up not really enjoying it, and eventually abandoned it, but my goal was to write fully-native Android.
I’m a big believer in fully-native development. I’ve worked with cross-platform frameworks for decades, and have never enjoyed any significant success.
For that reason, I’m a bit skeptical of the chances for this framework, but admire the work and dedication that went into it. I sincerely wish them luck.
> Most developers learn many languages during their careers and switch between them without a thought.
I’ve worked with quite a few, over my 40+ years of experience, but I don’t really “switch without a thought.” There’s always a “context switch” overhead.
For example, I am currently writing a Swift app (SwiftUI), with a PHP backend. I keep switching between the two. The biggest mistake I make in PHP, is neglecting trailing semicolons. The next-biggest mistake, is not surrounding if statement evaluations in parentheses. I've been working with PHP a lot longer than Swift, but not anywhere nearly as deeply. Swift is definitely my "native" language.
My experience is that I can learn a working understanding of a language in a couple of weeks, but it takes years to really get proficient. Think someone that speaks with a heavy accent, and someone fluent.
Also, the language is often the least relevant aspect. SDKs, stdlibs, and frameworks are where most of the work lives. They can take a long time to master, and are usually “moving targets,” undergoing constant evolution (like the language, itself).
Yes, these cross platform frameworks speed up developing easy and boring things but actively gets in the way the moment you venture out for more esoteric platform-specific features. Overall time savings is questionable, especially in the AI age where you get a lot more speedup for the easy and boring things with better documentation and more training corpus. Not recommended (from someone who made the switch back to separate native codebases), unless your app can basically be a web app anyway.
>Knowing two languages isn’t all that bad. Most developers learn many languages during their careers and switch between them without a thought.
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.
Knowing two or more languages is kind of liberating even. People love shiny but there are no shortcuts in this case.
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.
Which is what we're doing. The moment your app isn't some webview react crap and start using any non basic (or even basic) features you end up with two codebases. For example, anything using foreground services or requiring runtime permissions.
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 reverse -- building for iOS in Kotlin -- is an interesting option that on the surface appears to be a best of both worlds.
You get (1) access to JVM APIs as normal on Android, and (2) Fairly full-featured interop with ObjC, Swift and C APIs elsewhere, and (3) A pleasant language with excellent IDE support in IntelliJ.
The `expect fun` / `actual fun` stubbing for different platforms also works in a fairly low-drama way. You can also share UI with Compose Multiplatform (less mature), or just write native views.
The downside (of course) is that non-JVM targets like iOS can't use the JVM ecosystem, and most of the Kotlin ecosystem assumes Kotlin/JVM. This is slowly changing though, and isn't a structural flaw.
Also, you're going to end up with Gradle in your toolchain, which will torture your poor soul.
The fun part is that now you need to bind against swift and objective-c for success on Apple systems. They no longer provide obj-c frameworks for all the new things. So you have to double hop and deal with both or deal with it on a framework by framework level. Talking from a Unity background here where the interop with obj-c is kinda smooth due to the c# -> c marshaling. But swift needs a bit more work.
I wonder how this compares to Skip[1]? This seems to be focused entirely on Android, as opposed not making existing iOS SwiftUI code work on Android. I assume that might lead to better apps but any practical examples?
Somehow I never heard of this. How does this compare with SwiftCrossUI? Skip is also very compelling (as it runs actual SwiftUI natively as Swift and translates it to Compose).
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.
It's all about where the stable ABI exists. You can do anything in practice, but if you stray off the happy path it will result in pain. On PC OS, everything used C (or in Linux, syscall) ABI. On android the ABI is java based, and on iOS it's objc/swift based. These are deliberate choices and while they make some use cases more difficult, they are optimized for the use cases the companies care about. I'm personally preferential to a language agnostic IPC boundary being the abi, but that has its own cons as well.
A ton of native apps are written on mobile. On desktop, there is a trend of shipping a full browser together with a goddamn webapp instead of making a proper desktop app. I wouldn't say that desktop is more successful there...
React Native is not webview based, it's basically a translation layer that takes your JSX markup and turns it into SwiftUI / Kotlin UI code, native on each device.
Personally I like Flutter, a lot of people, even hardcore Android native devs, say Flutter could be the way to go for Android development in general [0].
> then i heard they added something called flutter that works on both android and ios
Flutter is just another cross-platform framework that happens to support Android. I think it brought good ideas that since got implemented in native Android. I am still against cross-platform frameworks anyway.
Kotlin-the-language has evolved into compiling for different targets instead of just the JVM. So with Kotlin MultiPlatform (KMP), you can compile your Kotlin code as a native executable (instead of a JVM one) or as an iOS framework. So that you can share a Kotlin library between e.g. Desktop, Android and iOS. The difference with Flutter is that KMP is not a cross-platform framework; just a way to "cross-compile" a library, if I can say. Just like you may share a C++/Rust library between iOS and Android, you can share a KMP library.
And Swift is also trying to get there, though it is less mature than Kotlin in that respect.
The advantage is that you can cherry-pick the library you want to depend on. Maybe your Swift team wrote advanced logic in Swift and it makes sense for you to call it from Kotlin instead of rewriting it, just like you may depend on a C, C++ or Rust library. And it is different from a framework like Flutter: if you go with Flutter, you write the whole app in Flutter.
They target different things. kmp/swiftdroid let you share business logic, but not really the UI. Although this is SwiftUI-like, it's not actually swiftui and doesn't behave as such. So you'd be doing platform-specific front ends, which isn't necessarily a bad thing but it's different from the promise of Flutter/React Native which is the same UI everywhere
Really bizarre to see all the dogpiling on Flutter/Dart, it's fine. Google isn't giving up on it and we aren't going to suddenly switch to something else. In fact I have no desire to use React Native which the community seems to always point to Expo, a paid tool with metered usage.
My only gripe is that there is no 3D game engine for Flutter, again Dart is great, lots of solid packages like GetX just make the overall development progress as advertised.
People also sleep on the fact that Flutter can do web application and target all 3 desktops and this shit is all free without needing a 3rd party tool like Expo because the RN core experience is lacking and you need to depend on another vendor.
> My only gripe is that there is no 3D game engine for Flutter, again Dart is great, lots of solid packages like GetX just make the overall development progress as advertised.
Yeah they're going to work on 3D afterwards (potentially, the main dev for 3D left the Flutter team and is back on Android if I recall correctly), it's not a huge priority right now. Also, it's not recommended to use GetX, there are some issues with it, a major one being it's like a framework within a framework, and it essentially rewrites a lot of Flutter. Better to use Riverpod, Bloc, Signals, ReArch or something else.
For 3D however, I've been looking at Dioxus which is in Rust, they're making a native renderer the same as Flutter (ie not webviews) called Blitz, and they're making good progress on the mobile side. This renderer can embed Bevy, a game engine also written in Rust, and Bevy can also embed Dioxus native, which I thought was really cool, it's bidirectional embedding.
I didn't know Expo explicitly made you pay, I thought it was only optional. Now that I look at it, seems like it's for high priority builds but still, can't we just build on our own servers? If not then that's a big con, I don't want to rely on an external service just to build my app.
Calling Expo a paid tool with metered usage is just flat out misinformation. You can promote your preferred tech without lying about alternatives.
Expo is a free open source framework that costs absolutely no money to use. You do not need to pay expo any money ever.
Expo Application Services is a set of cloud services that you do not have to use to use Expo. You can set up your own on-prem build infrastructure with fastlane and never use EAS Build. You can self-host your own EAS Updates server. You don't have to use EAS Hosting for web apps. Expo is far less coupled to EAS than Next.js is to Vercel.
Flutter for the web is terrible compared to React Native Web. It's a great way to get your company sued for violating the Americans with Disabilities Act. It literally renders to a canvas almost like the Macromedia Flash apps of old. There's also React Strict Dom now which absolutely blows flutter's web support out of the water while still supporting react native: https://facebook.github.io/react-strict-dom/
I just looked up an example flutter web app and it's completely invisible to the screen reader when I enable VoiceOver: https://flokk.app/#/ . The screen reader literally announces 'web content is empty'. You can't even select text to copy it!
If you want complex 2D graphics like you can do with flutter, react native can also use the Skia rendering engine just like flutter with react-native-skia.
If you already have a Swift app it could be worth considering. Or if you are targeting like 90% iOS users and just need Android support to check a box.
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.
does swift have a good web story or is wasm the main way? desktop?
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.
Swift on WASM also got very good last year. SQLite in WASM too.
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.
mihael|1 month ago
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.
w10-1|1 month ago
Then the questions is: roughly what percentage of Kotlin or Flutter apps could be writable in Swift? Today and next year?
liuliu|1 month ago
nicoburns|1 month ago
(we're trying to do something very similar with Rust instead of Swift)
canadiantim|1 month ago
dave_sid|1 month ago
ChrisMarshallNY|1 month ago
Long ago, I took a few months, and learned Android programming (using Java, which was the native choice, back then). I ended up not really enjoying it, and eventually abandoned it, but my goal was to write fully-native Android.
I’m a big believer in fully-native development. I’ve worked with cross-platform frameworks for decades, and have never enjoyed any significant success.
For that reason, I’m a bit skeptical of the chances for this framework, but admire the work and dedication that went into it. I sincerely wish them luck.
> Most developers learn many languages during their careers and switch between them without a thought.
I’ve worked with quite a few, over my 40+ years of experience, but I don’t really “switch without a thought.” There’s always a “context switch” overhead.
For example, I am currently writing a Swift app (SwiftUI), with a PHP backend. I keep switching between the two. The biggest mistake I make in PHP, is neglecting trailing semicolons. The next-biggest mistake, is not surrounding if statement evaluations in parentheses. I've been working with PHP a lot longer than Swift, but not anywhere nearly as deeply. Swift is definitely my "native" language.
My experience is that I can learn a working understanding of a language in a couple of weeks, but it takes years to really get proficient. Think someone that speaks with a heavy accent, and someone fluent.
Also, the language is often the least relevant aspect. SDKs, stdlibs, and frameworks are where most of the work lives. They can take a long time to master, and are usually “moving targets,” undergoing constant evolution (like the language, itself).
muzani|1 month ago
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.
oefrha|1 month ago
leptons|1 month ago
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.
isodev|1 month ago
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.
monegator|1 month ago
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.
unknown|1 month ago
[deleted]
pjmlp|1 month ago
These efforts are always to celebrate, however they always end up with leaky abstractions.
Just like on the other way around one needs to be aware of Objective-C for success, or .NET/COM on Windows.
iamcalledrob|1 month ago
You get (1) access to JVM APIs as normal on Android, and (2) Fairly full-featured interop with ObjC, Swift and C APIs elsewhere, and (3) A pleasant language with excellent IDE support in IntelliJ.
The `expect fun` / `actual fun` stubbing for different platforms also works in a fairly low-drama way. You can also share UI with Compose Multiplatform (less mature), or just write native views.
The downside (of course) is that non-JVM targets like iOS can't use the JVM ecosystem, and most of the Kotlin ecosystem assumes Kotlin/JVM. This is slowly changing though, and isn't a structural flaw.
Also, you're going to end up with Gradle in your toolchain, which will torture your poor soul.
larusso|1 month ago
aprilnya|1 month ago
[1] https://skip.tools/
wahnfrieden|1 month ago
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).
mihael|1 month ago
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.
wiseowise|1 month ago
crowbahr|1 month ago
shelled|1 month ago
z3t4|1 month ago
surajrmal|1 month ago
saagarjha|1 month ago
palata|1 month ago
deergomoo|1 month ago
vivzkestrel|1 month ago
- best way of making apps last i checked was swift for ios and java for android
- i read somewhere java got replaced with something called kotlin
- then i heard they added something called flutter that works on both android and ios
- react native / "web browser based" was already a form of dev i think which was considered the most non performant solution out there
Is this swift on android another layer like the above ones? the most performant layer is always native right?
satvikpendem|1 month ago
Personally I like Flutter, a lot of people, even hardcore Android native devs, say Flutter could be the way to go for Android development in general [0].
[0] https://old.reddit.com/r/androiddev/comments/1np26m4/do_othe...
palata|1 month ago
Flutter is just another cross-platform framework that happens to support Android. I think it brought good ideas that since got implemented in native Android. I am still against cross-platform frameworks anyway.
Kotlin-the-language has evolved into compiling for different targets instead of just the JVM. So with Kotlin MultiPlatform (KMP), you can compile your Kotlin code as a native executable (instead of a JVM one) or as an iOS framework. So that you can share a Kotlin library between e.g. Desktop, Android and iOS. The difference with Flutter is that KMP is not a cross-platform framework; just a way to "cross-compile" a library, if I can say. Just like you may share a C++/Rust library between iOS and Android, you can share a KMP library.
And Swift is also trying to get there, though it is less mature than Kotlin in that respect.
The advantage is that you can cherry-pick the library you want to depend on. Maybe your Swift team wrote advanced logic in Swift and it makes sense for you to call it from Kotlin instead of rewriting it, just like you may depend on a C, C++ or Rust library. And it is different from a framework like Flutter: if you go with Flutter, you write the whole app in Flutter.
fuomag9|1 month ago
mihael|1 month ago
tonyhart7|1 month ago
kllrnohj|1 month ago
unknown|1 month ago
[deleted]
thedumbname|1 month ago
maximgeorge|1 month ago
[deleted]
outreachCSOAI|1 month ago
[deleted]
testdelacc1|1 month ago
JusticeJuice|1 month ago
CSOAI_Official|1 month ago
[deleted]
agentifysh|1 month ago
My only gripe is that there is no 3D game engine for Flutter, again Dart is great, lots of solid packages like GetX just make the overall development progress as advertised.
People also sleep on the fact that Flutter can do web application and target all 3 desktops and this shit is all free without needing a 3rd party tool like Expo because the RN core experience is lacking and you need to depend on another vendor.
satvikpendem|1 month ago
Yeah they're going to work on 3D afterwards (potentially, the main dev for 3D left the Flutter team and is back on Android if I recall correctly), it's not a huge priority right now. Also, it's not recommended to use GetX, there are some issues with it, a major one being it's like a framework within a framework, and it essentially rewrites a lot of Flutter. Better to use Riverpod, Bloc, Signals, ReArch or something else.
For 3D however, I've been looking at Dioxus which is in Rust, they're making a native renderer the same as Flutter (ie not webviews) called Blitz, and they're making good progress on the mobile side. This renderer can embed Bevy, a game engine also written in Rust, and Bevy can also embed Dioxus native, which I thought was really cool, it's bidirectional embedding.
I didn't know Expo explicitly made you pay, I thought it was only optional. Now that I look at it, seems like it's for high priority builds but still, can't we just build on our own servers? If not then that's a big con, I don't want to rely on an external service just to build my app.
What are you making in Flutter?
never_inline|1 month ago
I haven't touched flutter in two years, but isn't getX a kitchen sink library disliked by everyone?
RantyDave|1 month ago
tcoff91|1 month ago
Expo is a free open source framework that costs absolutely no money to use. You do not need to pay expo any money ever.
Expo Application Services is a set of cloud services that you do not have to use to use Expo. You can set up your own on-prem build infrastructure with fastlane and never use EAS Build. You can self-host your own EAS Updates server. You don't have to use EAS Hosting for web apps. Expo is far less coupled to EAS than Next.js is to Vercel.
Flutter for the web is terrible compared to React Native Web. It's a great way to get your company sued for violating the Americans with Disabilities Act. It literally renders to a canvas almost like the Macromedia Flash apps of old. There's also React Strict Dom now which absolutely blows flutter's web support out of the water while still supporting react native: https://facebook.github.io/react-strict-dom/
I just looked up an example flutter web app and it's completely invisible to the screen reader when I enable VoiceOver: https://flokk.app/#/ . The screen reader literally announces 'web content is empty'. You can't even select text to copy it!
Also, as far as integrations with game engines:
https://github.com/calico-games/react-native-godot
If you want complex 2D graphics like you can do with flutter, react native can also use the Skia rendering engine just like flutter with react-native-skia.
mvkel|1 month ago
solidsnack9000|1 month ago
pjmlp|1 month ago
mobiledev2014|1 month ago
vanillax|1 month ago
daveidol|1 month ago
Octoth0rpe|1 month ago
akmarinov|1 month ago
websiteapi|1 month ago
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.
does swift have a good web story or is wasm the main way? desktop?
topspin|1 month ago
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.
wahnfrieden|1 month ago
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.
LorenDB|1 month ago
yk09123|1 month ago
cyberax|1 month ago
kenferry|1 month ago
andycall|1 month ago
https://openwebf.com/en/blog/announcing-webf
SchwKatze|1 month ago