Swift on Android: Full Native App Development Now Possible
docs.swifdroid.com
docs.swifdroid.com
Under the hood, projects are powered by SwifDroid, a framework I built that handles the Android application lifecycle, activities, fragments, and UI widgets (Android, AndroidX, Material, Flexbox) while automatically managing Gradle dependencies. The IDE compiles Swift, generates a full Android project ready for Android Studio.
This is the first public release. Both tooling and framework are open-source and MIT-licensed.
(we're trying to do something very similar with Rust instead of Swift)
On top of that, the IDE also auto-generates required Java/Kotlin classes on the fly, for example, for Activities.
I was looking into something similar, on Flutter it uses FFIgen and JNIgen, might be something to look into on the Rust side. From what I've seen, it's quite difficult from pure Kotlin to Rust, as I was looking for the equivalent of the flutter_rust_bridge package when experimenting with Compose Multiplatform, as I have some crates I need to use, but I ultimately gave up because it was not straightforward at all.
Then the questions is: roughly what percentage of Kotlin or Flutter apps could be writable in Swift? Today and next year?
Also, given <waves hands at everything>, I’d never consider becoming even more dependent on some big bad corp. And even if one is to put that aside somehow, Swift is a painful language … would be such a self own to have to use it even in places you’re not forced to.
Also picture this. Every time you run swift build, you get a mental image of Cook dining with Trump. It's very hard to stay focused and creative in that ecosystem rn.
Weird how Tim Cook gets so much hate, when the rest of them didn't. He didn't say anything notable except a bit of ring-kissing: "I want to thank you for setting the tone such that we can make a major investment ..."
Then Sergey Brin starts talking about how he's happy about Trump pressuring Maduro:
You're applying a lot of pressure to Maduro and I think that's phenomenal for an American president to actually be applying pressure there uh in Venezuela and then hopefully in Cuba and so forth. So there's a lot of um civil rights work that you're leading. we didn't get a chance to mention. Um I also just wanted to mention um we don't have to get into all the uh details talked about in the Oval Office, but uh I think it's a real incredible inflection point right now in AI and the fact that your administration uh is uh supporting our companies instead of fighting with them."
So, reading between the lines a little, i.e. Google looking depose dictators and burn lots of oil to keep their AI slop churning is totally fine:
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.
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.
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.
One of the most revered programmers in my circle, who's been coding since the early 1970's asked me once, "how many programming languages do you know?". I started rattling off a few, and he stopped me. He said "I only really know the last 2 languages I used".
Jack of all trades, master of none. If someone asked me to code in PHP, Perl or any of the dozens of languages I've used in the past today, just no way. No thank you. Yeah, I used to be very proficient with lots of languages, but no way am I going dust off those brain cells. Assembly is probably the only language I can really get into on different platforms without a huge cognitive context switch, because it's just straight forward, no kooky abstractions.
That said, I've used Javascript for front-end, back-end as well as database (mongo), and it was absolutely great to not have to context switch constantly. I've also done lots of different systems with a wide variety of other languages glued together, and it hasn't been as effortless as using one language for everything. YMMV.
I do agree a lot of people over estimate how much they know, but I work with multiple people who know at least 5 languages well.
For me myself, only counting things I’ve shipped at scale, I’d know C, C++, Swift, JavaScript, Python, Rust, MSL, HLSL, GLSL, MEL. There’s enough in common between them that I think it’s quite doable.
Every language has thousands of papercuts. It is hard to know many languages proficiently beyond surface syntax level, period.
> I’d know C, C++, Swift, JavaScript, Python, Rust, MSL, HLSL, GLSL, MEL
Shipped !== know. I've touched dozens of languages over my career and every time I've had my ass kicked by some esoteric knowledge of specific quirk in std of %lang%. We have a different definition of "know".
You initially said beyond a surface level and now you’re talking about esoteric quirks.
Pick one. 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.
This was indeed my point from the start.
Is there a language you’d feel comfortable saying you know every single aspect of, without exception? Down to every compiler and implementation quirk?
It is common practice to be thrown at random projects regardless of the programming project.
What is valued is the soft skills, and the ability to swim when thrown into the cold water, no matter how.
Yes it kind of sucks, however the Pandora box is long open and only an implosion of the capitalist enterprise culture would fix it.
Contrary to product companies you also get to jump technologies without having an HR department sending the application into the garbage because one doesn't tick all the boxes on a specific stack.
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).
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).
It still might be, as Kotlin isn't used on the lower layers below JetPack libraries, despite Google's resistance to modern Java adoption.
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.
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++.
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.
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?
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.
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.
Gradle can be a pain, but if I look at what our neighbors at the iOS team experience (constantly having to manually merge project files, not being able to simply import some libraries, ...) it's hardly a nightmare.
Specifically adding dependencies is super easy? Just specify which repo they're in (mavenCentral or Google or whatever) and add dependencies under "dependencies". When running or syncing, Gradle does the rest.
I find that IntelliJ IDEs are fine, but not nearly as amazing as they're often hyped up to be, and similarly while Xcode has problems it's not nearly as bad as is often claimed.
My experience is somewhat colored by Android Studio and JVM ecosystem stuff like gradle and proguard though, which have been more cumulative pain for me than anything Apple-side in a long time (Cocoapods was pretty gnarly but SwiftPM has fixed that).
It allows you to easily install and maintain several versions of Xcode (beta / RC versions).
And, more importantly, uses aria2 for HTTP download, which has resumability.
Xcode is so sluggish it's slower than an electron app despite being native, the xcode app upload is so broken even Apple released a third party tool to bypass their own IDE and its undocumented config files look like from the 90s and do not work well with git.
The UI is sort of okay but that's not going to cut it. You can feel the decades of cruft in this IDE, it feel like using Borland.
> Xcode is the worse IDE I ever used
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.
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.
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.
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.
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.
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.
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.
- 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?
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...
The good ideas of Flutter, IMHO, got implemented in native Android (Kotlin + Compose).
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.
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 :-).
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.
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.
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?
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.
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
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
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.
I haven't touched flutter in two years, but isn't getX a kitchen sink library disliked by everyone?
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?
There's been a trend of improved DX for languages used in app development:
ObjC -> Swift
Java -> Kotlin
Javascript -> Typescript
...Dart feels like the before with no after, even though it got traction in the era of the Afters.
> if you have an `enum Color { red, blue }` and a function takes `Color`, you can just do `f(.red)` not `f(Color.red)`
Dart is getting new features pretty fast, they really started focusing on the DX more after Dart 2 and now especially after Dart 3. Macros were supposed to ship but it was incompatible with the goals of fast compilation, so other sorts of smaller features will ship instead.
Also, statement based instead of expression based, and not immutable by default are kind of a drag; not the end of the world but a bit unpleasant, IMO.
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.
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.
It's aged like the recent languages but feels clunkier like a language that's much much older.
And I just checked the Dart release notes from all of 2025: https://dart.dev/resources/whats-new
Great progress! But smells a lot like the language I had it pegged for when "underscore as a wildcard" lands in February 2025, 2 years after pattern matching lands.
How did they ship pattern matching in 2023, with a million examples of how to do it right already hashed out and in the wild... and then not figure out a wildcard symbol for 2 years?
-
* Dart was awful, lost to Javascript because no one rated it highly enough to justify moving off Javascript, and was practically dead until Flutter dusted off the corpse and pivoted away from their browser goals... so super weird revisionism to act like we're talking about some beloved evergreen language.
Dart wasn’t awful. It wasn’t adopted at the time because it had a distinct runtime that would require splitting web in two which nobody wanted. On top of that it gave Google too much power, because now they would control both runtime (V8) + language (Dart).
TypeScript won and became king because it was pretty much JS 2.0 instead of JS++ like Dart.
I'm sure that's a really cozy idea, but doesn't pass the "common sense" test: a bit like your random misuse of the term FUD.
-
The simple reality is it wasn't very good, so no one was rushing to use it, and that limited how hard Google could push it. ES6 made Javascript good enough for the time being.
Dart 1.x had a weak type system, and Dart 2 was adding basics Kotlin already had almost 2 years earlier: that was also around the time I first crossed paths with Flutter, and honestly Flutter by itself was also pretty god awful since it was slowly reinventing native UI/UX from a canvas.
(It was a lot like Ionic: something you used when you had a captive user-base that literally couldn't pick a better product. Great for Google!)
"In my version of history"
It takes two seconds to find this if you weren't there when it happened. Google had a fork of Chromium with Dart VM called Dartium, it wasn't a matter of resources. Industry flipped Google off, plain and simple.
Educate yourself before making such claims, the decision to not adopt Dart wasn't because of its technical merits as a language.
The rest of your comment is just your opinion, so you do you. I'm not a Dart or Flutter devrel team to sell you their product.
To understand just enough to regurgitate what happened, but miss why it happened... and then assume someone who's pointing at the much more relevant why is just plain wrong.
Because the why requires actually understanding of things like developer mindshare rather than regurgitating search results.
-
The hint I'll leave if you're willing to consider maybe you don't know everything ever... look at who's feedback is being promoted when Chrome wants to do obviously unpopular things on the web: https://github.com/webmachinelearning/prompt-api/blob/main/R...
https://github.com/mozilla/standards-positions/issues/1213
And model for yourself what happens if developer interest exceeds vendor refusal in magnitude, so Google just ships the thing, without a feature flag, to a massive percentage of the web-going world.
Keep trying, though, if you believe hard enough you might rewrite history.
We shipped support for `_` as wildcards in patterns with Dart 3.0 when pattern matching first shipped.
However, prior to Dart 3.0, `_` was already a valid identifier (as it is in most other languages). The feature you're mentioning from last year was to remove support for uses of `_` as an identifier outside of patterns. This way `_` consistently behaves like a wildcard everywhere in the language. We didn't ship that in 3.0 because it's a breaking change and those are harder to roll out without causing a lot of user pain.
It's OK to not like Dart. There are multiple popular languages for a reason. But it is helpful when communicating about a language to others to be accurate so that they can make their own informed opinions.
It also inherits all of the bad parts of the JVM. Crappy build tooling (gradle), and then the slow startup and high memory usage.
Currently Kotlin is far and away my favorite language but I also haven't looked into the newer languages recently and am interested in hearing pain points people have. Especially if it isn't annoyances with Gradle
There's also things like Swift's guard statements that can help make intent clearer and read a bit more nicely.
The main thing though is that Dart has pub.dev and a CLI that makes it extremely easy to add packages, via `dart pub add`. If I do want to go more of a functional route I'll just use Rust instead, it has all of what Kotlin has and more, plus a similar streamlined package management as Dart in the form of `cargo add`.
Google's wildly popular NotebookLM is a recently released Flutter app, for example.
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.
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.
> Google is throwing their weight in on KMP
Hahah.
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.
And what exactly orchestrates the process of compilation (invoking Kotlin compiler + fetching dependencies)?
My point is that the fundamental difference between Flutter and KMP is not at all Gradle.
Last time I checked, Flutter was relying on messaging. KMP leverages FFIs. Flutter is a framework, KMP is not. If all you see is the command line you invoke to run the build, I think you're missing a lot.
Flutter is still bad on iOS and macOS. No Liquid Glass (except some weird hack attempts that look and behave badly). Liquid Glass isn't an optional decoration, it's the name of the new system-wide UI. Leaving it out of your app is like committing to iOS 6-era skeuomorphic design after iOS 7.
Edit: Several cross-platforms frameworks can do Liquid Glass:
- SwiftUI by using Skip for Android
- SwiftCrossUI
- React Native
I'm glad to see that I can finally target iOS as the first-class citizen, using Apple technologies, and then run that code on other platforms. Instead of having to use frameworks that treat iOS as secondary when it is by far the biggest money-maker for most apps.
No cross platform stack can do Liquid Glass yet. You have to wonder if that was one of design goals.
This is pretty funny because you just listed SwiftUI three times but in different configurations. They're not truly cross platform, they just wrap Apple's native design code. In contrast, I can (and do) use a package like liquid_glass_renderer to get Liquid Glass everywhere, on all my devices, with one codebase.
Maybe it will get there... Meanwhile I would rather use technologies that provide the full experience on the platform where it matters, and would never want those liquid components on platforms like Android or Windows anyway.
> and would never want those liquid components on platforms like Android or Windows anyway.
That's where we disagree then, I like the design itself but don't like it stuck on only one platform. I make apps with wholly custom UI designs, not following any particular OS' "native" design, and that's why Flutter is so powerful, because I am not constrained to what pixels I can render to a screen, nor should I be.
Of course it’s optional. Some of the most popular apps on the planet ignore the local UI conventions of their parent OSes entirely.
TikTok is a Flutter app. It looks identical on iOS and Android. It uses basically no native UI elements.
It’s a pretty well-known strategy to create apps that look identical on all platforms so that you lessen your customer confusion and your support burden. The fact that Spotify, Facebook, Uber, and Reddit look exactly the same no matter what platform you’re on is more important than complying with OS design guidelines and UI elements.
And I hate every one of those apps (well, back when I used Facebook, years ago, I did), because they’re just bad iOS citizens. I, as most iOS users do, don’t care what apps look on Android. For Android users, it’s the same with iOS. Making shitty cross platform apps is all about branding and saving some money for developers, nothing about the users.
What does “bad iOS citizen” even mean?
It’s not even about saving money for developers, it’s about the fact that your users expect a consistent experience.
Imagine if you watched an NFL game 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).
1. Spotify, Uber etc are popular because of their product, not the pure quality of their apps. People use Uber because they want to cheaply get somewhere, and Spotify cause that’s there all their shared playlists are.
2. People buy whatever tv is on sale when their old one breaks, but the vast majority will stay with their phone platform, so couldn’t care less what their apps look on the other platforms out there.
So, native experience does matter, but obviously only as one of multiple deciding factors.
> What does “bad iOS citizen” even mean?
Doesn’t look like native apps, doesn’t feel like native apps (come on, most multi platform frameworks don’t even get the scrolling right, one of the most basic forms of interaction), doesn’t use all of the platforms features to their fullest, as applicable for the type of app.
But it really doesn’t matter either way. The point is that TikTok doesn’t follow any OS conventions.
Disclaimer: I have seen teams writing mobile apps in Qt, and it was systematically a lot slower to develop, with a lot of pain, and resulting in worse apps. Even if you only have C++ devs, I would argue that it may be worth giving them the time to learn a modern language and write the mobile app with it.
I'd love if you could also contact me (my socials are in my profile) as I'm developing a set of components to help exactly in that situation.
They were developing non-trivial mobile apps. The kind where you use your fingers on a touch screen, but that are more complex than just showing a text and an image. Say Google Maps, or WhatsApp.
The problem was not the lack of components: the problem was that it was C++. C++ is more complex to write correctly than Swift or Kotlin and harder to debug. Which made those teams measurably a lot slower. It's just the wrong technology for the use-case, IMO.
> in C++ you can write performant code
This almost certainly does not matter for a mobile app, and definitely not for the UI part. In case your app has to do something that may need C++ (e.g. computer vision), then you can just call a C++ library over FFI.
> C++ isn't that complicated these days
I didn't mean that it is complicated. I can totally write C++. What I meant is that it is more complicated to get it right than modern languages. If users complain about a segmentation fault, it's often pretty tricky to debug. In Java/Kotlin, you will get an exception that tells you exactly which line crashed.
On top of that, C++ is slower to write. Again I have been able to compare teams working on the same app both in C++ and in Java/Kotlin/Swift (Java is not exactly a modern language, but still it's a lot faster to develop with).
And after all those disadvantages of using C++ for a mobile app, you end up with a UI that doesn't feel native to the platform.
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.
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.
Both Kotlin and Swift are compiled.
> But this is just the standard I set to myself - the entire industry clearly has different priorities.
I think you just underestimate the performance of Java/Kotlin/Swift, languages that you admitted you don't have any experience with.
> tho with good debugging tools and LLMs I have found this to not be a problem anymore
Again: try modern languages with good debugging tools and LLMs :-). I think your bias is that this is all you know.
> because I've proven that it is fixable by caring about UI/UX
It requires care, which means more effort. All that for being at best similar to the native tools, but probably never exactly the same. And it cannot be better, because the native ones are the ones defining how it should be.
> I can't stretch how FUN, easy, and overall a great experience to develop with QML and C++ together, it's just HOW GUI should always been
But you said you don't have experience with the native Android/iOS way. I personally have used QML/C++, Flutter, Android (Java/Kotlin, the old XML way and the new Compose way) and SwiftUI. QML/C++ is by very far the worst.
I would advise that you try either Kotlin/Compose or Swift/SwiftUI to get an idea. You can still use C++ to share some code (say you write a complex library in C++, no need to rewrite it in Kotlin and Swift), but starting a new mobile UI with QML these days is just madness IMHO :-).
I only said that because you said performant code "does not matter for a mobile app". I think writing apps in native frameworks is awesome! I'm all for it. BTW, I've heard some reports that SwiftUI/Swift are slow[1][2][3]. Again, I haven't explored SwiftUI and Kotlin, but I'd like some day. What do you love about them so much?
> All that for being at best similar to the native tools, but probably never exactly the same. And it cannot be better, because the native ones are the ones defining how it should be.
I agree, the best apps would almost always be those written in the framework the OS provides - kinda make sense - cross platform GUIs will always fall under the lowest common denominator issue - I've written about it in my blog post[4]. You also forget tho, that Linux does exist with a growing popularity - I think it's important to target it as well (I've started GUI development because I was on Linux and most apps had horrible UI/UX).
> but starting a new mobile UI with QML these days is just madness IMHO :-)
Follow my mad adventure (:
[1] https://notes.alinpanaitiu.com/SwiftUI%20is%20convenient,%20...
[2] https://x.com/daniel_nguyenx/status/1734495508746702936
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 :-).
You said you "hope good desktop GUIs will come eventually, because I absolutely hate the web-based stuff like Electron.", so I guess you still might need to use those. I'm with you, and I'm trying to be part of the change. To be honest, I'm not very much tied to a specific programming language. If the end result is good - stable, performant, with good DX than I'm with it. For me, the current combo works. I'm willing to adapt tho. Slint has nice QML syntax for UI and logic (and the underlying framework) is written in Rust. Its author was once The Qt Company/Nokia developer if I'm not mistaken.
Yeah, stuff like Slack for work. But there it's a bit different: they chose Electron because it makes them more productive even though it ends up in a worse product. It's sad, but it is rational to produce crap that makes more money.
That would be a reason to use React for a mobile app, maybe. But writing a mobile app in Qt is not more productive :-). I am very convinced it costs more money and results in a worse product.
Hope to prove you wrong soon (:
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.