> The most important question for every cross platform framework is what happens to the UI?

I kindly disagree. The first feature I want from a cross-platform framework is that it lets me write a native UI. That's why I like KMP: I can just share a framework with an iOS app built with SwiftUI.

Sharing business logic makes a lot of sense in a ton of cases and has been done forever (C/C++/Rust/Go libraries, etc). Sharing UI in complex apps, in my experience, always ends up being a "write once - debug everywhere" nightmare.

What KMP (and I'm hoping Swift for Android) bring is the possibility to share a Kotlin (respectively Swift) library instead of sharing code with C/C++/Rust/Go. So that an Android/iOS team can keep using Android/Swift without having to introduce a third language for sharing logic.

It's worth noting that this doesn't add any expectations for how your UI is built. The example shown in the screenshot continues to use Jetpack Compose (Android's native UI) with Kotlin invoking Swift business logic. You can also use other UI frameworks on Android, of course, including some that are written in Swift.

One nice thing about this implementation is that it shares many of the same characteristics as Swift on other platforms: unlike some common alternatives, it's not garbage collected but uses reference counting; it uses the same underlying libraries, concurrency primitives and memory model.

Excited to see how folk use it... it's technology that will hopefully springboard some other interesting innovations.

[Disclosure: I work on developer tools and frameworks at Apple.]

The Swift SDK for Android doesn't specify or mandate any user-interface technology, but leaves it open for other projects to build upon. For example, Skip.tools re-implements SwiftUI for Android by bridging it to Jetpack Compose, so you can use the same codebase for both your business logic as well as UI layer.

We write about it at https://skip.tools/blog/fully-native-android-swift-apps/ and an example of an app on the Play Store that demonstrates this is the Skip Showcase app: https://skip.tools/docs/samples/skipapp-showcase-fuse/

[Disclaimer: I work on the Skip product, and I am also a founding member of the Swift Android Workgroup and am the release manager for the Swift SDK for Android]

The Browser Company did an amazing job of porting SwiftUI to Windows, where the element primitives in the language map to native Windows UI C++ classes under the hood.

Perhaps the future of Swift for Android is similar, where SwiftUI will map to Jetpack elements. That would be cool.

Remember on iOS and MacOS, SwiftUI is not "native". It's a description language that system frameworks interpret and create NSViews and UIViews and CGLayers etc out of.

> 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

It doesn’t sound like this release includes bringing SwiftUI or UIKit to android, so unless you did a ton of work to replicate it (ala flutter) using Apple’s UI on android probably still isn’t really possible.

Didn’t Flutter decide not to support Liquid Glass, because it’ll be too much work?

i think traditional UI should be decoupled from the language - only providing CLI and web UI (w3c web standards).

Apple's ui is very nice, but you're stuck with a whole ecosystem for life. If you want to cross-platform, as you mentioned, well, all hell breaks loose: React & co, Flutter, web assembly.

a unified, all-batteries-included system is excellent for the manufacturer/provider - they can plan, invest, manage and rollout products at a desired rate. but for developers, third-party, and consumers is very costly, intense and risky.

fun-fact from Steve Jobs bio, he was interviewing a tech hopeful for a job, the guy showed him a prototype of what would become the Dock (aqua + animations), created using an Adobe product. Abobe etc had powerful, flexible platforms - unfortunately the market was driven by eager tech geeks - so it was easy to get curried away with fancy UIs. However, that was (20 years ago) an educational issue - not a tech issue.

Huh? Did you read the link? Did you notice the ONE screenshot clearly shows the app has a material-ui look.

I'm going to say this because I think you might not know this, but also because I think many others might not have thought about this:

Almost always, a programming language is UI agnostic. Swift SDK for Android means: You can now write Android Apps in Swift. This doesn't magically include Apple's components / SwiftUI. When you write code for a platform, specifically an SDK for an OS, all you do is expose that platform to that language.

So, as long the SDK/bindings are there, a new "Window" means whatever a the OS thinks is a Window. A Button is what is defined (or exposed/binded to) as a Button in Android.

Swift was sorta released for Windows: a new Window looks like a generic Win32 Window. The same one you would get if you used C, C++, Rust, etc..

All your examples are GREAT examples to explain how this works: - Flutter has "Cupertino" to allow people to use Flutter to make Apple apps, and not have to learn names/methods/interface of the native Apple UI. - React Native: A LOT of work was put in to make/bind Apple native objects to a React component. And the same for Android.

So again:

The Swift SDK for Android means you can write your Android apps in Swift. The same apps you might of wrote in Java or Kotlin, you can now use Swift. Meaning whatever it looked like in Java/Kotlin (using native api's), it would look like in Swift.

The SwiftUI, Apple's component library written/exposed to Swift, is something completely different.

> The most important question for every cross platform framework is what happens to the UI?

They don't give a fsck. Compare Windows, Adobe, Apple, Google products from 10 years ago with the present ones.

Looks like this is package compatibility, not a cross-platform UI system (although maybe that’s in the works. SwiftUI could probably port well).

Think of this more like Kotlin Multi Platform. Shared logic, not UI.

Very unpopular opinion but i like apps that ashew looking “native” for an original ux. Maybe it is my love for gamedev and all the crazy designs they come up with but i personally loath boring uninspired native apps esp when the native ux is terrible.

Apple wants everyone to conform because historically their ux is on point but the last update really reinforces my view.

Nobody cares about native UI, not even Apple, the strength of a UI toolkit is to empower creative design while retaining consistency and intuitiveness across devices

Only the UX has to feel native, the pixels are yours

> The most important question for every cross platform framework is what happens to the UI?

For that, there needs to be a single definitive agreement on UI somewhere.

Like what does it mean to be a "list"? How does it behave with mouse, touch, keyboard?

How many different kinds of lists? (for example, a list for "favorites" behaves slightly differently than a list for "bookmarks", vs lists of "products/offers" and so on)

I bet any example you can give I or others can nitpick some flaws in that.

Hell, there are differences of opinion right off the bat: Should content move up when I scroll/swipe down or move down when I scroll up?

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

Is it? There seem to be a hundred million Java developers out there, that can do an Android app, plus even release that in-house or with minimal registration fees if single dev/sideproject.

For Objective-C/Swift, there seem to be ten percent as many devs.

I always only tinkered with Android apps in my spare time, but never managed to deploy anything to iOS.

Also, outside the US, iPhones are a 10 % niche product in private hands, but companies might use a lot of iPads or provide iPhones as work phones, so perhaps companies do think of both platforms as second class citizens (behind windows/browser as two other "OS-like" primary platforms)

> KMP exists but I think for most developers wanting to build an app it's more common to build for iOS first

This sounds US-centric to me.

The advantage of KMP is that it is pretty mature and it is used in big apps like Google workspace (Google Docs etc), so it feels like it may be in a really good position.

I used to be exited about Flutter when it started, but the speed of major releases (by the time I had rewritten my app for Flutter 2, Flutter 3 was out, or something like that) and it did not seem to get so much traction (Dart is fun, but well).

KMP builds on top of Kotlin, with big investment from JetBrains and Google. That looks extremely promising to me.

I think business-logic-in-JavaScript is something cross-platform folks shouldn't snooze on either, with the usual caveats of not doing anything performance-critical or where an asynchronous API would be awkward (to be clear, using JavaScriptCore or QuickJS or the like, not just running in a WebView)

But it'll run on iOS (v7.0+), Android (I think more recently) and of course web and server-side. And most importantly, it's hot-reloadable, as long as you don't run afoul of platform gatekeepers (i.e. use it for bug fixes and minor behavior changes, not like whole new features).

One of the frustrating things about mobile development is that once you ship a version, that version will almost certainly be running on at least someone's device indefinitely without being upgraded. My day job is even on step further back in that we have to get our customers to update the version of our SDK that they're integrating (which for many of them means contracting out because they don't have an in-house mobile dev team), before they ship an app update, which then needs to be installed by end-users, whose device might not even support the new deployment target…

(I've been trying to sell this to the bosses for the last 9 years or so, and never gotten the go-ahead, so there could be aspects I'm missing, but it always seemed like a huge missed opportunity).

At Proton they use Rust for shared logic (their claim is more than 80% of the codebase iirc), and platform specifics for the rest.

This is already possible with .NET and MvvmCross: a shared core library plus native UI projects for each platform. UIKit feels great in C# and it’s all been working quite well since Xamarin times, with access to the Nuget ecosystem.

react native do uses native UI per platform in contrast to flutter or compose multiplatform. React Native improved a lot - it's not the same technology that has been 5 years ago. Especially this year there were plenty of improvements also regarding speed but in react native and community plugins (new architecture rolled in, react compiler, hermes v1, nitro modules, flash list v2, legend list, react native skia, react native webgpu, expo use dom) Tooling in JS/TS ecosystem also improved a lot.

Yes, Skip has been using our preview release of the Swift SDK for Android in our Fuse mode for over a year, and it has proven to be very popular! You can see our blog post about using it to build a completely native SwiftUI app for Android at https://skip.tools/blog/fully-native-android-swift-apps/

To clarify a couple of other comments about transpilation vs. compilation, Skip has two modes: Skip Lite, whereby your Swift code is transpiled into Kotlin, and Skip Fuse, whereby Swift is compiled natively for Android using the Swift SDK. Skip Fuse and Skip Lite work side-by-side, where Skip Lite is used to provide bridged integration to many popular Kotlin frameworks on Android (Lottie, Firebase, Stripe, etc.). You can read about the comparison between the two modes at https://skip.tools/docs/status/ and see a subset of our available modules at https://skip.tools/docs/modules/

We are very excited that the Swift SDK for Android is now official and we can switch over from using our own preview build of the SDK to the officially supported one.

Yes, Skip is a major contributor to this effort!

You don't need to use the transpiler anymore. Skip added native Swift execution on Android recently. It has much greater compatibility than the transpiler (though they maintain both).

You can set the corner radius to whatever you like in Flutter, also the framework is quite fast, if an app doesn't respond to touches it's likely a poorly made app

I have no love for RN and Flutter, but what makes you think Swift on Android will be even remotely close to what Flutter and RN has?

If anything, Apple will launch this and quickly forget this exist.

> Please kill RN and Flutter already.

Just No. Nobody will kill >30% of apps on the iOS store. Flutter is simply a massively superior development experience overall compared to the horrifying disaster that is SwiftUI. SwiftUI is so utterly pathetic that more than a third of all apps are now being written in Flutter.

"The compiler is unable to type-check this expression in reasonable time" -> one of the most atrocious and common errors that increases cortisol levels and reduces life expectancy amongst mobile developers.

Please kill SwiftUI already. For the sake of Humanity.

> Swift embedded, for example, is a sort of proof of concept more than viable platform, and you end up battling that more than the problem you are trying to solve.

Yet Apple has managed to create WatchOS. I don’t know what is the portion of Swift, however.

guard let self = self else { return }

Perfectly delivered, the Reese's commercial that keeps on giving. Although to fully match the analogy, there'd need to be some form of Kotlin+swift hybrid with a crinkly wrapper.

Kotlin on iOS is statically compiled and interops with Swift/ObjC natively. Don't think KMP on iOS is even running a VM like Flutter has to with Dart?

https://kotlinlang.org/docs/native-overview.html

Do you build desktop apps, too, with Kotlin Multiplatform? How mature is it overall?

It'll take you thirty minutes to port the shaders with a modern LLM.

I am not joking. I have done this. Shaders are pretty simple. You'll have some weird artifacts but thats more because of platform differences than translation errors.

Metal cannot be used on Android. Your business logic can be ported - if it's separated as a library. If you don't want to separate it, Skip can handle bridging a lot of Apple libraries including SwiftUI.

Yeah I would also like to see SwiftUI but its apple ecosystem only.

When was the last time you tried react native? It’s pretty good now that they finally completed the transition to the New Architecture. With Expo it’s pretty nice these days.

Less necessary to be fluent nowadays with LLMs.

  > Are we getting first‑class debugging, package management, continuous integration for Android targets...

i'd love it if you could pull/push and build/debug changes to the shared code from android studio and build it all together there, that would reduce a huge amount of friction...

IMO the implementation (for me at least) is ... terrible. Why reach for this when it's, at the end of the day, just the exact same as NDK work in C++ but in Swift.

You have to use Kotlin / Other UI setup anyways (or their fully-native example, use OpenGL to draw the screen[0]), and on top of that statically assign the package path and class name in the Swift code, while making it an external func in the kotlin code[1]. You then also get to deal with the annoyances that come up with native libs.

kotlin side: /* * A native method that is implemented by the 'helloswift' native library, * which is packaged with this application. */ external fun stringFromSwift(): String

swift side: @_cdecl("Java_org_example_helloswift_MainActivity_stringFromSwift")

[0]: https://github.com/swiftlang/swift-android-examples/blob/mai...

[1]: https://github.com/swiftlang/swift-android-examples/tree/mai...

> Can I now build my app in Xcode with an Android target and use that binary in the Play Store?

No. The vision document[1] lays out the direction of travel. Currently the focus is on shared business logic and libraries, rather than full native applications (although that's certainly a goal, albeit a very long term one).

[1]: https://github.com/swiftlang/swift-evolution/pull/2946/files

The SDK doesn't quite work that way, your iOS-specific dependencies like SwiftUI and UIKit aren't available. For SwiftUI development, [Skip](https://skip.tools/) has a transpiler that translates your SwiftUI code into Jetpack Compose.

Without Skip, you can still share other code through JNI - similar to Kotlin Multiplatform.

The reverse is slowly becoming a possibility. Jet Brains just announced another improvement with Swift Export. https://kotlinlang.org/docs/native-swift-export.html

But it's not there yet

An example of an Android app that is built using the Swift SDK for Android and is available in the Google Play Store is Skip Showcase: https://github.com/skiptools/skipapp-showcase/

(disclaimer: I work on the Skip.tools product)

Not yet, and possibly not ever quite from Xcode. But using Swift CLI tools, yes.

The example Activty I saw is pretty rough ergonomically, but I have no doubt an ergonomic, SwiftUI-like library could be built on top of what’s currently there and/or on the roadmap.

No, it’s just an Android compiler and standard libraries.

Same way there are C compilers for Windows and Linux, but that does not mean binary compatibility.

idk about Android, but native iPhone dev is pure torture. Hence React Native.

This depends entirely on how well the thing you're using bothered to support multiple platforms.

Browsers are pretty much the gold standard here, ironically. You might have to care if it's Firefox or Chrome but it's very rare for you to have to care if it's Firefox on Windows or Mac or Linux. It's exactly why React is simultaneously horrible and everywhere.

So it can be done, it's just a question of whether that framework has done it well, ideally while also doing other things well (unlike React).

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

What happens in the Java/Kotlin case?

You mean android?

It's compiled.

From what I see in other threads, skip.tools offers the possibility to transpile SwiftUi to Compose, so you build one UI and port it to android too.

Here we're talking about sharing the code logic (written in swift) and write android UI that uses it.

Same reason everyone doesn't use Xamarin. Everyone has their own multiplatform framework solution.

JetBrains already works on Swift support within Android Studio.

Because some of us prefer writing Swift over writing Kotlin.

Pretty much everything starts iOS first, so why bother with KMP when this exists?

I'm pretty happy with that number, considering this ecosystem is _brand new_. This is the lowest it'll be.

If you compare it to absolute zero I think you may be pleasantly surprised.

Not a chance

React Native is popular because there’s a thousand times more React devs than native devs.

And people like to use what they know.

Also React dev experience makes anything Swift related look like stone age technology

Why would a marginal platform language become de facto language for mobile? If anything, Kotlin is much better positioned to fill the niche. It is already far, far ahead of anything Swift has to offer and is backed by a company actually making money out of the tools. What incentive does Apple have? My bet is expanding Apple services (Apple TV, Music, etc.), but is that enough for Apple to create a proper dev ecosystem? Highly unlikely.

Flutter still exists, so as a competitor you need to beat both React Native and Flutter.

I last used RN half a decade ago, but from what I see around me - our frontend developer, who is proficient in React, actually chose to use Flutter for our iOS and Android mobile apps — and he’s quite satisfied with it.

Kotlin did it first with kotlin multiplatform

Because hardware capabilities exist outside the realm of web technologies.

Apple and Google couldn’t take 15-30% that way

Because Google/Apple don't want us to circumvent their respective app stores, so they make certain features/API's a PITA (if not impossible) to use unless you are building natively.

Most people don't even know they exist (I do not count webapps in a native shell as PWA). that's the biggest issue with PWA in my experience. People aren't using them.