11 ms·
Swift on Android: Full Native App Development Now Possible
- mihael 9mo agoI 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.
- canadiantim 9mo agoCongrats, I've definitely been looking to just centralize with Swift. Great work!
- liuliu 9mo agoOne 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?
- fingerlocks 9mo agoProbably using the compiler flags directly? I’ve never heard of a Bazel dependency in Swift, and precompiled c++ was a huge pain in SwiftPM a year ago. I work on ObjC++/Swift/Metal as my day job and just use a Makefile because it’s easier
- nicoburns 9mo agoInterestinggg. How does binding Java/Kotlin code into Swift work? (we're trying to do something very similar with Rust instead of Swift)
- mihael 9mo agoIt works primarily through the jni-kit library, which handles JNI bindings between Swift and Java/Kotlin. You can check out the full docs here: https://docs.swifdroid.com/jni-kit/ https://docs.swifdroid.com/jni-kit/ On top of that, the IDE also auto-generates required Java/Kotlin classes on the fly, for example, for Activities.
- satvikpendem 9mo agoFor Dioxus? 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.
- lukeh 9mo agoAnother approach is swift-java, which uses Swift macros and also supports Panama. https://github.com/swiftlang/swift-java https://github.com/swiftlang/swift-java
- pjmlp 9mo agoPanama will probably never make it to Android, given Google's behaviour on updating Java support.
- w10-1 9mo agoThe 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?
- wiseowise 9mo agoThat you don't have to touch Android Studio/Intellij is already a huge improvement. Awesome job.
- shelled 9mo agoAnd Gradle? Does skip the Gradle and that nightmare of a dependency management and handling?
- mihael 9mo agoYes, exactly. SwifDroid automatically wires all the necessary Gradle dependencies, so you don’t have to manage them manually.
- nicoburns 9mo agoDoes it still ultimately call into gradle to perform the build?
- mihael 9mo agoYes, since we need Gradle dependencies in order to build rich UI with AndroidX or Material Design. But if you're interested in a minimal approach without Gradle, check out the example by @purpln here: https://github.com/purpln/android-example https://github.com/purpln/android-example
- mavamaarten 9mo agoI'm totally biased towards Android development using Gradle and kotlin. 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.
- crowbahr 9mo ago
- tonyhart7 9mo agoit is time to ditch flutter/react native for these type of technology (kmp,swiftdroid) ????
- deleted 9mo ago[deleted]
- kllrnohj 9mo agoThey 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
- websiteapi 9mo agojeez so many ways to do things - 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?
- yk09123 9mo agoI find Kotlin Multiplatform to be far and away a better experience than flutter
- websiteapi 9mo agoKotlin Multiplatform does seem pretty appealing, but haven't looked into it very much
- flax 9mo agoCould you explain why? I have been interested, in theory, in Kotlin Multiplatform. But I'm already very comfortable in Dart and Flutter. I have decades of experience with Java, Javascript, and quite a few years with Typescript. Kotlin feels like a different kind of language, one I find grating. I think this is primarily aesthetic, but it's still enough to make getting over the initial hump annoying. As petty as it is, I think the lack of statement-terminating semicolons is a major reason I do not like it. I would welcome a factual list of things that make the KM experience better for you.
- BoorishBears 9mo agoFunny you say that since Dart is the primary reason most people I know don't want to use Flutter. 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.
- wahnfrieden 9mo agoSomehow 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).
- mihael 9mo agoIt’s a different approach with different goals. 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.
- dave_sid 9mo agoUsing 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.
- isodev 9mo agoKnowing 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.
- myko 9mo agoShocked to hear Swift described as "painful" (well, maybe the new concurrency stuff)
- isodev 9mo agoIt's always been unpleasant but you could find a balance to make it work. Since Swift 6 it's just headache as a service. If only we weren't forced to use it.. 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.
- saagarjha 9mo agoI have unfortunate news about the tech industry in general.
- 9mo ago
- agentifysh 9mo agoReally 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.
- satvikpendem 9mo 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. 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?
- aleph_naught 9mo agoYou can build on your own machine. I have github actions that trigger a local macos runner for local expo android/ios builds.
- vanillax 9mo agoWhat is the point of this. just use flutter or react native.
- Octoth0rpe 9mo agoSome people have a strong background in swift already and would like to use that experience for Android dev. That's a perfectly reasonable goal.
- daveidol 9mo agoIf 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.
- akmarinov 9mo agoImagine if people said “just use swift and kotlin” back before RN and Flutter - we wouldn’t have them
- z3t4 9mo agoWhy is mobile development so shitty compared to PC? Why cant you make an hello world in asm for a mobile device?
- saagarjha 9mo agoYou can. It would be about as bad as writing hello world in assembly for PC, which is why nobody does it.
- surajrmal 9mo agoIt'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.
- dagmx 9mo agoYou’re conflating ABI with primary language for frontend development. Android, iOS and “PC” all use the C ABI at their C stack level. They just have different languages available for their primary SDK. Windows doesn’t use a C api primarily for example, so your PC example is wrong. Mac shares the same frameworks as iOS so is no more Swift/objc than iOS. It’s just that you can’t really ship electron (JIT) or easily use Qt (licensing) on iOS. But you can just as happily develop entire apps in the same C as you could on a “PC”. Case in point, blender builds for iOS. Android is definitely the most out-there of the platforms because the jump from JNI to Java SDk is quite large but that is completely orthogonal to what you’re incorrectly claiming. Your comment is conflating completely opposite ends of the stack, but if we go by your definition, Android is Linux just as much as Linux distros on desktop.
- pjmlp 9mo agoABI is the language used to write the OS, thus OP is kind of right. While Windows has moved away from pure C, and nowadays has ABIs across C, C++, .NET, COM, WinRT interfaces, you can still program Windows applications in straight C. The caveat is to only use APIs up to Windows XP, and Petzold's book to follow along.
- vivzkestrel 9mo agoBeen out of android stuff for a while, can someone kindly elaborate here - 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 9mo agoReact 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]. [0] https://old.reddit.com/r/androiddev/comments/1np26m4/do_other_android_devs_feel_this_way_about_flutter/ https://old.reddit.com/r/androiddev/comments/1np26m4/do_othe...
- palata 9mo agoI liked Flutter 1.0, but then it broke my codebase with 2.0, and again with 3.0, which made me swear never to use it again. The good ideas of Flutter, IMHO, got implemented in native Android (Kotlin + Compose).
- satvikpendem 9mo agoI don't mind not having backward compatibility especially when it's for a growing framework that's not feature complete. Those versions are semantically versioned so you didn't need to upgrade if you didn't feel like it. Jetpack Compose and Compose Multiplatform is nowhere near what Flutter does, it's essentially still Android only as their other OS support isn't really stable, even if they say it is. I tried to make an app and gave up and went back to Flutter.
- 9mo ago
- aprilnya 9mo agoI 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? [1] https://skip.tools/ https://skip.tools/
- mvkel 9mo agoJust in time, right when Apple is quietly abandoning it
- mobiledev2014 9mo agoThat’s one I haven’t heard yet, do elaborate
- akmarinov 9mo agoHe might be referring to Apple abandoning SwiftUI as there’s a rumor going around about it.
- dickersnoodle 9mo agoRumors are worth exactly what you pay for them.
- steve1977 9mo agoAny sources for this? Reason I'm asking is I have some old knowledge in Objective-C, earlier Swift and AppKit/UIKit and I'm considering brushing up my Swift and also learn SwiftUI.
- mihael 9mo agohttps://www.youtube.com/watch?v=pL8Ex0Co8fA https://www.youtube.com/watch?v=pL8Ex0Co8fA
- mobiledev2014 9mo agoAhh well that’s very different and equally unlikely to be true! Current and previous household name employers are all-in on SwiftUI and it is unquestionably a valuable thing to learn. Something new always comes along but I’d bet a lot of money we’re not going back to UIKit
- solidsnack9000 9mo agoApple is abandoning Swift on Android?
- thedumbname 9mo agoHow to make a HTTP call and parse JSON response idiomatically?
- pjmlp 9mo agoKind of, because this always has to go via JNI in the end, given that 80% of the API surface is only exposed via Java. 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.
- larusso 9mo agoThe 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.
- pjmlp 9mo agoWith a caveat, Metal is written in a mix of Objective-C and C++, with Swift bindings. Thus you can do anything Metal with Objective-C and zero Swift. Also, writing drivers, even in userspace is still mostly C++. Going on a tangent, even if Swift isn't everywhere still, I would like that Microsoft would be half as serious as Apple, regarding .NET use on Windows, however they aren't even serious with C++.
- iamcalledrob 9mo agoThe 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.
- maximgeorge 9mo ago[dead]
- CSOAI_Official 9mo ago[flagged]
- outreachCSOAI 9mo ago[flagged]
- JusticeJuice 9mo agoDead link
- testdelacc1 9mo agoShameless self promotion. Account created 5 minutes ago, 0 karma.
- fuomag9 9mo agoThe cookie consent definitely feels not legal in europe
- mihael 9mo agoThanks