HN Reader

696

280

3 months agoby gok

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

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.

3 months agoby bsimpson

Very excited to see this as an official project!

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.

3 months agoby trevor-e

Thank you. Please kill RN and Flutter already. I'm done with square UI apps that handle touches after two days

3 months agoby ls-a

Does this project tie in to the SKIP transpiler? https://skip.tools/blog/bringing-swift-to-android/

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.

3 months agoby TheJoeMan

I hope they actually stick with this. 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.

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.

3 months agoby mosura

"You got Kotlin in my iOS."

"You got Swift in my Android."

3 months agoby jajuuka

I think people will get excited about this and then quickly realize how painful it is to code in a foreign environment from the platform.

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.

3 months agoby VWWHFSfQ

Happy to have it but I worry it's too little too late. I see more and more new projects choosing React Native, Flutter or Jetpack Compose Multiplatform. It's gonna take multiple years for apple or community to catch up to those. Also they should open (source) up xcode tooling for other IDE to get any better cross-platform adoption.

3 months agoby pzo

I have been sharing code between Android and iOS for a long time. Sharing the UI has always been a nightmare for non-trivial apps.

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.

3 months agoby palata

I'm a big lover of Kotlin Multiplatform, but I think this is pretty cool anyway. I could imagine making a native Swift library shared between the platforms for memory-sensitive work. I'm not sure about using it to write an app's entire business logic, KMP is going to be more mature for a while for this.

3 months agoby outadoc

When it comes to UI, most of us know native wins for actual feel and simplicity. Cross-platform UI tends to create new headaches, not solutions. Still, having more options like this pushes the ecosystem forward. Let's just hope the platform docs stay sharp and open for devs who want to build confidently.

3 months agoby Vipsy

I read this announcement mainly as proving the success of the new support for SDK's. Previously, supporting another platform required invasive hodge-podge of CMake tangles at best.

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

3 months agoby w10-1

I would love if I don't have to port my whole iOS app to Android manually. How exactly would this integration work if say business logic is handled by Swift - I'm guessing UI and SwiftUI would not be supported initially?

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

3 months agoby lukko

This is really interesting. I’ve made cross platform mobile libraries before and ended up using Rust… which was fine. But there’s a huge built in advantage to using a language one half of the problem is already fluent in. Curious to see how well it combines with Swift/Webassembly.

3 months agoby afavour

Sharing the “business logic” pretty wasn’t the problem — at least not of late. Writing UI on both was the pain, or the existing shared UI solutions. As a mobile dev I’d rather appreciate a common UI framework that doesn’t suck like react native.

3 months agoby crossroadsguy

I'm just getting started in iOS development as a hobby, but what does this mean? Can I now build my app in Xcode with an Android target and use that binary in the Play Store? It surely can't be that easy now is it?

3 months agoby chrsstrm

Interesting to see excitement around this release...

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

3 months agoby orliesaurus

I've worked with Flutter, React Native, and now I'm building an app in SwiftUI.

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.

3 months agoby tomburgs

I'd love to see a future, where I can use Swift as a bridge between Kotlin and c++ and then gradually port more and more c++ to Swift.

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

3 months agoby kurak

> Swift has matured significantly over the past decade — extending from cloud services to Windows applications, browser apps, and microcontrollers

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

3 months agoby victor106

This looks not bad, but why would anyone use this in a world where Kotlin Multiplatform exists?

3 months agoby saubeidl

The example shows non-GUI code written in Swift, with Kotlin for frontend. So, still no UI in Swift?

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?

3 months agoby a3w