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.<p>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.<p>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?<p>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?
Interestinggg. How does binding Java/Kotlin code into Swift work?<p>(we're trying to do something very similar with Rust instead of Swift)
It works primarily through the jni-kit library, which handles JNI bindings between Swift and Java/Kotlin. You can check out the full docs here:
<a href="https://docs.swifdroid.com/jni-kit/" rel="nofollow">https://docs.swifdroid.com/jni-kit/</a><p>On top of that, the IDE also auto-generates required Java/Kotlin classes on the fly, for example, for Activities.
For Dioxus?<p>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.
Another approach is swift-java, which uses Swift macros and also supports Panama.<p><a href="https://github.com/swiftlang/swift-java" rel="nofollow">https://github.com/swiftlang/swift-java</a>
Congrats, I've definitely been looking to just centralize with Swift. Great work!
Kind of, because this always has to go via JNI in the end, given that 80% of the API surface is only exposed via Java.<p>These efforts are always to celebrate, however they always end up with leaky abstractions.<p>Just like on the other way around one needs to be aware of Objective-C for success, or .NET/COM on Windows.
The reverse -- building for iOS in Kotlin -- is an interesting option that on the surface appears to be a best of both worlds.<p>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.<p>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.<p>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.<p>Also, you're going to end up with Gradle in your toolchain, which will torture your poor soul.
Yeah, the JVM ecosystem is what makes Kotlin interesting, and the main reason why Google begrudgingly updates Java support, when Android starts to lag behind the current Maven Central trend, currently Java 17.<p>I agree regarding Gradle, thankfully the time I used to do Android native development is behind me, even if I keep up with Google IO sessions, and ADP Podcast.<p>How is Kotlin Native maturity nowadays?
I've found Kotlin/Native to be fine, but very basic. It's limited due to lack of ecosystem and minimal stdlib, though this is improving.<p>There are things you might expect to be able to do trivially (e.g. formatting a timestamp into a date string) had no off-the-shelf approach last time I tried. You'd need to roll your own, or pull in an existing non-kotlin library, e.g. something from C.<p>I think a lot of issues stem from existing APIs being designed around Java types that will never be available without the JVM.
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.
With a caveat, Metal is written in a mix of Objective-C and C++, with Swift bindings.<p>Thus you can do anything Metal with Objective-C and zero Swift.<p>Also, writing drivers, even in userspace is still mostly C++.<p>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++.
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.<p>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.<p>I’m a big believer in fully-native development. I’ve worked with cross-platform frameworks for decades, and have <i>never</i> enjoyed any significant success.<p>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.<p><i>> Most developers learn many languages during their careers and switch between them without a thought.</i><p>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.<p>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.<p>My experience is that I can learn a working understanding of a language in a couple of weeks, but it takes <i>years</i> to really get proficient. Think someone that speaks with a heavy accent, and someone fluent.<p>Also, the language is often the least relevant aspect. SDKs, stdlibs, and frameworks are where most of the work lives. They can take a <i>long</i> time to master, and are usually “moving targets,” undergoing constant evolution (like the language, itself).
>But it does allow engineers, trained on one platform, to work on the other.<p>The programming language is the most surface level detail when learning a platform.<p>The libraries, the frameworks, the OS services, the app lifecycle, the UI idioms are the hard part, and those cannot be abstracted away (of course you can try, but you'll end up with an inconsistent mess that doesn't feel native in any of the supported platforms, at which point you should just create a website).
> using Java, which was the native choice, back then<p>It still might be, as Kotlin isn't used on the lower layers below JetPack libraries, despite Google's resistance to modern Java adoption.
Kotlin and Swift are both very similar, and where they are not, we don't really want the abstraction. I agree, it's cool, but I doubt we'd use it.<p>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.
Knowing two or more languages is kind of liberating even. People love shiny but there are no shortcuts in this case.<p>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.
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.
Yes building a native app has fewer layers of abstraction and often has better DX than building with a cross-platform framework where you have to work around bugs that inevitably exist in the framework.<p>Cross-platform frameworks I find are more about making sure that your apps stay consistent across platforms over time as they are maintained. Features land on all platforms at the same time.<p>I worked on a product that had been around a long time and had a separate macOS, windows, iOS, android, and web apps. It was a big a big shit-show when product leadership wanted to make large scale changes across all platforms in unison. For that product though it really did have to be native to each platform and I don't think any cross platform framework could have worked for that particular product.<p>Having worked with both native apps & cross-platform frameworks, I do think there is value in cross-platform frameworks as long as the framework allows you to drop down to native platform specific code easily where needed.<p>When it comes to mobile, I think that React Native has some serious benefits:<p>- Fast refresh: incredible DX improvement to be able to just save a file and instantly see the behavior of your app update without rebuilding and reinstalling.
- Server-driven UI via React Server Components (still experimental): Companies like AirBnB spend a ton of engineering effort to build their own bespoke server-driven UI frameworks. Expo Router is bringing React Server Components to native apps.
- Automatic deep linking: If you also ship your app for the web using Expo Web & Expo Router, then all your links work perfectly as deep links into your app because your web app and your native app have the exact same routing. If you use next.js with solito for your web app instead of Expo Router, you can also keep your web app in lock-step with your native app without having to use Expo Router for your web app.
- Over the Air Updates: You can ship changes to your apps instantly without app store review.
- Can drop down to native easily: These days you can easily build an expo module or if you need really high performance build a nitro module and leverage the native platform APIs where you really need it. I mean look at react-native-vision-camera, it's so much easier to use than the native camera APIs.
- LLMs are way better at react than they are at swift & kotlin development.<p>If I wanted to build the next TikTok though I'd 100% go full native.
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.<p>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)<p>The two OS' are just so fundamentally different.
>Knowing two languages isn’t all that bad. Most developers learn many languages during their careers and switch between them without a thought.<p>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".<p>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.<p>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 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?<p>[1] <a href="https://skip.tools/" rel="nofollow">https://skip.tools/</a>
That you don't have to touch Android Studio/Intellij is already a huge improvement. Awesome job.
Touching xcode to avoid touching Android is like touching concentrated hydrochloric acid to avoid breathing a fart
I think IDE preference leans further towards subjective than many believe.<p>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.<p>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).
The linked article states that you'd use VSCode, so no touching Xcode.
Have you even opened the link? It uses VS Code.
Xcode, for all its faults, is largely pleasant to use. This is not true of Android Studio, which looks and works as a Java IDE (derogatory).
I've used Jetbrains IDE's for most of my career, and after that trying Xcode felt like going back to Medieval times.
You can't be serious, Xcode is the worse IDE I ever used, while Android Studio isn't great, it cannot be compared to that.<p>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.<p>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.
And Gradle? Does skip the Gradle and that nightmare of a dependency management and handling?
I'm totally biased towards Android development using Gradle and kotlin.<p>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.<p>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.
Yes, exactly. SwifDroid automatically wires all the necessary Gradle dependencies, so you don’t have to manage them manually.
Why is mobile development so shitty compared to PC? Why cant you make an hello world in asm for a mobile device?
You can. It would be about as bad as writing hello world in assembly for PC, which is why nobody does it.
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...
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.
You’re conflating ABI with primary language for frontend development.<p>Android, iOS and “PC” all use the C ABI at their C stack level. They just have different languages available for their primary SDK.<p>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.<p>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.
ABI is the language used to write the OS, thus OP is kind of right.<p>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.<p>The caveat is to only use APIs up to Windows XP, and Petzold's book to follow along.
Small correction.<p>On PC, MS-DOS did not use C, rather interrupts and there was no common C ABI.<p>On OS/2, a mix of C ABI and SOM, with C, C++ and Smalltalk as main languages.<p>Windows started only with the C ABI, nowadays it is a mix of C, C++, .NET, COM, WinRT, depending on the subsystem.
<a href="https://gist.github.com/nicolas17/966a03ce49f949dd17b0123415ef2e31" rel="nofollow">https://gist.github.com/nicolas17/966a03ce49f949dd17b0123415...</a>
Been out of android stuff for a while, can someone kindly elaborate here<p>- best way of making apps last i checked was swift for ios and java for android<p>- i read somewhere java got replaced with something called kotlin<p>- then i heard they added something called flutter that works on both android and ios<p>- react native / "web browser based" was already a form of dev i think which was considered the most non performant solution out there<p>Is this swift on android another layer like the above ones? the most performant layer is always native right?
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.<p>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].<p>[0] <a href="https://old.reddit.com/r/androiddev/comments/1np26m4/do_other_android_devs_feel_this_way_about_flutter/" rel="nofollow">https://old.reddit.com/r/androiddev/comments/1np26m4/do_othe...</a>
I 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.<p>The good ideas of Flutter, IMHO, got implemented in native Android (Kotlin + Compose).
I 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.<p>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.
> Those versions are semantically versioned so you didn't need to upgrade if you didn't feel like it.<p>This is only valid if you write a trivial app. If your dependencies migrate to the new major version, eventually you have to do it as well.<p>Cross-platform frameworks are generally not terrible for trivial apps; the pain comes when the app get complicated. But then if it's a trivial app, I can write it natively in the different languages I need to support, so there is not much need for a cross-platform framework.<p>Of course if your alternative is Qt, then Flutter is better :-).
> then i heard they added something called flutter that works on both android and ios<p>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.<p>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.<p>And Swift is also trying to get there, though it is less mature than Kotlin in that respect.<p>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.
The cookie consent definitely feels not legal in europe
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).<p>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).
It’s a different approach with different goals.<p>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.<p>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.
How to make a HTTP call and parse JSON response idiomatically?
it is time to ditch flutter/react native for these type of technology (kmp,swiftdroid) ????
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
[dead]
[flagged]
[flagged]
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.<p>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.<p>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.
> <i>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.</i><p>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.<p>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, <i>and Bevy can also embed Dioxus native,</i> which I thought was really cool, it's bidirectional embedding.<p>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.<p>What are you making in Flutter?
You can build on your own machine. I have github actions that trigger a local macos runner for local expo android/ios builds.
Expo is free, that was misinformation. EAS costs money but is optional.
> lots of solid packages like GetX<p>I haven't touched flutter in two years, but isn't getX a kitchen sink library disliked by everyone?
Likewise. It took me a while to "get" flutter but now I'm here, I 'aint leaving.
Calling Expo a paid tool with metered usage is just flat out misinformation. You can promote your preferred tech without lying about alternatives.<p>Expo is a free open source framework that costs absolutely no money to use. You do not need to pay expo any money ever.<p>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.<p>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: <a href="https://facebook.github.io/react-strict-dom/" rel="nofollow">https://facebook.github.io/react-strict-dom/</a><p>I just looked up an example flutter web app and it's completely invisible to the screen reader when I enable VoiceOver: <a href="https://flokk.app/#/" rel="nofollow">https://flokk.app/#/</a> . The screen reader literally announces 'web content is empty'. You can't even select text to copy it!<p>Also, as far as integrations with game engines:<p><a href="https://github.com/calico-games/react-native-godot" rel="nofollow">https://github.com/calico-games/react-native-godot</a><p>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.
Flutter for the web is lacking but for iOS/Android/Windows it's ideal.
saying Expo is "free" is disingenuous. sure, you can self-hosts and duct-tapep pipelines together on-prem, but at that point you're just paying in devops hours (<a href="https://github.com/expo/expo/issues?q=is%3Aissue%20state%3Aopen%20build" rel="nofollow">https://github.com/expo/expo/issues?q=is%3Aissue%20state%3Ao...</a>) instead, something which is not part of flutter DX<p>your comparison for web is a lazy trope. If a Flutter app is invisible to VoiceOver, thats on the developer for ignoring the semantics tree, not the framework<p>ironically, your point on React Strict DOM actually shows how much of a mess RN web approach is. Flutter solved cross-platform consistency at the engine level years ago while React is still trying to force the DOM to behave.<p>I much prefer a compiled language than the runtime uncertainty of RN. composing native views sounds ideal until an iOS update changes and breaks your layout, or JS bridge chokes during a complex animation edge case that will get you digging through github issues. Flutter is rendering natively on the GPU without the overhead. I prefer shipping a consistent app over debugging why some react-native-* is dropping frames on a budget phone because of JS thread<p>Overall, I find your blatant marketing advertisement of Expo, very suspicious, digging through your past comments I see similar promotion of Expo and RN. You can see Expo's pricing (<a href="https://expo.dev/pricing#plan-features" rel="nofollow">https://expo.dev/pricing#plan-features</a>) which clearly shows its a classic open-core funnel scheme to get developers to build dependence and end up paying for build credits
Just in time, right when Apple is quietly abandoning it
I think you are confused with Objective-C.
Apple is abandoning Swift on Android?
That’s one I haven’t heard yet, do elaborate
What is the point of this. just use flutter or react native.
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.
Some people have a strong background in swift already and would like to use that experience for Android dev. That's a perfectly reasonable goal.
Imagine if people said “just use swift and kotlin” back before RN and Flutter - we wouldn’t have them
jeez so many ways to do things -<p>react native
flutter
ionic<p>and now swift.<p>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).<p>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.<p>does swift have a good web story or is wasm the main way? desktop?
> it surprises me that this hasn't been perfected<p>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.<p>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.
Qt/QML can do all those targets as well (although it is admittedly jankier on mobile than Flutter or Swift would be).
I never understood that. Qt is C++. The only valid reason to use C++ is "not having a choice" (which happens to me, too). But if you write a mobile app, I find it extremely weird to choose C++ instead of a modern language.<p>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 find Kotlin Multiplatform to be far and away a better experience than flutter
Could 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.
Kotlin doesn’t feel right to me either. I did a portion of AoC in it this year and it was surprisingly more verbose than I expected. I think the thing I liked the least was trailing lambda syntax combined with how verbose it was to define variables with types.<p>It also inherits all of the bad parts of the JVM. Crappy build tooling (gradle), and then the slow startup and high memory usage.
I used Kotlin as well and it just feels off too. The package support is a major thing, as I don't want to mess around in Gradle, I want something that Just Works™. Dart 3 has much of the same feature set as Kotlin now with sealed class support, it's just not as functional, but it recently got tearoffs so you don't have to specify the class, just the property, similar to Swift (ie if you have an `enum Color { red, blue }` and a function takes `Color`, you can just do `f(.red)` not `f(Color.red)`).<p>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`.
Funny you say that since Dart is the primary reason most people I know don't want to use Flutter.<p>There's been a trend of improved DX for languages used in app development:<p>ObjC -> Swift<p>Java -> Kotlin<p>Javascript -> Typescript<p>...Dart feels like the before with no after, even though it got traction in the era of the Afters.
Darts pretty good. It has a lot of modern features, nullable types, pattern matching, sum types, and factory constructors; some really good build tooling. It can compile fully AoT.
isn't this just because Dart is way newer than those? it's from the 2010s. it's really modern in comparison (same generation as Kotlin swift and typescript)
Have you even used modern Dart?
Dart is hands down the best modern language out there for app development right now what are you even talking about? I understand that maybe a lot of people haven’t used it or maybe haven’t used it in years and that probably drives a lot of the FUD but for those who use it, it has stupidly high ratings from developers who use it and has for years.
It's not FUD when you make something terrible* and that reputation doesn't immediately slough off.<p>And I just checked the Dart release notes from all of 2025: <a href="https://dart.dev/resources/whats-new" rel="nofollow">https://dart.dev/resources/whats-new</a><p>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.<p>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?<p>-<p>* 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.
You seem confused and indeed spreading FUD.<p>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).<p>TypeScript won and became king because it was pretty much JS 2.0 instead of JS++ like Dart.
In your version of history Dart was always a great language... but Google was simultaneously too powerful for other vendors to allow Dart to proliferate, but also too weak to sustain it themselves <i>despite Chrome going on to do just that for many many web standards.</i><p>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.<p>-<p>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.<p>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 <i>by itself</i> was also pretty god awful since it was slowly reinventing native UI/UX from a canvas.<p>(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 your version of history Dart was always a great language... but Google was simultaneously too powerful for other vendors to allow Dart to proliferate, but also too weak to sustain it themselves despite Chrome going on to do just that for many many web standards.<p>"In my version of history"<p>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.<p>Educate yourself before making such claims, the decision to not adopt Dart wasn't because of its technical merits as a language.<p>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.
I guess this is the Dunning-Kruger effect everyone talks about!<p>To understand just enough to regurgitate <i>what</i> happened, but miss <i>why</i> it happened... and then assume someone who's pointing at the much more relevant <i>why</i> is just plain wrong.<p>Because <i>the why</i> requires actually understanding of things like developer mindshare rather than regurgitating search results.<p>-<p>The hint I'll leave if you're willing to consider <i>maybe</i> 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: <a href="https://github.com/webmachinelearning/prompt-api/blob/main/README.md" rel="nofollow">https://github.com/webmachinelearning/prompt-api/blob/main/R...</a><p><a href="https://github.com/mozilla/standards-positions/issues/1213" rel="nofollow">https://github.com/mozilla/standards-positions/issues/1213</a><p>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.
The last time I looked at it was far less mature on non-Android platforms than Flutter. Has that changed?
That's funny, I found it the exact opposite, not the least of which is that it requires a JetBrains IDE to even run it. VSCode or neovim with Flutter and really most every other UI framework like React (and Native) work great.<p>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.<p>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.<p>These days I'm looking forward to Dioxus, they're making their own native renderer similar to Flutter but especially for web, they are <i>not</i> 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.
Kotlin Multiplatform does seem pretty appealing, but haven't looked into it very much
In what way? It’s an unfinished, hot garbage bolted on top of Gradle. Flutter is light years ahead in terms of polish and development experience.
I think you're confused. It's not "something on top of Gradle". For instance to run on in Swift on iOS, it has to compile to native, and then it wraps it in a C interface and finally in a Swift interface. This has absolutely nothing to do with Gradle.
> For instance to run on in Swift on iOS, it has to compile to native, and then it wraps it in a C interface and finally in a Swift interface. This has absolutely nothing to do with Gradle.<p>And what exactly orchestrates the process of compilation (invoking Kotlin compiler + fetching dependencies)?
The bigger hit than performance is usually user experience quality and “write once debug everywhere”.
There is also Dioxus
I was initially uninterested in Dioxus because they just used webviews but their native renderer is really interesting now because it has a lot of strengths, using plain HTML and CSS as the markup language so that they don't have to render to a canvas on the web like Flutter, Compose Multiplatform or many other WASM based renderers do, as they can just, well, ship the HTML and CSS directly. But then on mobile and desktop, it <i>will</i> be rendered without a webview, so you get all the benefits of each platform.
React Native doesn't use Electron on mobile, it's a misconception. But it does depend on interpreted JavaScript on iOS and Android.
Swift on WASM also got very good last year. SQLite in WASM too.<p>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.<p>Edit: Several cross-platforms frameworks can do Liquid Glass:<p>- SwiftUI by using Skip for Android<p>- SwiftCrossUI<p>- React Native<p>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.
I’ve had very good experiences with Flutter on iOS and macOS. It’s actually a lot easier to get good performance in Flutter than SwiftUI.<p>No cross platform stack can do Liquid Glass yet. You have to wonder if that was one of design goals.
I'm pretty well convinced it was a goal too. If it wasn't then shame on them since it doesn't accomplish anything else well.
It’s nice developer experience indeed. But for me as a user, I hate it. Looks nothing like an iOS app, often even worse than fckng webviews…
> <i>Edit: Several cross-platforms frameworks can do Liquid Glass:
</i><p>This is pretty funny because you just listed SwiftUI three times but in different configurations. They're not <i>truly</i> 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.
If this is the current state of it, I can spot a dozen details that are wrong or missing: <a href="https://x.com/imadetheseworks/status/1973765948218941771/video/1" rel="nofollow">https://x.com/imadetheseworks/status/1973765948218941771/vid...</a><p>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.
Well, the library is literally 3 months old, and it's made by one person as an OSS package, so yes, I'm sure you can spot those wrong details. Still, it'll get there, especially once Flutter gets official support for Liquid Glass, as they are planning on working on it later this year or into next year, currently they are refactoring their current design library code.<p>> <i>and would never want those liquid components on platforms like Android or Windows anyway.</i><p>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.
> Liquid Glass isn't an optional decoration, it's the name of the new system-wide UI<p>Of course it’s optional. Some of the most popular apps on the planet ignore the local UI conventions of their parent OSes entirely.<p>TikTok is a Flutter app. It looks identical on iOS and Android. It uses basically no native UI elements.<p>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.
> Spotify, Facebook, Uber, and Reddit<p>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.
It’s cool that you are a non-conformist badass but their wild popularity proves that a native app experience doesn’t matter.<p>What does “bad iOS citizen” even mean?<p>It’s not even about saving money for developers, it’s about the fact that your users expect a consistent experience.<p>Imagine if you watched an NFL game on 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 content apps on smart TV app platforms which are way more fragmented than iOS versus Android).
Your conclusion is false, as you’re mixing stuff that shouldn’t be mixed here:<p>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.<p>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.<p>So, native experience does matter, but obviously only as one of multiple deciding factors.<p>> What does “bad iOS citizen” even mean?<p>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.
What I meant to say in my original message is that if you are using system default-ish iOS UI styling, Liquid Glass is not optional decoration. If you have your entirely own UI and design system, sure you don't need it. But many of these Flutter apps or other such toolkits are using it to approximate system default UI except either without the Liquid Glass parts or with uncanny and incomplete approximations of it.
Exactly. Branding and UX are breaking out of the box for guidelines in the successful platforms. You want to be able to pick up any device and have the user know exactly what theyre doing
I thought TikTok used native implementations and Lynx (their cross-platform framework)
in my experience wasm on web, though it works, has too slow a first page load time for slow connections.