Hacker News Reader

Comment by cosmic_cheese | Hacker News Reader

It'd be nice if Apple made SwiftUI cross platform and I'd be singing in the streets if UIKit got ported, but that seems unlikely at best.

I believe that there's strong community interest in some kind of Swift UI framework for Android, though, and so there's a substantial chance that a third party solution will appear.

View on HN

Correct me if im wrong, but isn't the pain points for mobile devs, the need to have intimate knowledge of both pl to build & maintain a good "backend/functionality" of the app over time and that the UI portion of the app is quite simple to learn, build and maintain.

So is it necessary for the swift team to try get swift ui onto android, versus a developer building their app "backend/functionality" in swift, compiling it down for both ios and android, then bridging the android bindings with a UI made in kmp etc

I recently learnt that amo and protonmail use this solution but instead of swift android, they were using uniffi-rs and seemed to have great results, I think proton ditched react native for this solution, which to me sounds like a more streamlined way of getting native performance without needing the overhead of managing multiple language. I guess we will have to see how mature swift android gets and if it can replace uniffi-rs etc which would save even more time

Do you have a link that talks about Proton Mail's use of UniFFI-rs? A quick search didn't turn up anything.

here is a reddit thread about it: https://www.reddit.com/r/rust/comments/1nq3vk9/proton_mail_r...

the proton mail team claimed they will write a technical writeup soon

I’d absolutely love it if they made SwiftUI cross platform for both mobile and desktop. Flutter is nice but it’s still sort of a mess sometimes when targeting desktop instead of mobile.

SwiftUI is also a mess when targeting desktop (macOS).

Let’s be honest. It’s a mess targeting iOS. It’s like the old days with VB - first 80% done in no time, last 20% takes forever, requiring ever more elaborate hacks to get around stupid restrictions (eg try hiding the keyboard associated with a TextField when you tap on a Picker).

skip.tools is one third-party solution for creating Swift + SwiftUI apps for Android today.

It still translates SwiftUI to Kotlin+Compose, right? Very cool and useful, but not quite the same as a Swift-based UI framework for Android.

Oops, TIL Jetpack Compose doesn't use Android native controls. That is unfortunate.

Jetpack Compose is just as "native" as Android views at this point; it hooks into the same accessibility frameworks and renders to the same surfaces as the framework toolkit. This isn't like Flutter which renders to an opaque Skia buffer.

Great! I appreciate the claification, thank you.

> It'd be nice if Apple made SwiftUI cross platform

It's a nearly impossible task. Just ask Qt, who have been at this for thirty years.

SwiftUI is more realistic actually. UIKit, much tougher (more mature, more tied to the IOS ecosystem).

Highly doubt it, Safari on Windows ran on AppKit and that thing is from the early 1990s. You'd be surprised how high level UIKit actually is.

Source?

Don’t have links, but it’s true. iTunes for Windows also includes chunks of AppKit.

The Windows ports of AppKit in both likely trace their lineages back to Yellow Box, which was the Windows port of AppKit that Apple briefly made available prior to the release of OS X 10.0.

My understanding was Foundation and bits of CoreGraphics but not AppKit. Yellow Box required DPS.

Qt has grown so huge that I rather choose Tk or GTK for cross platform GUI.

i would love to see how Swift will do cross platform gui.

UIKit is very mature and tied to the iOS ecosystem and a bit more complex. SwiftUI is easier to port (since it is still a incomplete / subset features of UIKit).

From what I've read, SwiftUI is using parts of UIKit under the hood, so it also doesn't seem too likely.

Yes historically but not by design. It's more of a transition tactic.

Starting with iOS 26, new UIKit and AppKit features are implemented by "native" SwiftUI (specifically, Liquid Glass's implementation). In recent years they have also been replacing UIKit/AppKit-backed SwiftUI views with "native" SwiftUI implementations.

But besides this technical change I don't think Apple has any desire to bring SwiftUI to other platforms.

BTW: https://skip.tools has bridged it to Compose. Your SwiftUI code runs in native Swift on Android.

Reply on news.ycombinator.com