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?

Interestinggg. How does binding Java/Kotlin code into Swift work?

(we're trying to do something very similar with Rust instead of Swift)

Congrats, I've definitely been looking to just centralize with Swift. Great work!

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).

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.

>Knowing two languages isn’t all that bad. Most developers learn many languages during their careers and switch between them without a thought.

One of the most revered programmers in my circle, who's been coding since the early 1970's asked me once, "how many programming languages do you know?". I started rattling off a few, and he stopped me. He said "I only really know the last 2 languages I used".

Jack of all trades, master of none. If someone asked me to code in PHP, Perl or any of the dozens of languages I've used in the past today, just no way. No thank you. Yeah, I used to be very proficient with lots of languages, but no way am I going dust off those brain cells. Assembly is probably the only language I can really get into on different platforms without a huge cognitive context switch, because it's just straight forward, no kooky abstractions.

That said, I've used Javascript for front-end, back-end as well as database (mongo), and it was absolutely great to not have to context switch constantly. I've also done lots of different systems with a wide variety of other languages glued together, and it hasn't been as effortless as using one language for everything. YMMV.

Knowing two or more languages is kind of liberating even. People love shiny but there are no shortcuts in this case.

Also, given <waves hands at everything>, I’d never consider becoming even more dependent on some big bad corp. And even if one is to put that aside somehow, Swift is a painful language … would be such a self own to have to use it even in places you’re not forced to.

Which is what we're doing. The moment your app isn't some webview react crap and start using any non basic (or even basic) features you end up with two codebases. For example, anything using foreground services or requiring runtime permissions.

The only framework i found that really bridges the gap is B4X, but you still need to have two separate projects, because of services, and #if blocks for the things the framework doesn't abstract (which, to be frank, is really just advanced uses of peripherals and libraries)

The two OS' are just so fundamentally different.

The reverse -- building for iOS in Kotlin -- is an interesting option that on the surface appears to be a best of both worlds.

You get (1) access to JVM APIs as normal on Android, and (2) Fairly full-featured interop with ObjC, Swift and C APIs elsewhere, and (3) A pleasant language with excellent IDE support in IntelliJ.

The `expect fun` / `actual fun` stubbing for different platforms also works in a fairly low-drama way. You can also share UI with Compose Multiplatform (less mature), or just write native views.

The downside (of course) is that non-JVM targets like iOS can't use the JVM ecosystem, and most of the Kotlin ecosystem assumes Kotlin/JVM. This is slowly changing though, and isn't a structural flaw.

Also, you're going to end up with Gradle in your toolchain, which will torture your poor soul.

The fun part is that now you need to bind against swift and objective-c for success on Apple systems. They no longer provide obj-c frameworks for all the new things. So you have to double hop and deal with both or deal with it on a framework by framework level. Talking from a Unity background here where the interop with obj-c is kinda smooth due to the c# -> c marshaling. But swift needs a bit more work.

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.

Touching xcode to avoid touching Android is like touching concentrated hydrochloric acid to avoid breathing a fart

And Gradle? Does skip the Gradle and that nightmare of a dependency management and handling?

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 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...

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...

> 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.

Thanks

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

Shameless self promotion. Account created 5 minutes ago, 0 karma.

Dead link

> 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?

> 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?

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.

Apple is abandoning Swift on Android?

I think you are confused with Objective-C.

That’s one I haven’t heard yet, do elaborate

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

> 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.

Qt/QML can do all those targets as well (although it is admittedly jankier on mobile than Flutter or Swift would be).

I find Kotlin Multiplatform to be far and away a better experience than flutter

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.

The bigger hit than performance is usually user experience quality and “write once debug everywhere”.

There is also Dioxus