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?
Probably 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
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:
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.
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.
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).
>But it does allow engineers, trained on one platform, to work on the other.
The programming language is the most surface level detail when learning a platform.
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).
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.
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.
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.
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.
When it comes to mobile, I think that React Native has some serious benefits:
- 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.
If I wanted to build the next TikTok though I'd 100% go full native.
>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.
If he can only remember two programming languages then he wouldn’t stand a chance in today’s dev ops, t-shaped, m-shaped world I’m afraid. Imagine asking him to help setup an CI pipeline, or some infrastructure but he’s worried learning a bit of Terraform will make him forget his second last language. You just can’t be like that these days. You have to be a jack of all trades and a master of all trades. That’s just where we are and it’s not going to change anytime soon.
A lot of language concepts are shared and abstract. It’s not hard to know many languages proficiently.
I do agree a lot of people over estimate how much they know, but I work with multiple people who know at least 5 languages well.
For me myself, only counting things I’ve shipped at scale, I’d know C, C++, Swift, JavaScript, Python, Rust, MSL, HLSL, GLSL, MEL. There’s enough in common between them that I think it’s quite doable.
Shipped !== know. I've touched dozens of languages over my career and every time I've had my ass kicked by some esoteric knowledge of specific quirk in std of %lang%. We have a different definition of "know".
You initially said beyond a surface level and now you’re talking about esoteric quirks.
Pick one. Of course nobody has the same definition as you if you’re shifting the line and simultaneously not defining what you mean.
You don’t need to know every aspect of a languages corners to be proficient in it. If that were true, there’s only a handful of people on this planet who’d be proficient in a single language let alone multiple.
Sure, I can "swim when thrown into the cold water", but you have to be a masochist to like that kind of job. It sucks. I won't do it if I don't have to, and luckily I don't have to.
It pays better than the alternatives and some freedom moving between technologies, which tend to be product development with an expiration date, until the company gets acquired or decides to offshore the team.
Contrary to product companies you also get to jump technologies without having an HR department sending the application into the garbage because one doesn't tick all the boxes on a specific stack.
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.
It'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.
Bill Gates, Tim Cook, Mark Zuckerberg, Satya Nadella, Sergey Brin and Sundar Pichai were all there dining with Trump.
Weird how Tim Cook gets so much hate, when the rest of them didn't. He didn't say anything notable except a bit of ring-kissing: "I want to thank you for setting the tone such that we can make a major investment ..."
Then Sergey Brin starts talking about how he's happy about Trump pressuring Maduro:
You're applying a lot of pressure to Maduro and I think that's phenomenal for an
American president to actually be applying pressure there uh in Venezuela and then hopefully in Cuba and so forth. So there's a lot of um civil rights work that you're leading. we didn't get a chance to mention. Um I also just wanted to mention um we don't have to get into all the uh details talked about in the Oval Office, but uh I think it's a real incredible inflection point right now in AI and the fact that your administration uh is uh supporting our companies instead of fighting with them."
So, reading between the lines a little, i.e. Google looking depose dictators and burn lots of oil to keep their AI slop churning is totally fine:
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.
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.
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.
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.
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.
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.
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++.
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.
I think IDE preference leans further towards subjective than many believe.
I find that IntelliJ IDEs are fine, but not nearly as amazing as they're often hyped up to be, and similarly while Xcode has problems it's not nearly as bad as is often claimed.
My experience is somewhat colored by Android Studio and JVM ecosystem stuff like gradle and proguard though, which have been more cumulative pain for me than anything Apple-side in a long time (Cocoapods was pretty gnarly but SwiftPM has fixed that).
Xcode 26.2 is a 2.1GB download, which expands to 8.63GB on disk, which includes the macOS SDK. The iOS SDK and simulators are another 8.38GB. Luckily Xcode versions can share iOS SDKs now, so you only need to install them once. Really the biggest disk eater is Xcode's default behavior of creating a huge set of simulators for every platform.
At 8.6gb of disk usage, they could include the entire macOS Mojave ISO disk image[0] and still have ~930 MB to include fit the IDE. It's just unprecedented.
You’re counting the development SDK against the IDE. Xcode itself doesn’t require that space, and you’d need that space regardless of IDE choice if you were targeting the platform.
Indeed, and unless that changed since, the Mac downloader isn't even capable of resuming downloads properly so if anything happens while you download these 13GB, it's back to square one.
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.
Xcode is so sluggish it's slower than an electron app despite being native, the xcode app upload is so broken even Apple released a third party tool to bypass their own IDE and its undocumented config files look like from the 90s and do not work well with git.
The UI is sort of okay but that's not going to cut it. You can feel the decades of cruft in this IDE, it feel like using Borland.
The UI is nice and I already know how to set up projects so it’s much better for me. The config files work perfectly fine with git, that’s where I put them.
I'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.
Yes, 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
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.
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.
Just because you can use it from C doesn't mean it's a C ABI. You can do almost anything from C, but the semantics of the APIs require additional work in order to use correctly. Just because golang can interface with C doesn't mean C APIs have a golang ABI right?
ABI 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.
You can argue that JNI technically is exposed via C, yeah if you ignore the JVM/ART semantics that go along with it.
Likewise on Windows, technically you can use bare bones structs with function pointers to deal with COM, use CLR COM APIs to call .NET via reflection, and a similar story with WinRT, but it is not going to be fun, and then there is the whole type libraries that have to be manually created.
I think we’re talking past each other, and you’re largely repeating what I already covered .
My original response delineated between levels of the stack, and also already called out that Android requires you to use the NDK/JNI to use the C ABI.
I also specifically called out windows as well.
My point is that the original persons distinction of what supports a C ABI is conflating different levels of the stack. It’s not a useful distinction when describing the platforms and the windows case is why I quote “PC” since desktop semantics vary quite a bit as well
A more useful delineation of why mobile dev is harder to just do an asm hello world is that mobile dev doesn’t really have a concept of CLIs without jumping through some hoops first. So you have to pipe such a thing through some kind of UI framework 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].
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.
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.
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.
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.
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
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.
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 (https://github.com/expo/expo/issues?q=is%3Aissue%20state%3Ao...) instead, something which is not part of flutter DX
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
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.
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
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 (https://expo.dev/pricing#plan-features) which clearly shows its a classic open-core funnel scheme to get developers to build dependence and end up paying for build credits
Those github build issues you've linked have nothing to do with funneling people to EAS Build. EAS build doesn't make your builds more reliable than just using fastlane and building on your own infra. Most build issues are due to react-native itself and when you have those issues it fails in EAS build as well. Giving Expo money doesn't save you from any of the build issues that plague React Native.
I have years of experience building react-native apps that use Expo in CircleCI and making them available to developers in our company with Diawi without paying Expo a dime.
Saying that I'm 'suspicious' because I have a good opinion of the technology I use in my day job at a SaaS company is ridiculous.
Is it great that Flutter probably has 10x less build issues than React Native? Yeah it is. A lot of things about Flutter's DX are better than React Native. But the fact is that you can produce a way better web app with React Native Web than you can with Flutter unless complex game-esque 2d graphics are the focus of your experience.
If you rebuilt twitter's website with Flutter (it's currently react-native-web) it would 100% be a worse experience.
It's not fair to blame accessibility issues on devs and just say it's a skill issue when other frameworks give you a baseline level of accessibility for free.
Ahh 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
Any 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.
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.
> Liquid Glass isn't an optional decoration, it's the name of the new system-wide UI
Of course it’s optional. Some of the most popular apps on the planet ignore the local UI conventions of their parent OSes entirely.
TikTok is a Flutter app. It looks identical on iOS and Android. It uses basically no native UI elements.
It’s a pretty well-known strategy to create apps that look identical on all platforms so that you lessen your customer confusion and your support burden. The fact that Spotify, Facebook, Uber, and Reddit look exactly the same no matter what platform you’re on is more important than complying with OS design guidelines and UI elements.
And I hate every one of those apps (well, back when I used Facebook, years ago, I did), because they’re just bad iOS citizens. I, as most iOS users do, don’t care what apps look on Android. For Android users, it’s the same with iOS. Making shitty cross platform apps is all about branding and saving some money for developers, nothing about the users.
It’s cool that you are a non-conformist badass but their wild popularity proves that a native app experience doesn’t matter.
What does “bad iOS citizen” even mean?
It’s not even about saving money for developers, it’s about the fact that your users expect a consistent experience.
Imagine if you watched an NFL game 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:
1. Spotify, Uber etc are popular because of their product, not the pure quality of their apps. People use Uber because they want to cheaply get somewhere, and Spotify cause that’s there all their shared playlists are.
2. People buy whatever tv is on sale when their old one breaks, but the vast majority will stay with their phone platform, so couldn’t care less what their apps look on the other platforms out there.
So, native experience does matter, but obviously only as one of multiple deciding factors.
> What does “bad iOS citizen” even mean?
Doesn’t look like native apps, doesn’t feel like native apps (come on, most multi platform frameworks don’t even get the scrolling right, one of the most basic forms of interaction), doesn’t use all of the platforms features to their fullest, as applicable for the type of app.
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
> Edit: Several cross-platforms frameworks can do Liquid Glass:
This is pretty funny because you just listed SwiftUI three times but in different configurations. They're not truly cross platform, they just wrap Apple's native design code. In contrast, I can (and do) use a package like liquid_glass_renderer to get Liquid Glass everywhere, on all my devices, with one codebase.
Maybe it will get there... Meanwhile I would rather use technologies that provide the full experience on the platform where it matters, and would never want those liquid components on platforms like Android or Windows anyway.
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.
> and would never want those liquid components on platforms like Android or Windows anyway.
That's where we disagree then, I like the design itself but don't like it stuck on only one platform. I make apps with wholly custom UI designs, not following any particular OS' "native" design, and that's why Flutter is so powerful, because I am not constrained to what pixels I can render to a screen, nor should I be.
Embedded Swift WASM is very small now. But it is still behind on some useful capabilities like having a replacement for Codable (which last I read may be getting a more performant replacement). Regular Swift WASM got a lot smaller too last year though.
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.
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'm curious about the use cases people you know used Qt to develop for mobile.
They were developing non-trivial mobile apps. The kind where you use your fingers on a touch screen, but that are more complex than just showing a text and an image. Say Google Maps, or WhatsApp.
The problem was not the lack of components: the problem was that it was C++. C++ is more complex to write correctly than Swift or Kotlin and harder to debug. Which made those teams measurably a lot slower. It's just the wrong technology for the use-case, IMO.
I also write complex UIs with QML and C++. I do not consider myself an expert in C++ but there is clearly a subset of it that I feel comfortable in. I think the combo of QML & C++ is great since QML lets you focus on the UI - and does a great job at it, and in C++ you can write performant code. C++ isn't that complicated these days - if you stick to a subset you're familiar with.
How much experience do you have writing mobile apps in Kotlin or Swift, as a comparison? I have worked in C++ for years, and in Swift for years. I have seen the exact same app being written both in Java and in C++.
> in C++ you can write performant code
This almost certainly does not matter for a mobile app, and definitely not for the UI part. In case your app has to do something that may need C++ (e.g. computer vision), then you can just call a C++ library over FFI.
> C++ isn't that complicated these days
I didn't mean that it is complicated. I can totally write C++. What I meant is that it is more complicated to get it right than modern languages. If users complain about a segmentation fault, it's often pretty tricky to debug. In Java/Kotlin, you will get an exception that tells you exactly which line crashed.
On top of that, C++ is slower to write. Again I have been able to compare teams working on the same app both in C++ and in Java/Kotlin/Swift (Java is not exactly a modern language, but still it's a lot faster to develop with).
And after all those disadvantages of using C++ for a mobile app, you end up with a UI that doesn't feel native to the platform.
Again: I still write C++ when it makes sense (usually that's for legacy reasons or libraries availability, otherwise Rust is a better choice IMO). But for writing a mobile UI? Doesn't make any sense to me.
Even for writing a Desktop app, I don't understand why people use Qt instead of e.g. Java. Kotlin/Compose seem to be coming on Desktop too, which makes a lot of sense to me. And maybe even Flutter.
Finally, I don't understand writing a cross-platform UI for Desktop and mobile. On mobile, I have a big finger and a small touch screen. On Desktop, I have a big screen, a mouse and a keyboard. Those require different UIs. Sharing the logic is fine, but the UI needs to be written for the platform.
> How much experience do you have writing mobile apps in Kotlin or Swift, as a comparison?
No, in the mobile space I've only used React Native and QML with C++.
> This almost certainly does not matter for a mobile app, and definitely not for the UI part.
I disagree. For example, I expect block editors to handle large texts efficiency - both in terms of power draw and performance. Writing in a non-compiled language already puts you in a disadvantage in both aspects. But this is just the standard I set to myself - the entire industry clearly has different priorities.
> I didn't mean that it is complicated. I can totally write C++. What I meant is that it is more complicated to get it right than modern languages. If users complain about a segmentation fault, it's often pretty tricky to debug. In Java/Kotlin, you will get an exception that tells you exactly which line crashed.
Yep, I generally agree, tho with good debugging tools and LLMs I have found this to not be a problem anymore.
> On top of that, C++ is slower to write. Again I have been able to compare teams working on the same app both in C++ and in Java/Kotlin/Swift (Java is not exactly a modern language, but still it's a lot faster to develop with).
I write in TypeScript at my day job and C++ for my side projects and I don't feel like I'm slower in C++. Again, I'm using the subset I'm conformable with.
> And after all those disadvantages of using C++ for a mobile app, you end up with a UI that doesn't feel native to the platform.
That has certainly been the case, and what I'm trying to fix - because I've proven that it is fixable by caring about UI/UX. QML is great for UI, it's just that Qt developers (both the developers of Qt and those using it) don't care much about those things. But it's definitely posiible to get good results. For example, I'm working on SwipeStackView like other iOS apps have in QML, and I'm liking what I've made so far: https://rubymamistvalove.com/notes-mobile-swipe-stack-view.M...
> Even for writing a Desktop app, I don't understand why people use Qt instead of e.g. Java. Kotlin/Compose seem to be coming on Desktop too, which makes a lot of sense to me. And maybe even Flutter.
Again, I can't stretch how FUN, easy, and overall a great experience to develop with QML and C++ together, it's just HOW GUI should always been. I'm thinking of creating some Youtube tutorials that will try to present this feeling.
> Finally, I don't understand writing a cross-platform UI for Desktop and mobile. On mobile, I have a big finger and a small touch screen. On Desktop, I have a big screen, a mouse and a keyboard. Those require different UIs. Sharing the logic is fine, but the UI needs to be written for the platform.
100%. Completely in agreement. The fact that you can develop both Desktop and mobile apps in QML doesn't mean you must make them share the same code (at least, not fully). I think Kirigami have gone the wrong way with their 'adaptable' UI (I've also thought about doing that until I realized it's the wrong approach). One should always start with the UX that the end result should be - never start from tech considerations.
> Writing in a non-compiled language already puts you in a disadvantage
Both Kotlin and Swift are compiled.
> But this is just the standard I set to myself - the entire industry clearly has different priorities.
I think you just underestimate the performance of Java/Kotlin/Swift, languages that you admitted you don't have any experience with.
> tho with good debugging tools and LLMs I have found this to not be a problem anymore
Again: try modern languages with good debugging tools and LLMs :-). I think your bias is that this is all you know.
> because I've proven that it is fixable by caring about UI/UX
It requires care, which means more effort. All that for being at best similar to the native tools, but probably never exactly the same. And it cannot be better, because the native ones are the ones defining how it should be.
> I can't stretch how FUN, easy, and overall a great experience to develop with QML and C++ together, it's just HOW GUI should always been
But you said you don't have experience with the native Android/iOS way. I personally have used QML/C++, Flutter, Android (Java/Kotlin, the old XML way and the new Compose way) and SwiftUI. QML/C++ is by very far the worst.
I would advise that you try either Kotlin/Compose or Swift/SwiftUI to get an idea. You can still use C++ to share some code (say you write a complex library in C++, no need to rewrite it in Kotlin and Swift), but starting a new mobile UI with QML these days is just madness IMHO :-).
I only said that because you said performant code "does not matter for a mobile app". I think writing apps in native frameworks is awesome! I'm all for it. BTW, I've heard some reports that SwiftUI/Swift are slow[1][2][3]. Again, I haven't explored SwiftUI and Kotlin, but I'd like some day. What do you love about them so much?
> All that for being at best similar to the native tools, but probably never exactly the same. And it cannot be better, because the native ones are the ones defining how it should be.
I agree, the best apps would almost always be those written in the framework the OS provides - kinda make sense - cross platform GUIs will always fall under the lowest common denominator issue - I've written about it in my blog post[4]. You also forget tho, that Linux does exist with a growing popularity - I think it's important to target it as well (I've started GUI development because I was on Linux and most apps had horrible UI/UX).
> but starting a new mobile UI with QML these days is just madness IMHO :-)
Memory safety, for one. A whole lot of better defaults (e.g. immutability by default). Then the influence of functional programming. Nice async primitives like coroutines.
It's not just Kotlin and Swift. Rust is nice as well. Even Java has actually improved a lot over the years.
Only C++ seems to get worse over the years. It's the only mainstream language where people say "if you limit yourself to a subset of the language, it's actually decent". And every year, C++ brings new stuff that people probably shouldn't include into their "decent" subset.
> You also forget tho, that Linux does exist with a growing popularity
I have been a Linux user for 20 years, I don't forget it. My favourite UI is a CLI, and there, languages like Go or Rust now often make more sense than C++. I am hoping that good desktop GUIs will come eventually, because I absolutely hate the web-based stuff like Electron. Maybe with Compose multiplatform? I hear Flutter is decent there, too.
> I've started GUI development because I was on Linux and most apps had horrible UI/UX
Except for IDEs (I like the JetBrains ones) and browser, I don't use GUIs :-).
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.
It also inherits all of the bad parts of the JVM. Crappy build tooling (gradle), and then the slow startup and high memory usage.
Coming from writing a ton of Swift (and previously Obj-C), Kotlin’s ergonomics feel kinda off. It also feels like it’s different for the sake of being different more often than I’d like.
Can you give concrete examples? I played with Swift in school after already making the dive into Kotlin. It just felt like Kotlin but trapped on Apple. Part of the program even included a course in using a different language every couple weeks where we went through Scala, Lisp, and some others just to see what they could do.
Currently Kotlin is far and away my favorite language but I also haven't looked into the newer languages recently and am interested in hearing pain points people have. Especially if it isn't annoyances with Gradle
Broadly speaking, Kotlin deviates from popular conventions more than Swift does. For example, Kotlin expects you to use inline if statements where in Swift, ternary operators work like they do in C, JavaScript, and many other languages.
There's also things like Swift's guard statements that can help make intent clearer and read a bit more nicely.
Same opinion. It just feels off. Why use `fun` for function declarations instead of func or function? Dropping () before { makes it hard to tell what runs first. It feels like it's trying to be different for the sake of being different. I'm not able to quickly skim kotlin code like other 'C-like' languages and tell what is going on because it's trying to be too clever.
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)`).
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`.
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.
Eh, it's getting there, slowly at first but more rapidly now. It now got tearoffs, I explained in another comment but
> if you have an `enum Color { red, blue }` and a function takes `Color`, you can just do `f(.red)` not `f(Color.red)`
Dart is getting new features pretty fast, they really started focusing on the DX more after Dart 2 and now especially after Dart 3. Macros were supposed to ship but it was incompatible with the goals of fast compilation, so other sorts of smaller features will ship instead.
Big turnoff with Dart is the lack of json (de) serialization -- kind of shocking to have to resort to source code generation libraries in a modern language.
Also, statement based instead of expression based, and not immutable by default are kind of a drag; not the end of the world but a bit unpleasant, IMO.
Serialization support is coming, probably this year. As for statements vs expressions, it does have some expressions such as if and for inside lists but changing it wholesale to an expression based language would be too much of a breaking change.
Serialization support has been coming for years, I lost patience.
Otherwise, yes, some support for expressions, some support for immutability, no support for optional semi-colons, no privacy modifiers so "_" littered everywhere.
I just found it to be an exceedingly ugly language when I used it a couple of years ago. Yes, some more pleasant modern functionality has been bolted on since then, but it's unfortunate that Dart was chosen as the backing language for Flutter, which is an awesome mobile framework.
Serialization has always been possible via libraries, so most people were doing fine with that, what is coming is native serialization support, but in practice it will be functionally the same, ie rather than you running build_runner, the compiler will do it for you. I'm not sure what you used but that's what you were hung up on, there were always ways to solve it.
Dart is a pragmatic language, it has everything you need and has a lot of benefits too, such as sound null checking (very few languages have this, Rust comes to mind), JIT and AOT support (Javascript / TypeScript such as for React Native doesn't, and Kotlin is just getting there with Kotlin Native but it still has a lot of issues), and now more functional programming concepts with algebraic data types via sealed classes and pattern matching.
What language would you have chosen when Flutter came out circa a decade ago, or, we can be even more charitable and ask what language would you use today if you were to implement Flutter? I'm curious because everyone has their own ideas but they all don't work for one reason or another.
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)
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.
Great progress! But smells a lot like the language I had it pegged for when "underscore as a wildcard" lands in February 2025, 2 years after pattern matching lands.
How did they ship pattern matching in 2023, with a million examples of how to do it right already hashed out and in the wild... and then not figure out a wildcard symbol for 2 years?
-
* Dart was awful, lost to Javascript because no one rated it highly enough to justify moving off Javascript, and was practically dead until Flutter dusted off the corpse and pivoted away from their browser goals... so super weird revisionism to act like we're talking about some beloved evergreen language.
> 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?
We shipped support for `_` as wildcards in patterns with Dart 3.0 when pattern matching first shipped.
However, prior to Dart 3.0, `_` was already a valid identifier (as it is in most other languages). The feature you're mentioning from last year was to remove support for uses of `_` as an identifier outside of patterns. This way `_` consistently behaves like a wildcard everywhere in the language. We didn't ship that in 3.0 because it's a breaking change and those are harder to roll out without causing a lot of user pain.
It's OK to not like Dart. There are multiple popular languages for a reason. But it is helpful when communicating about a language to others to be accurate so that they can make their own informed opinions.
Dart wasn’t awful. It wasn’t adopted at the time because it had a distinct runtime that would require splitting web in two which nobody wanted. On top of that it gave Google too much power, because now they would control both runtime (V8) + language (Dart).
TypeScript won and became king because it was pretty much JS 2.0 instead of JS++ like Dart.
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.
I'm sure that's a really cozy idea, but doesn't pass the "common sense" test: a bit like your random misuse of the term FUD.
-
The simple reality is it wasn't very good, so no one was rushing to use it, and that limited how hard Google could push it. ES6 made Javascript good enough for the time being.
Dart 1.x had a weak type system, and Dart 2 was adding basics Kotlin already had almost 2 years earlier: that was also around the time I first crossed paths with Flutter, and honestly Flutter by itself was also pretty god awful since it was slowly reinventing native UI/UX from a canvas.
(It was a lot like Ionic: something you used when you had a captive user-base that literally couldn't pick a better product. Great for Google!)
> In 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.
"In my version of history"
It takes two seconds to find this if you weren't there when it happened. Google had a fork of Chromium with Dart VM called Dartium, it wasn't a matter of resources. Industry flipped Google off, plain and simple.
Educate yourself before making such claims, the decision to not adopt Dart wasn't because of its technical merits as a language.
The rest of your comment is just your opinion, so you do you. I'm not a Dart or Flutter devrel team to sell you their product.
I guess this is the Dunning-Kruger effect everyone talks about!
To understand just enough to regurgitate what happened, but miss why it happened... and then assume someone who's pointing at the much more relevant why is just plain wrong.
Because the why requires actually understanding of things like developer mindshare rather than regurgitating search results.
-
The hint I'll leave if you're willing to consider maybe you don't know everything ever... look at who's feedback is being promoted when Chrome wants to do obviously unpopular things on the web: https://github.com/webmachinelearning/prompt-api/blob/main/R...
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.
This is completely incorrect. Large companies like Canonical are all in on Flutter even now, they're making it the default for desktop UI development in Ubuntu and are writing a lot of their own apps in Flutter.
The "layoffs" were not any of the core team, it was just an offshoring, of infrastructure devs at Google that happened to work on Flutter builds, to Europe where they rehired for the same positions there.
Google Workspace has been moving to KMP. They said at KotlinConf that it has replaced their decade-old transpiler from Java to ObjC, which is very impressive.
Yes this is because they are starting with a Java codebase and that obviously makes sense there.
You have other platforms like Google earth who when it was time for a proper rewrite went with flutter and dart along with a bunch of Google cloud stuff and Google Ads.
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.
Regarding KMP specifically, I didn't find it much use to only write business logic in one language, while still having to rewrite the UI up to 6 times (mobile, web, desktop), I'd rather have everything all in one.
Compose Multiplatform looks promising as it's Flutter-like in that it renders its own UI but it's still quite early, I know they say it's "stable" but when I used it, it really didn't seem so, plus the package support is extremely lacking compared to Flutter and of course the behemoth that is React (and Native)'s npm.
These days I'm looking forward to Dioxus, they're making their own native renderer similar to Flutter but especially for web, they are not doing the canvas trick, because they actually use plain HTML and CSS as their markup languages so they can compile directly to browser standards sites while still having a non-webview experience on mobile and desktop.
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.
And what exactly orchestrates the process of compilation (invoking Kotlin compiler + fetching dependencies)?
Whatever you want, really. The default just happens to be Gradle because that's the default on Android.
My point is that the fundamental difference between Flutter and KMP is not at all Gradle.
Last time I checked, Flutter was relying on messaging. KMP leverages FFIs. Flutter is a framework, KMP is not. If all you see is the command line you invoke to run the build, I think you're missing a lot.
I know react native for windows is a thing, but is it on par with electron these days? my understand is that it was way beyond, but I could def be wrong
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 will be rendered without a webview, so you get all the benefits of each platform.
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?
Probably 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
Interestinggg. How does binding Java/Kotlin code into Swift work?
(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: 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.
For 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.
Another approach is swift-java, which uses Swift macros and also supports Panama.
https://github.com/swiftlang/swift-java
Panama will probably never make it to Android, given Google's behaviour on updating Java support.
Congrats, I've definitely been looking to just centralize with Swift. Great work!
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).
>But it does allow engineers, trained on one platform, to work on the other.
The programming language is the most surface level detail when learning a platform.
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
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.
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.
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.
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.
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.
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.
When it comes to mobile, I think that React Native has some serious benefits:
- 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.
If I wanted to build the next TikTok though I'd 100% go full native.
>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.
If he can only remember two programming languages then he wouldn’t stand a chance in today’s dev ops, t-shaped, m-shaped world I’m afraid. Imagine asking him to help setup an CI pipeline, or some infrastructure but he’s worried learning a bit of Terraform will make him forget his second last language. You just can’t be like that these days. You have to be a jack of all trades and a master of all trades. That’s just where we are and it’s not going to change anytime soon.
Many times this. I'm always skeptical if people saying they know 5+ programming languages beyond surface level.
A lot of language concepts are shared and abstract. It’s not hard to know many languages proficiently.
I do agree a lot of people over estimate how much they know, but I work with multiple people who know at least 5 languages well.
For me myself, only counting things I’ve shipped at scale, I’d know C, C++, Swift, JavaScript, Python, Rust, MSL, HLSL, GLSL, MEL. There’s enough in common between them that I think it’s quite doable.
> A lot of language concepts are shared and abstract. It’s not hard to know many languages proficiently.
Every language has thousands of papercuts. It is hard to know many languages proficiently beyond surface syntax level, period.
> I’d know C, C++, Swift, JavaScript, Python, Rust, MSL, HLSL, GLSL, MEL
Shipped !== know. I've touched dozens of languages over my career and every time I've had my ass kicked by some esoteric knowledge of specific quirk in std of %lang%. We have a different definition of "know".
Now you’re just shifting the goalpost.
You initially said beyond a surface level and now you’re talking about esoteric quirks.
Pick one. Of course nobody has the same definition as you if you’re shifting the line and simultaneously not defining what you mean.
You don’t need to know every aspect of a languages corners to be proficient in it. If that were true, there’s only a handful of people on this planet who’d be proficient in a single language let alone multiple.
> If that were true, there’s only a handful of people on this planet who’d be proficient in a single language let alone multiple.
This was indeed my point from the start.
I’m just trying to understand what your bar is for “knowing a language”
Is there a language you’d feel comfortable saying you know every single aspect of, without exception? Down to every compiler and implementation quirk?
Yes.
When you work in enterprise consulting, it suffices to know a language good enough to deliver.
It is common practice to be thrown at random projects regardless of the programming project.
What is valued is the soft skills, and the ability to swim when thrown into the cold water, no matter how.
Yes it kind of sucks, however the Pandora box is long open and only an implosion of the capitalist enterprise culture would fix it.
Sure, I can "swim when thrown into the cold water", but you have to be a masochist to like that kind of job. It sucks. I won't do it if I don't have to, and luckily I don't have to.
It pays better than the alternatives and some freedom moving between technologies, which tend to be product development with an expiration date, until the company gets acquired or decides to offshore the team.
Contrary to product companies you also get to jump technologies without having an HR department sending the application into the garbage because one doesn't tick all the boxes on a specific stack.
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.
Shocked to hear Swift described as "painful" (well, maybe the new concurrency stuff)
It'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.
I have unfortunate news about the tech industry in general.
Indeed, but it doesn't hurt to be a bit more selective and future thinking when choosing a stack or tools.
Where are you heading to next?
So Swift is painful to use because Tim Cook once had dinner with someone you don’t like?
Bill Gates, Tim Cook, Mark Zuckerberg, Satya Nadella, Sergey Brin and Sundar Pichai were all there dining with Trump.
Weird how Tim Cook gets so much hate, when the rest of them didn't. He didn't say anything notable except a bit of ring-kissing: "I want to thank you for setting the tone such that we can make a major investment ..."
Then Sergey Brin starts talking about how he's happy about Trump pressuring Maduro:
You're applying a lot of pressure to Maduro and I think that's phenomenal for an American president to actually be applying pressure there uh in Venezuela and then hopefully in Cuba and so forth. So there's a lot of um civil rights work that you're leading. we didn't get a chance to mention. Um I also just wanted to mention um we don't have to get into all the uh details talked about in the Oval Office, but uh I think it's a real incredible inflection point right now in AI and the fact that your administration uh is uh supporting our companies instead of fighting with them."
So, reading between the lines a little, i.e. Google looking depose dictators and burn lots of oil to keep their AI slop churning is totally fine:
https://www.youtube.com/watch?v=MvbKA-Te8QE
[flagged]
As you say elswhere in this thread:
> Indeed, but it doesn't hurt to be a bit more selective and future thinking when choosing a stack or tools.
So if Microsoft, Apple, Google and Facebook are off the table, what's your stack looking like?
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 two OS' are just so fundamentally different.
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.
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.
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.
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.
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.
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.
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.
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.
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++.
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?
[1] https://skip.tools/
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).
It’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.
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.
I find that IntelliJ IDEs are fine, but not nearly as amazing as they're often hyped up to be, and similarly while Xcode has problems it's not nearly as bad as is often claimed.
My experience is somewhat colored by Android Studio and JVM ecosystem stuff like gradle and proguard though, which have been more cumulative pain for me than anything Apple-side in a long time (Cocoapods was pretty gnarly but SwiftPM has fixed that).
There's definitely room for subjectivity, but my hard drive space is finite. And XCode takes up more room than all of my Jetbrains software combined.
Xcode download is only a couple GBs
12-20 GB, and only that if you don't want to run software on any iOS simulator.
Xcode 26.2 is a 2.1GB download, which expands to 8.63GB on disk, which includes the macOS SDK. The iOS SDK and simulators are another 8.38GB. Luckily Xcode versions can share iOS SDKs now, so you only need to install them once. Really the biggest disk eater is Xcode's default behavior of creating a huge set of simulators for every platform.
At 8.6gb of disk usage, they could include the entire macOS Mojave ISO disk image[0] and still have ~930 MB to include fit the IDE. It's just unprecedented.
[0] https://archive.org/details/mac-osx-mojave-iso
You’re counting the development SDK against the IDE. Xcode itself doesn’t require that space, and you’d need that space regardless of IDE choice if you were targeting the platform.
Indeed, and unless that changed since, the Mac downloader isn't even capable of resuming downloads properly so if anything happens while you download these 13GB, it's back to square one.
For years, my team uses the third-party tool `xcodes`... `brew install xcodes` or use the [GUI](https://www.xcodes.app/).
It allows you to easily install and maintain several versions of Xcode (beta / RC versions).
And, more importantly, uses aria2 for HTTP download, which has resumability.
Now this is the stuff that Apple should be Sherlocking, but doesn't.
The comment is wrong, the download is ~2 GB
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.
I use a Mac and using anything Jetbrains is miserable. Nothing works the way it should and all the keyboard shortcuts are completely different.
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.
Xcode is so sluggish it's slower than an electron app despite being native, the xcode app upload is so broken even Apple released a third party tool to bypass their own IDE and its undocumented config files look like from the 90s and do not work well with git.
The UI is sort of okay but that's not going to cut it. You can feel the decades of cruft in this IDE, it feel like using Borland.
The UI is nice and I already know how to set up projects so it’s much better for me. The config files work perfectly fine with git, that’s where I put them.
I used eclipse in the past and unless they became worse, the current xcode is still worse that ~2015 eclipse (last time I've used it)
Eclipse is also better than IntelliJ if we’re rounding out the unpopular IDE opinions
what makes intellij so bad? (personally i thought it was better than eclipse but idk)
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.
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.
Yes, exactly. SwifDroid automatically wires all the necessary Gradle dependencies, so you don’t have to manage them manually.
Does it still ultimately call into gradle to perform the build?
Yes, 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
Why is mobile development so shitty compared to PC? Why cant you make an hello world in asm for a mobile device?
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.
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.
Just because you can use it from C doesn't mean it's a C ABI. You can do almost anything from C, but the semantics of the APIs require additional work in order to use correctly. Just because golang can interface with C doesn't mean C APIs have a golang ABI right?
Which of the platforms (other than Android) require you to do extra work to talk to the underlying system API with a C ABI?
iOS certainly doesn’t require any extra work, and even exposes several C api for frameworks as well (not even including ObjC).
And even in the case of Android, the system provides JNI facilities so it’s not foreign to the system.
ABI 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.
They’re describing higher level API that may have a separate ABI than the lower level system.
But like I said, they’re conflating the lower level ABI with the higher level API/ABI.
All the systems they mentioned have an equal C ABI available for talking to the core system.
No they don't, you cannot use C in Android outside the NDK, and even on the NDK you need to go through JNI for 80% of the OS APIs.
This is the only set of APIs exposed via a C API to Android applications,
https://developer.android.com/ndk/guides/stable_apis
You can argue that JNI technically is exposed via C, yeah if you ignore the JVM/ART semantics that go along with it.
Likewise on Windows, technically you can use bare bones structs with function pointers to deal with COM, use CLR COM APIs to call .NET via reflection, and a similar story with WinRT, but it is not going to be fun, and then there is the whole type libraries that have to be manually created.
I think we’re talking past each other, and you’re largely repeating what I already covered .
My original response delineated between levels of the stack, and also already called out that Android requires you to use the NDK/JNI to use the C ABI.
I also specifically called out windows as well.
My point is that the original persons distinction of what supports a C ABI is conflating different levels of the stack. It’s not a useful distinction when describing the platforms and the windows case is why I quote “PC” since desktop semantics vary quite a bit as well
A more useful delineation of why mobile dev is harder to just do an asm hello world is that mobile dev doesn’t really have a concept of CLIs without jumping through some hoops first. So you have to pipe such a thing through some kind of UI framework as well.
If userspace needs to use NDK/JNI ABI to call the Linux C ABI, naturally the OS ABI isn't the C ABI, by definition.
Why not? The NDK/JNI calls are still in user space themselves. So what delineation are you trying to make here?
How userspace applications talk to the kernel subsystems, in a legal way without hacking the operating system architecture.
Small correction.
On PC, MS-DOS did not use C, rather interrupts and there was no common C ABI.
On OS/2, a mix of C ABI and SOM, with C, C++ and Smalltalk as main languages.
Windows started only with the C ABI, nowadays it is a mix of C, C++, .NET, COM, WinRT, depending on the subsystem.
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...
https://gist.github.com/nicolas17/966a03ce49f949dd17b0123415...
Been 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?
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].
[0] https://old.reddit.com/r/androiddev/comments/1np26m4/do_othe...
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.
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.
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.
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.
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.
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
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.
The cookie consent definitely feels not legal in europe
Thanks
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
With KMP, you can also share UI code with Compose Multiplatform.
Isn’t that still like alpha or beta for iOS?
It's stable: https://www.jetbrains.com/compose-multiplatform/
How to make a HTTP call and parse JSON response idiomatically?
[dead]
[flagged]
Shameless self promotion. Account created 5 minutes ago, 0 karma.
Dead link
[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.
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.
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
I haven't touched flutter in two years, but isn't getX a kitchen sink library disliked by everyone?
11k likes on github means everyone hates it? it is anti-pattern which might turn people off sure.
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.
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.
Flutter for the web is lacking but for iOS/Android/Windows it's ideal.
The DX may be ideal but they are not very ideal for your iOS users. Painting pixels vs composing native views is not great.
I’d rather put up with the more painful DX of react native because I care more about the quality of the app vs the DX
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 (https://github.com/expo/expo/issues?q=is%3Aissue%20state%3Ao...) instead, something which is not part of flutter DX
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
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.
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
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 (https://expo.dev/pricing#plan-features) which clearly shows its a classic open-core funnel scheme to get developers to build dependence and end up paying for build credits
Those github build issues you've linked have nothing to do with funneling people to EAS Build. EAS build doesn't make your builds more reliable than just using fastlane and building on your own infra. Most build issues are due to react-native itself and when you have those issues it fails in EAS build as well. Giving Expo money doesn't save you from any of the build issues that plague React Native.
I have years of experience building react-native apps that use Expo in CircleCI and making them available to developers in our company with Diawi without paying Expo a dime.
Saying that I'm 'suspicious' because I have a good opinion of the technology I use in my day job at a SaaS company is ridiculous.
Is it great that Flutter probably has 10x less build issues than React Native? Yeah it is. A lot of things about Flutter's DX are better than React Native. But the fact is that you can produce a way better web app with React Native Web than you can with Flutter unless complex game-esque 2d graphics are the focus of your experience.
If you rebuilt twitter's website with Flutter (it's currently react-native-web) it would 100% be a worse experience.
It's not fair to blame accessibility issues on devs and just say it's a skill issue when other frameworks give you a baseline level of accessibility for free.
Just in time, right when Apple is quietly abandoning it
Apple is abandoning Swift on Android?
I think you are confused with Objective-C.
That’s one I haven’t heard yet, do elaborate
He might be referring to Apple abandoning SwiftUI as there’s a rumor going around about it.
Ahh 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
Any 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.
https://www.youtube.com/watch?v=pL8Ex0Co8fA
Rumors are worth exactly what you pay for them.
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 -
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?
> it surprises me that this hasn't been perfected
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.
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.
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…
All those approximations at Liquid Glass are infuriating to use and make every app that does feel cheap and gross
> Liquid Glass isn't an optional decoration, it's the name of the new system-wide UI
Of course it’s optional. Some of the most popular apps on the planet ignore the local UI conventions of their parent OSes entirely.
TikTok is a Flutter app. It looks identical on iOS and Android. It uses basically no native UI elements.
It’s a pretty well-known strategy to create apps that look identical on all platforms so that you lessen your customer confusion and your support burden. The fact that Spotify, Facebook, Uber, and Reddit look exactly the same no matter what platform you’re on is more important than complying with OS design guidelines and UI elements.
> Spotify, Facebook, Uber, and Reddit
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.
What does “bad iOS citizen” even mean?
It’s not even about saving money for developers, it’s about the fact that your users expect a consistent experience.
Imagine if you watched an NFL game 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:
1. Spotify, Uber etc are popular because of their product, not the pure quality of their apps. People use Uber because they want to cheaply get somewhere, and Spotify cause that’s there all their shared playlists are.
2. People buy whatever tv is on sale when their old one breaks, but the vast majority will stay with their phone platform, so couldn’t care less what their apps look on the other platforms out there.
So, native experience does matter, but obviously only as one of multiple deciding factors.
> What does “bad iOS citizen” even mean?
Doesn’t look like native apps, doesn’t feel like native apps (come on, most multi platform frameworks don’t even get the scrolling right, one of the most basic forms of interaction), doesn’t use all of the platforms features to their fullest, as applicable for the type of app.
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
Thank God I’m only using web versions whenever possible.
Which also have consistent branding and UX with the apps.
That's fine, as long as I have native OS dialogs/settings.
I thought TikTok used native implementations and Lynx (their cross-platform framework)
I dunno, the ByteDance logo is on the Flutter web page.
But it really doesn’t matter either way. The point is that TikTok doesn’t follow any OS conventions.
> Edit: Several cross-platforms frameworks can do Liquid Glass:
This is pretty funny because you just listed SwiftUI three times but in different configurations. They're not truly cross platform, they just wrap Apple's native design code. In contrast, I can (and do) use a package like liquid_glass_renderer to get Liquid Glass everywhere, on all my devices, with one codebase.
If this is the current state of it, I can spot a dozen details that are wrong or missing: https://x.com/imadetheseworks/status/1973765948218941771/vid...
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.
> and would never want those liquid components on platforms like Android or Windows anyway.
That's where we disagree then, I like the design itself but don't like it stuck on only one platform. I make apps with wholly custom UI designs, not following any particular OS' "native" design, and that's why Flutter is so powerful, because I am not constrained to what pixels I can render to a screen, nor should I be.
in my experience wasm on web, though it works, has too slow a first page load time for slow connections.
Embedded Swift WASM is very small now. But it is still behind on some useful capabilities like having a replacement for Codable (which last I read may be getting a more performant replacement). Regular Swift WASM got a lot smaller too last year though.
interesting - do you have a good example of a non-trivial web app that uses swift wasm?
Goodnotes
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.
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.
Hi there! I'm curious about the use cases people you know used Qt to develop for mobile. Do you mind expanding on this?
I'd love if you could also contact me (my socials are in my profile) as I'm developing a set of components to help exactly in that situation.
> I'm curious about the use cases people you know used Qt to develop for mobile.
They were developing non-trivial mobile apps. The kind where you use your fingers on a touch screen, but that are more complex than just showing a text and an image. Say Google Maps, or WhatsApp.
The problem was not the lack of components: the problem was that it was C++. C++ is more complex to write correctly than Swift or Kotlin and harder to debug. Which made those teams measurably a lot slower. It's just the wrong technology for the use-case, IMO.
I also write complex UIs with QML and C++. I do not consider myself an expert in C++ but there is clearly a subset of it that I feel comfortable in. I think the combo of QML & C++ is great since QML lets you focus on the UI - and does a great job at it, and in C++ you can write performant code. C++ isn't that complicated these days - if you stick to a subset you're familiar with.
How much experience do you have writing mobile apps in Kotlin or Swift, as a comparison? I have worked in C++ for years, and in Swift for years. I have seen the exact same app being written both in Java and in C++.
> in C++ you can write performant code
This almost certainly does not matter for a mobile app, and definitely not for the UI part. In case your app has to do something that may need C++ (e.g. computer vision), then you can just call a C++ library over FFI.
> C++ isn't that complicated these days
I didn't mean that it is complicated. I can totally write C++. What I meant is that it is more complicated to get it right than modern languages. If users complain about a segmentation fault, it's often pretty tricky to debug. In Java/Kotlin, you will get an exception that tells you exactly which line crashed.
On top of that, C++ is slower to write. Again I have been able to compare teams working on the same app both in C++ and in Java/Kotlin/Swift (Java is not exactly a modern language, but still it's a lot faster to develop with).
And after all those disadvantages of using C++ for a mobile app, you end up with a UI that doesn't feel native to the platform.
Again: I still write C++ when it makes sense (usually that's for legacy reasons or libraries availability, otherwise Rust is a better choice IMO). But for writing a mobile UI? Doesn't make any sense to me.
Even for writing a Desktop app, I don't understand why people use Qt instead of e.g. Java. Kotlin/Compose seem to be coming on Desktop too, which makes a lot of sense to me. And maybe even Flutter.
Finally, I don't understand writing a cross-platform UI for Desktop and mobile. On mobile, I have a big finger and a small touch screen. On Desktop, I have a big screen, a mouse and a keyboard. Those require different UIs. Sharing the logic is fine, but the UI needs to be written for the platform.
> How much experience do you have writing mobile apps in Kotlin or Swift, as a comparison?
No, in the mobile space I've only used React Native and QML with C++.
> This almost certainly does not matter for a mobile app, and definitely not for the UI part.
I disagree. For example, I expect block editors to handle large texts efficiency - both in terms of power draw and performance. Writing in a non-compiled language already puts you in a disadvantage in both aspects. But this is just the standard I set to myself - the entire industry clearly has different priorities.
> I didn't mean that it is complicated. I can totally write C++. What I meant is that it is more complicated to get it right than modern languages. If users complain about a segmentation fault, it's often pretty tricky to debug. In Java/Kotlin, you will get an exception that tells you exactly which line crashed.
Yep, I generally agree, tho with good debugging tools and LLMs I have found this to not be a problem anymore.
> On top of that, C++ is slower to write. Again I have been able to compare teams working on the same app both in C++ and in Java/Kotlin/Swift (Java is not exactly a modern language, but still it's a lot faster to develop with).
I write in TypeScript at my day job and C++ for my side projects and I don't feel like I'm slower in C++. Again, I'm using the subset I'm conformable with.
> And after all those disadvantages of using C++ for a mobile app, you end up with a UI that doesn't feel native to the platform.
That has certainly been the case, and what I'm trying to fix - because I've proven that it is fixable by caring about UI/UX. QML is great for UI, it's just that Qt developers (both the developers of Qt and those using it) don't care much about those things. But it's definitely posiible to get good results. For example, I'm working on SwipeStackView like other iOS apps have in QML, and I'm liking what I've made so far: https://rubymamistvalove.com/notes-mobile-swipe-stack-view.M...
> Even for writing a Desktop app, I don't understand why people use Qt instead of e.g. Java. Kotlin/Compose seem to be coming on Desktop too, which makes a lot of sense to me. And maybe even Flutter.
Again, I can't stretch how FUN, easy, and overall a great experience to develop with QML and C++ together, it's just HOW GUI should always been. I'm thinking of creating some Youtube tutorials that will try to present this feeling.
> Finally, I don't understand writing a cross-platform UI for Desktop and mobile. On mobile, I have a big finger and a small touch screen. On Desktop, I have a big screen, a mouse and a keyboard. Those require different UIs. Sharing the logic is fine, but the UI needs to be written for the platform.
100%. Completely in agreement. The fact that you can develop both Desktop and mobile apps in QML doesn't mean you must make them share the same code (at least, not fully). I think Kirigami have gone the wrong way with their 'adaptable' UI (I've also thought about doing that until I realized it's the wrong approach). One should always start with the UX that the end result should be - never start from tech considerations.
[1] https://develop.kde.org/frameworks/kirigami//
> Writing in a non-compiled language already puts you in a disadvantage
Both Kotlin and Swift are compiled.
> But this is just the standard I set to myself - the entire industry clearly has different priorities.
I think you just underestimate the performance of Java/Kotlin/Swift, languages that you admitted you don't have any experience with.
> tho with good debugging tools and LLMs I have found this to not be a problem anymore
Again: try modern languages with good debugging tools and LLMs :-). I think your bias is that this is all you know.
> because I've proven that it is fixable by caring about UI/UX
It requires care, which means more effort. All that for being at best similar to the native tools, but probably never exactly the same. And it cannot be better, because the native ones are the ones defining how it should be.
> I can't stretch how FUN, easy, and overall a great experience to develop with QML and C++ together, it's just HOW GUI should always been
But you said you don't have experience with the native Android/iOS way. I personally have used QML/C++, Flutter, Android (Java/Kotlin, the old XML way and the new Compose way) and SwiftUI. QML/C++ is by very far the worst.
I would advise that you try either Kotlin/Compose or Swift/SwiftUI to get an idea. You can still use C++ to share some code (say you write a complex library in C++, no need to rewrite it in Kotlin and Swift), but starting a new mobile UI with QML these days is just madness IMHO :-).
> Both Kotlin and Swift are compiled.
I only said that because you said performant code "does not matter for a mobile app". I think writing apps in native frameworks is awesome! I'm all for it. BTW, I've heard some reports that SwiftUI/Swift are slow[1][2][3]. Again, I haven't explored SwiftUI and Kotlin, but I'd like some day. What do you love about them so much?
> All that for being at best similar to the native tools, but probably never exactly the same. And it cannot be better, because the native ones are the ones defining how it should be.
I agree, the best apps would almost always be those written in the framework the OS provides - kinda make sense - cross platform GUIs will always fall under the lowest common denominator issue - I've written about it in my blog post[4]. You also forget tho, that Linux does exist with a growing popularity - I think it's important to target it as well (I've started GUI development because I was on Linux and most apps had horrible UI/UX).
> but starting a new mobile UI with QML these days is just madness IMHO :-)
Follow my mad adventure (:
[1] https://notes.alinpanaitiu.com/SwiftUI%20is%20convenient,%20...
[2] https://x.com/daniel_nguyenx/status/1734495508746702936
[3] https://danielchasehooper.com/posts/why-swift-is-slow/
[4] https://rubymamistvalove.com/block-editor#9-aesthetics
> What do you love about them so much?
Memory safety, for one. A whole lot of better defaults (e.g. immutability by default). Then the influence of functional programming. Nice async primitives like coroutines.
It's not just Kotlin and Swift. Rust is nice as well. Even Java has actually improved a lot over the years.
Only C++ seems to get worse over the years. It's the only mainstream language where people say "if you limit yourself to a subset of the language, it's actually decent". And every year, C++ brings new stuff that people probably shouldn't include into their "decent" subset.
> You also forget tho, that Linux does exist with a growing popularity
I have been a Linux user for 20 years, I don't forget it. My favourite UI is a CLI, and there, languages like Go or Rust now often make more sense than C++. I am hoping that good desktop GUIs will come eventually, because I absolutely hate the web-based stuff like Electron. Maybe with Compose multiplatform? I hear Flutter is decent there, too.
> I've started GUI development because I was on Linux and most apps had horrible UI/UX
Except for IDEs (I like the JetBrains ones) and browser, I don't use GUIs :-).
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.
It also inherits all of the bad parts of the JVM. Crappy build tooling (gradle), and then the slow startup and high memory usage.
Coming from writing a ton of Swift (and previously Obj-C), Kotlin’s ergonomics feel kinda off. It also feels like it’s different for the sake of being different more often than I’d like.
Can you give concrete examples? I played with Swift in school after already making the dive into Kotlin. It just felt like Kotlin but trapped on Apple. Part of the program even included a course in using a different language every couple weeks where we went through Scala, Lisp, and some others just to see what they could do.
Currently Kotlin is far and away my favorite language but I also haven't looked into the newer languages recently and am interested in hearing pain points people have. Especially if it isn't annoyances with Gradle
Broadly speaking, Kotlin deviates from popular conventions more than Swift does. For example, Kotlin expects you to use inline if statements where in Swift, ternary operators work like they do in C, JavaScript, and many other languages.
There's also things like Swift's guard statements that can help make intent clearer and read a bit more nicely.
Same opinion. It just feels off. Why use `fun` for function declarations instead of func or function? Dropping () before { makes it hard to tell what runs first. It feels like it's trying to be different for the sake of being different. I'm not able to quickly skim kotlin code like other 'C-like' languages and tell what is going on because it's trying to be too clever.
You're just not used to it.
https://steveklabnik.com/writing/the-language-strangeness-bu...
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)`).
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.
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.
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.
It’s not very good if you’re comparing it against Kotlin or Swift though.
It's a matter of taste, even just the swift example on this website makes me raise eyebrows.
I think that is valid because the syntax shown off here is controversial. However, I think Dart is just generally worse in almost all of its features.
It is great if you’re comparing it against Kotlin or Swift, unless you’re stuck in an era of 1.x Dart.
I would consider it to be weaker in power to both
Programming languages aren’t anime.
Eh, it's getting there, slowly at first but more rapidly now. It now got tearoffs, I explained in another comment but
> if you have an `enum Color { red, blue }` and a function takes `Color`, you can just do `f(.red)` not `f(Color.red)`
Dart is getting new features pretty fast, they really started focusing on the DX more after Dart 2 and now especially after Dart 3. Macros were supposed to ship but it was incompatible with the goals of fast compilation, so other sorts of smaller features will ship instead.
Big turnoff with Dart is the lack of json (de) serialization -- kind of shocking to have to resort to source code generation libraries in a modern language.
Also, statement based instead of expression based, and not immutable by default are kind of a drag; not the end of the world but a bit unpleasant, IMO.
Serialization support is coming, probably this year. As for statements vs expressions, it does have some expressions such as if and for inside lists but changing it wholesale to an expression based language would be too much of a breaking change.
Serialization support has been coming for years, I lost patience.
Otherwise, yes, some support for expressions, some support for immutability, no support for optional semi-colons, no privacy modifiers so "_" littered everywhere.
I just found it to be an exceedingly ugly language when I used it a couple of years ago. Yes, some more pleasant modern functionality has been bolted on since then, but it's unfortunate that Dart was chosen as the backing language for Flutter, which is an awesome mobile framework.
Serialization has always been possible via libraries, so most people were doing fine with that, what is coming is native serialization support, but in practice it will be functionally the same, ie rather than you running build_runner, the compiler will do it for you. I'm not sure what you used but that's what you were hung up on, there were always ways to solve it.
Dart is a pragmatic language, it has everything you need and has a lot of benefits too, such as sound null checking (very few languages have this, Rust comes to mind), JIT and AOT support (Javascript / TypeScript such as for React Native doesn't, and Kotlin is just getting there with Kotlin Native but it still has a lot of issues), and now more functional programming concepts with algebraic data types via sealed classes and pattern matching.
What language would you have chosen when Flutter came out circa a decade ago, or, we can be even more charitable and ask what language would you use today if you were to implement Flutter? I'm curious because everyone has their own ideas but they all don't work for one reason or another.
[dead]
I thought dart could natively deserialize via dart:convert? It just only decodes to lists and maps, you have to manually map into classes.
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)
> Dart feels like the before with no after, even though it got traction in the era of the Afters.
It's aged like the recent languages but feels clunkier like a language that's much much older.
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.
And I just checked the Dart release notes from all of 2025: https://dart.dev/resources/whats-new
Great progress! But smells a lot like the language I had it pegged for when "underscore as a wildcard" lands in February 2025, 2 years after pattern matching lands.
How did they ship pattern matching in 2023, with a million examples of how to do it right already hashed out and in the wild... and then not figure out a wildcard symbol for 2 years?
-
* Dart was awful, lost to Javascript because no one rated it highly enough to justify moving off Javascript, and was practically dead until Flutter dusted off the corpse and pivoted away from their browser goals... so super weird revisionism to act like we're talking about some beloved evergreen language.
> 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?
We shipped support for `_` as wildcards in patterns with Dart 3.0 when pattern matching first shipped.
However, prior to Dart 3.0, `_` was already a valid identifier (as it is in most other languages). The feature you're mentioning from last year was to remove support for uses of `_` as an identifier outside of patterns. This way `_` consistently behaves like a wildcard everywhere in the language. We didn't ship that in 3.0 because it's a breaking change and those are harder to roll out without causing a lot of user pain.
It's OK to not like Dart. There are multiple popular languages for a reason. But it is helpful when communicating about a language to others to be accurate so that they can make their own informed opinions.
You seem confused and indeed spreading FUD.
Dart wasn’t awful. It wasn’t adopted at the time because it had a distinct runtime that would require splitting web in two which nobody wanted. On top of that it gave Google too much power, because now they would control both runtime (V8) + language (Dart).
TypeScript won and became king because it was pretty much JS 2.0 instead of JS++ like Dart.
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.
I'm sure that's a really cozy idea, but doesn't pass the "common sense" test: a bit like your random misuse of the term FUD.
-
The simple reality is it wasn't very good, so no one was rushing to use it, and that limited how hard Google could push it. ES6 made Javascript good enough for the time being.
Dart 1.x had a weak type system, and Dart 2 was adding basics Kotlin already had almost 2 years earlier: that was also around the time I first crossed paths with Flutter, and honestly Flutter by itself was also pretty god awful since it was slowly reinventing native UI/UX from a canvas.
(It was a lot like Ionic: something you used when you had a captive user-base that literally couldn't pick a better product. Great for Google!)
> In 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.
"In my version of history"
It takes two seconds to find this if you weren't there when it happened. Google had a fork of Chromium with Dart VM called Dartium, it wasn't a matter of resources. Industry flipped Google off, plain and simple.
Educate yourself before making such claims, the decision to not adopt Dart wasn't because of its technical merits as a language.
The rest of your comment is just your opinion, so you do you. I'm not a Dart or Flutter devrel team to sell you their product.
I guess this is the Dunning-Kruger effect everyone talks about!
To understand just enough to regurgitate what happened, but miss why it happened... and then assume someone who's pointing at the much more relevant why is just plain wrong.
Because the why requires actually understanding of things like developer mindshare rather than regurgitating search results.
-
The hint I'll leave if you're willing to consider maybe you don't know everything ever... look at who's feedback is being promoted when Chrome wants to do obviously unpopular things on the web: https://github.com/webmachinelearning/prompt-api/blob/main/R...
https://github.com/mozilla/standards-positions/issues/1213
And model for yourself what happens if developer interest exceeds vendor refusal in magnitude, so Google just ships the thing, without a feature flag, to a massive percentage of the web-going world.
http://xahlee.info/comp/CoffeeScript_Dart_Javascript.html
Keep trying, though, if you believe hard enough you might rewrite history.
I guess you're not willing, or not capable? Either way, good luck: must be a hard way to live :)
Have you even used modern Dart?
The last time I looked at it was far less mature on non-Android platforms than Flutter. Has that changed?
Flutter has been abandoned by all the large companies - Google is throwing their weight in on KMP and has laid off the flutter teams.
This is completely incorrect. Large companies like Canonical are all in on Flutter even now, they're making it the default for desktop UI development in Ubuntu and are writing a lot of their own apps in Flutter.
The "layoffs" were not any of the core team, it was just an offshoring, of infrastructure devs at Google that happened to work on Flutter builds, to Europe where they rehired for the same positions there.
This is a large exaggeration. There are still a lot of people working on Flutter at Google and large companies continue to adopt it.
Google's wildly popular NotebookLM is a recently released Flutter app, for example.
I heard of the flutter layoffs, but my understand is that it was unrelated to KMP. fwiw google still uses flutter
Source?
> Google is throwing their weight in on KMP
Hahah.
Just straight up making shit up here. WTF are you talking about?
Google Workspace has been moving to KMP. They said at KotlinConf that it has replaced their decade-old transpiler from Java to ObjC, which is very impressive.
Yes this is because they are starting with a Java codebase and that obviously makes sense there.
You have other platforms like Google earth who when it was time for a proper rewrite went with flutter and dart along with a bunch of Google cloud stuff and Google Ads.
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.
Regarding KMP specifically, I didn't find it much use to only write business logic in one language, while still having to rewrite the UI up to 6 times (mobile, web, desktop), I'd rather have everything all in one.
Compose Multiplatform looks promising as it's Flutter-like in that it renders its own UI but it's still quite early, I know they say it's "stable" but when I used it, it really didn't seem so, plus the package support is extremely lacking compared to Flutter and of course the behemoth that is React (and Native)'s npm.
These days I'm looking forward to Dioxus, they're making their own native renderer similar to Flutter but especially for web, they are not doing the canvas trick, because they actually use plain HTML and CSS as their markup languages so they can compile directly to browser standards sites while still having a non-webview experience on mobile and desktop.
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.
And what exactly orchestrates the process of compilation (invoking Kotlin compiler + fetching dependencies)?
Whatever you want, really. The default just happens to be Gradle because that's the default on Android.
My point is that the fundamental difference between Flutter and KMP is not at all Gradle.
Last time I checked, Flutter was relying on messaging. KMP leverages FFIs. Flutter is a framework, KMP is not. If all you see is the command line you invoke to run the build, I think you're missing a lot.
React/Vue + TailwindCSS are now ready for building Flutter apps.
https://openwebf.com/en/blog/announcing-webf
React Native doesn't use Electron on mobile, it's a misconception. But it does depend on interpreted JavaScript on iOS and Android.
I mean on desktop
React Native doesn’t depend on Electron for desktop apps either. It renders using native UI components and don’t use a browser engine.
I know react native for windows is a thing, but is it on par with electron these days? my understand is that it was way beyond, but I could def be wrong
The bigger hit than performance is usually user experience quality and “write once debug everywhere”.
true - though I don't think that's inherent, more just the mentality of one who might pursue this.
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 will be rendered without a webview, so you get all the benefits of each platform.