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?
Why cant everyone just get along and allow for KMP to work all within Android Studio instead of XCode. I'm working with this stuff everyday and that is by far my biggest headache.
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?
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.
> 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.
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.
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.
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.
The issue with that approach is that the state of the art for iOS dev is about 15 years behind the state of the art for Android dev. The amount of simple things that are incredibly painful for iOS devs to do is astounding. Some of that is because xcode is horrific, some of it is that the ecosystem is starved by disinvestment from Apple.
I've talked with colleagues in several companies and the story is always the same: the iOS repository is a patchwork of horrible patterns that shatters when you update to the latest iOS target.
At my current employer it takes 4 iOS devs longer to implement things than it takes 1.5 Android devs (0.5 because the other .5 is spent being Team Lead and architecting, planning, endless meetings etc).
When I talked with the KMP team at Google they were mentioning that their most enthusiastic user base at Google was iOS developers, begging to be saved from their tooling nightmares.
I'm sure some defensive devs will show up here but I've been at 5 different places over my decade at work and every single one of them has had endless struggles hiring iOS devs, maintaining iOS projects etc.
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.
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...
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.
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.
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.
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
Except Flutter hit a wall with the liquid glass on IOS and Material 3 on android since they implement all the widgets from scratch implementing the new UI language will take considerable amount of effort and they are saying this is not even their roadmap RN.
> The most important question for every cross platform framework
I don’t think this is a cross platform framework. AFAICT, It’s a Swift toolchain (compiler + Swift standard library) that allows you to call Android APIs.
I would understand people's craving for pixel perfection, smooth 120Hz scrolling, etc, if we had nothing else to want. But I believe that we are now in a totally different era when overall software quality is degrading and we lack some basic stuff here and there, even in the apps of multi-billion-valued companies. In this situation UX should be much more important than UI.
57 comments
[ 2.9 ms ] story [ 79.2 ms ] threadIs Swift now going to be the de facto language for Mobile (and maybe Desktop) development?
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.
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.
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
That's... not encouraging.
"You got Swift in my Android."
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.
Yet Apple has managed to create WatchOS. I don’t know what is the portion of Swift, however.
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.
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've talked with colleagues in several companies and the story is always the same: the iOS repository is a patchwork of horrible patterns that shatters when you update to the latest iOS target.
At my current employer it takes 4 iOS devs longer to implement things than it takes 1.5 Android devs (0.5 because the other .5 is spent being Team Lead and architecting, planning, endless meetings etc).
When I talked with the KMP team at Google they were mentioning that their most enthusiastic user base at Google was iOS developers, begging to be saved from their tooling nightmares.
I'm sure some defensive devs will show up here but I've been at 5 different places over my decade at work and every single one of them has had endless struggles hiring iOS devs, maintaining iOS projects etc.
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.
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...
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?
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.
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.
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.
Only the UX has to feel native, the pixels are yours
They don't give a fsck. Compare Windows, Adobe, Apple, Google products from 10 years ago with the present ones.
I don’t think this is a cross platform framework. AFAICT, It’s a Swift toolchain (compiler + Swift standard library) that allows you to call Android APIs.
Key word _aiming_ lol