Adobe products (both the Creative Suite, and their Flex Builder environment for Flash app) had their own design system that felt foreign on every platform it shipped on. If you wanted something that felt native, you had to reimplement e.g. Apple Aqua in Flash yourself.

Flutter goes out of its way to do that work for you, aiming for a "Cupertino" theme that looks-and-feels pixel-perfect on iOS.

React Native tries to delegate to platform primitives for complex widgets, so scroll views still feel like Apple's when on Apple's platform.

Just about every top-level comment here is talking about that in one way or another; yet the blog post doesn't mention it at all.

It's possible that Apple/Swift's mindshare among developers will lead to a significant number of apps shipping the Swift version for Android even if it means using Apple's UI, simply because they can't be bothered to make something bespoke for Android. Then again, Apple takes so much pride in its design language that it might not be willing to implement anything that feels good on a platform they don't own. If they were to ship an API-compatible widget toolkit, it might e.g. use intentionally bad spring physics to remind you you aren't on an iPhone.

I wonder how big the community part of this is. Is this an open source project of non-Apple people who are trying to break Apple's platform out of its walled garden? Is a lot of it funded by Apple? Ultimately, that's going to shape a lot of how this plays out.

I've been toying around with multiplatform frameworks like RN and Flutter for a side project of mine but they never feel right. I'd rather use the native UI per platform and have a nice way to share business logic. KMP exists but I think for most developers wanting to build an app it's more common to build for iOS first, and then port to Android later if the app gets traction. With a little foresight of keeping shared code in a Swift Package, it seems like that's getting more and more possible which is great to see.

I have an existing Swift / SwiftUI app that I am looking to port to Android, and have been not wanting to move to React Native.

It is a shame because aesthetically Swift is easily the nicest of the modern safe languages, but there have been really odd noises in the community about project leadership that sour things.

"You got Swift in my Android."

How miserable it would be trying to write Java or kotlin targeting iOS apps. I think this will be the same.

Just use the native tools and languages for the platform. Swift/Objc/xcode for iOS. Java/Kotlin/Android Studio for Android.

You will be so much happier.

What makes sense to share is complex libraries, and usually I have been doing that with C/C++/Rust libraries. But it means that the team now deals with Kotlin, Swift and one (or more) of those "sharing" languages.

What I believe KMP and Swift for Android bring is that teams will be able to share libraries in Kotlin/Swift, so that they can keep writing in their preferred language without having to introduce C/C++/Rust.

I believe this approach is vastly superior to any kind of framework that tries to share the UI. Mobile devs, in my experience, want to use the native tools: Kotlin for Android and Swift for iOS.

Swift SDK's are a way for anyone to support any platform, as proven by the Android guys doing it on their own. There are also SDK's for Linux, wasm, and embedded (and soon, windows?). So long as you play by SDK rules, Apple won't stop you from porting Swift to a new platform, even on competitive platforms like Android.

(The inter-op story with the JVM languages is still being written; it reduces to either the C/C++ FFI or the two incomplete duals of Java's legacy JNI and newer FFI/Memory interfaces. Prototypes work fine when the semantics are the same, but beyond that, there be dragons. Cross-platform UI frameworks are similarly (and likely eternally) afflicted with bright and dark spots.)

My app [0] uses a lot of metal shader code - I'm guessing there's no easy way to bring that across?

[0] https://apps.apple.com/app/apple-store/id1545223887

BUT beyond cross‑platform hype there's a practical question... what developer tooling will look like... Are we getting first‑class debugging, package management, continuous integration for Android targets...

ALSO adoption often comes down to licensing and governance... open SDKs thrive when the steering group is transparent and responsive...

And it's worth remembering that bridging two ecosystems isn't just about code... it's about aligning design idioms, APIs and expectations... Without that you end up with uncanny valley apps...

I've found a few things in the process: 1.) Neither RN nor Flutter seems to be able to create truly native applications on iOS. I've never once seen an application made in either of them and thought it was a native iOS application. 2.) Unless your application must support both platforms, android (in an economic sense) is dead weight. I was shocked to see how bafflingly little android users contributed to our revenue. I've heard this from people in other companies as well. 3.) SwiftUI (and I assume UIKit) makes it really simple to create apps according to HiG. You can feel yourself fighting the framework whenever you deviate from what Apple wants you to do. I actually think this is a good thing.

I think Apple is doing something really smart here. They're not making SwiftUI cross platform, they're making it possible for you to re-use your business logic from your SwiftUI apps in Android apps.

The way see I see it they're saying — if you want to spend the least amount of time possible building a cross platform app use Flutter or RN. If you want to create a truly native experience on both platforms, but still re-use your core business logic, Swift is your friend.

Does anyone know/understand what's the story for using Swift's interop with c++ on Android? Should this work right now? How?

Really!!! Would love to know more how that statement is true. I could not find any resources to support that claim

What does it add to the linked "swift-java project" then at all, perhaps some lifetime events and a sort of batteries-included standard library?

That's... not encouraging.

Is Swift now going to be the de facto language for Mobile (and maybe Desktop) development?