The Swift SDK for Android(swift.org)
swift.org
The Swift SDK for Android
https://www.swift.org/blog/nightly-swift-sdk-for-android/
297 comments
> 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.
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.
Indeed, "cross-platform UI" can only be as good as the average between all the platforms it supports and it usually ends up costing a lot more than using the native UI kits of each platform. Kotlin Multiplatform has been and continues to be the "happy path" for buildings apps in our studio - native UI + shared business layer. Also, in terms of API stability and mental load, Kotlin is a lot more productive than Swift... and it doesn't come with a yearly breaking cycle.
« kotlin is a lot more productive than swift »
care to elaborate ?
care to elaborate ?
Having worked a long time with client teams as a lead - this is always the biggest pain in the ass.
At one of my last phase startups I started shifting all our business logic stuff into our graphql server and treated it like it was part of the client teams. (we had ios/android/web as independent full apps with a very small team of devs).
Business logic is the real killer. Have one person suck it up and do it in typescript (sorry y'all) on the GQL/apollo server and all the clients can ingest it easy.
Send down viewmodels to the clients not data models. etc etc.
This helped DRAMATICALLY with complexity in the clients.
At one of my last phase startups I started shifting all our business logic stuff into our graphql server and treated it like it was part of the client teams. (we had ios/android/web as independent full apps with a very small team of devs).
Business logic is the real killer. Have one person suck it up and do it in typescript (sorry y'all) on the GQL/apollo server and all the clients can ingest it easy.
Send down viewmodels to the clients not data models. etc etc.
This helped DRAMATICALLY with complexity in the clients.
So your takeaway is that business logic should be done on the server. Hasn't it always been like this?
Has been the true core vision of the web if not mobile. If I remember correctly, that is how the original Basecamp was implemented, or Craigslist (still is?)... or this very website
Also I just realized the irony of them using GraphQL. They've really come full circle
OP is likely talking about local business logic, ie password field is min 3 chars long. You validate that in the FE before sending it up to get instant feedback to the user.
Your API should be fast enough and hosted on the edge so that the server side validation is instant feedback
There are external factors apart from your own API that can impact latency, for example a user could be in an area of poor internet connection or have a slow connection. Users do not live in our perfect development environment bubble where everything just works, it’s important not to assume that.
If it takes 1 second for a small percent of users to get form validation back it won't impact the business
That's how we got to "download 50 GB before playing a game on a console is fine", feels like we just stopped carying. Sending the form to the BE just to do same basic validation adds so much latency to the UI that it feel unusable for many/most users.
Related: A few Sundays ago I wanted to play Anno again. Sadly it was not installed on the Laptop I used. So i started downloding it because you won't get it on DVD/as iso-file today). Now it's a few Sundays after and I didn't play yet - because the download took 7 hours.
Related: A few Sundays ago I wanted to play Anno again. Sadly it was not installed on the Laptop I used. So i started downloding it because you won't get it on DVD/as iso-file today). Now it's a few Sundays after and I didn't play yet - because the download took 7 hours.
That's such a ridiculous logical falacy. You already have to send the form input to submit the form in the first place and you already need server side validation.
I just checked one of my app's register page (which makes > $2M ARR). If you submit a short password it returns an error from the backend that says "Password should be at least 6 characters.". (It uses Supabase). But yeah, that is so unusable it is basically the same as taking 7 hours to download a game onto your Playstation. Great logic!
I just checked one of my app's register page (which makes > $2M ARR). If you submit a short password it returns an error from the backend that says "Password should be at least 6 characters.". (It uses Supabase). But yeah, that is so unusable it is basically the same as taking 7 hours to download a game onto your Playstation. Great logic!
What if you want your app to work offline?
And not just off-line, but as we learned last week, if us–east-1 is down you have spotty connectivity, not hard down, and your device needs to not cook your users; literally in the case of Sleep8.
We've really hit a strange level of dystopia when your bed doesn't work because a server is down
It was a near real-time messaging application. So not really applicable (other than seeing messages you already received - which could be cached from previous sessions).
I guess I'm not clear on what you mean about putting business logic in the client. It can't only be on the client side. If you do so, then obviously you have to replicate it on the server to check that the client was sending the right results, no? Not to mention avoiding thread races and double inserts and whatever else may have gone stale on the server before you allow a client to validate something? Even if your code isn't public-facing, the server still needs to check everything. As a solo dev it seems insane to me to ever put business logic in the client, unless the client and server literally share the same typescript codebase for crosschecking ops, and even then the server needs the same code plus additional safeguards. It baffles me that anyone would write a platform from the ground up with primary business logic on the client side, if the server isn't written in the same language. Maybe some simple initial validations and checks to avoid bombarding the server, but the server has to be the central source of truth.
That’s the exact opposite of what the GP is suggesting. Read this again:
> Business logic is the real killer. Have one person suck it up and do it in typescript (sorry y'all) on the GQL/apollo server and all the clients can ingest it easy.
Move the logic to the GQL retriever so that clients don’t have to implement business logic.
> Business logic is the real killer. Have one person suck it up and do it in typescript (sorry y'all) on the GQL/apollo server and all the clients can ingest it easy.
Move the logic to the GQL retriever so that clients don’t have to implement business logic.
Yeah, I understood what they said. I'm wondering why the previous owners of the code decided to put business logic in the client.
we had a lot of very talented iOS devs that started running away with feature development when the server team couldn't keep up.
This really hurt the android + web client teams.
Eventually our backend started changing (mono-rail -> microservices) and it turned into an absolute cluster of trying to massage/cram new data models into the existing ones the iOS team created.
Late stage startup and then post finding product market fit problems.
This really hurt the android + web client teams.
Eventually our backend started changing (mono-rail -> microservices) and it turned into an absolute cluster of trying to massage/cram new data models into the existing ones the iOS team created.
Late stage startup and then post finding product market fit problems.
OP is likely talking about local business logic, ie password field is min 3 chars long. You validate that in the FE before sending it up to get instant feedback to the user (yes you also have it on the server).
> 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.
if you can fix the dev issues and have a dedicated team behind the shared logic it could work out, but still then again if you also have a website your re-implementing that logic on the front-end twice...
> e.g kotlin exceptions cant be caught from swift
FWIW the approach that swift-java takes in managing interop with Java (and potentially Kotlin) function calls means it is perfectly possible to to catch exceptions thrown by the JVM using wrappers that catch and rethrow them as Swift errors. So there would be a distinction here with bringing Swift calling into JVM-based code running on Android.
FWIW the approach that swift-java takes in managing interop with Java (and potentially Kotlin) function calls means it is perfectly possible to to catch exceptions thrown by the JVM using wrappers that catch and rethrow them as Swift errors. So there would be a distinction here with bringing Swift calling into JVM-based code running on Android.
> catch and rethrow them as Swift errors
Sure. I guess my point was that maybe your devs are more comfortable doing it in Kotlin than in C/C++/Rust.
And IMO not everything should be shared; it's worth sharing complex logic because the overhead of sharing beats the overhead of writing it twice. But in many situations it is not slower to write it twice. And I am an advocate of writing the UI on each platform to have a truly native experience for the users.
And IMO not everything should be shared; it's worth sharing complex logic because the overhead of sharing beats the overhead of writing it twice. But in many situations it is not slower to write it twice. And I am an advocate of writing the UI on each platform to have a truly native experience for the users.
I’ve experienced much the same as you but that’s one of the reasons I’m interested to see where Swift on Android goes. These problems are solvable, it’s just that current implementations haven’t solved them satisfactorily.
> Sharing UI in complex apps, in my experience, always ends up being a "write once - debug everywhere" nightmare
Compared to the tried and true method of "write many times - debug everywhere".
there is not a world in which you won't have issues on $PLATFORM because $PLATFORM themselves have their own individual bugs / issues
Compared to the tried and true method of "write many times - debug everywhere".
there is not a world in which you won't have issues on $PLATFORM because $PLATFORM themselves have their own individual bugs / issues
> Sharing UI in complex apps, in my experience, always ends up being a "write once - debug everywhere" nightmare
Amen!
Amen!
>> The most important question for every cross platform framework is what happens to the UI?
>I kindly disagree.
You're still discussing the question of UI though, whether it's native or not.
You're still discussing the question of UI though, whether it's native or not.
React Native is pretty good at cross platform but yes, it must be tested right away on all platforms.
Retrofitting an iOS-only React Native app to Android later is possible but can be of a pain, at least initially.
Retrofitting an iOS-only React Native app to Android later is possible but can be of a pain, at least initially.
My experience as an Android user is that React Native apps don't feel "Android native". Maybe it's because I only notice the apps that have the poorer UI, I don't know.
React Native apps can be made to feel native but it takes some knowledge and skill. In certain cases, a bit of native code might be required instead of off-the-shelf libs.
For example, I was looking for a way to perform certain computations on a stream of frames from the camera. Most libraries available I found would send the image frames to the JavaScript side first and do the computation there. Unfortunately, that was never 60fps because the amount of data being copied/serialized was too large. The solution was to write a bit of custom code that performs the computation on the native side and only ship the computed result (tiny JSON) to the JavaScript side. The end result was easily 60fps and felt 100% native.
For example, I was looking for a way to perform certain computations on a stream of frames from the camera. Most libraries available I found would send the image frames to the JavaScript side first and do the computation there. Unfortunately, that was never 60fps because the amount of data being copied/serialized was too large. The solution was to write a bit of custom code that performs the computation on the native side and only ship the computed result (tiny JSON) to the JavaScript side. The end result was easily 60fps and felt 100% native.
> Sharing UI in complex apps, in my experience, always ends up being a "write once - debug everywhere" nightmare.
Was that with UI framework that wraps platform's UI framework or with one that draws controls on its own? Shared complex UI is not much of an issue with frameworks that fully implement their own controls. But quality implementation of controls from the ground up is a lot of work so there's not many good UI frameworks that do this.
Was that with UI framework that wraps platform's UI framework or with one that draws controls on its own? Shared complex UI is not much of an issue with frameworks that fully implement their own controls. But quality implementation of controls from the ground up is a lot of work so there's not many good UI frameworks that do this.
[deleted]
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.]
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.]
This seems great, we are looking for a code sharing language between platforms and the options so far are the Usual Suspects:
- TypeScript: we have a few million lines already, but it runs poorly on Android midrange devices.
- Rust: very efficient on Android / iOS but on web there’s very expensive memcopy between WASM memory and JS. Safe but hard to write and refactor casually. Would be great for server perf tho. Async has many footgun for our JS devs. Biggest long term downside: borrow checker speed limit on developer velocity for business logic.
- Kotlin: can target JS directly avoiding bridge cost. iOS devs are uneasy about it. Async story is extremely confusing. Biggest long term downside: how Byzantine the JVM ecosystem is on the server.
Until I saw this Swift wasn’t really in the running. I need to explore the web target situation. Swift is maturing but still weak in ecosystem on non-Apple platform compared to other options. Still swift is moving towards a great combo of speed + safety + usability.
Biggest long term downside: type inference pain. Swift is the only language I’ve used that will tell me “the types seem wrong / ambiguous, but the compiler has no idea what your specific mistake is” and there’s no way to fix it other than trying random code permutations. I hit that one with node-swift yesterday and gave up.
Is there anything in the works for taming the type inference or some way to force-select which overload I want?
- TypeScript: we have a few million lines already, but it runs poorly on Android midrange devices.
- Rust: very efficient on Android / iOS but on web there’s very expensive memcopy between WASM memory and JS. Safe but hard to write and refactor casually. Would be great for server perf tho. Async has many footgun for our JS devs. Biggest long term downside: borrow checker speed limit on developer velocity for business logic.
- Kotlin: can target JS directly avoiding bridge cost. iOS devs are uneasy about it. Async story is extremely confusing. Biggest long term downside: how Byzantine the JVM ecosystem is on the server.
Until I saw this Swift wasn’t really in the running. I need to explore the web target situation. Swift is maturing but still weak in ecosystem on non-Apple platform compared to other options. Still swift is moving towards a great combo of speed + safety + usability.
Biggest long term downside: type inference pain. Swift is the only language I’ve used that will tell me “the types seem wrong / ambiguous, but the compiler has no idea what your specific mistake is” and there’s no way to fix it other than trying random code permutations. I hit that one with node-swift yesterday and gave up.
Is there anything in the works for taming the type inference or some way to force-select which overload I want?
How does transpiration work without GC? I would think all the Kotlin equivalents would be GC heap allocated objects.
This doesn't transpile. It cross-compiles to Android architectures using the NDK. You can see a very simple "hello world" example at the bottom of this article:
https://www.swift.org/documentation/articles/swift-sdk-for-a...
https://www.swift.org/documentation/articles/swift-sdk-for-a...
Oh thanks, I was reading about Skip and it seemed to be a transpilation tool. The new thing is Swift compiled to a native binary with the NDK and using a JNI bridge to interoperate with Kotlin APIs.
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]
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]
Appreciate the response!
Respectfully, the demos on your page look like impostors on Android. For apps that wouldn't bother supporting Android in the first place, maybe this is an improvement. But for apps that want all customers to feel considered, that's not a direction I would recommend.
Would still like to see a call out to this in the blog post above ("For UI, you can use Swift for business logic and use Android's SDK to create the interface. Or you can use a library like our partner skip.tools to write SwiftUI apps directly.")
Respectfully, the demos on your page look like impostors on Android. For apps that wouldn't bother supporting Android in the first place, maybe this is an improvement. But for apps that want all customers to feel considered, that's not a direction I would recommend.
Would still like to see a call out to this in the blog post above ("For UI, you can use Swift for business logic and use Android's SDK to create the interface. Or you can use a library like our partner skip.tools to write SwiftUI apps directly.")
> the demos on your page look like impostors on Android
On the Android side, Skip apps utilize Jetpack Compose directly, which is the officially recommended toolkit for creating Android apps these days (https://developer.android.com/compose). It isn't mimicking native UI like other x-platform tools, but is actually using the Google-recommended API.
On the Android side, Skip apps utilize Jetpack Compose directly, which is the officially recommended toolkit for creating Android apps these days (https://developer.android.com/compose). It isn't mimicking native UI like other x-platform tools, but is actually using the Google-recommended API.
The three buttons dialog (ContentView.swift Showcase) in particular looks like iOS rather than Android.
Pretty sure that was a design choice, not a tech limitation. It's just a four row stack or a table with a custom header, and a border with rounded corners.
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.
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 exists already.
SwiftUI to Jetpack Compose: https://skip.tools
And a less mature but very interesting project with a SwiftUI-like API for UI across macOS/Linux/Windows plus some emerging support for Android and even a TUI target contributed by Miguel de Icaza: https://swiftcrossui.dev
> It's a description language that system frameworks interpret and create NSViews and UIViews and CGLayers etc out of.
This is out of date. FYI parts of SwiftUI are "native" now. Notably the new Liquid Glass UI was written in "native" SwiftUI. UIKit and AppKit actually wrap SwiftUI views to render Liquid Glass now. Although SwiftUI-exclusive APIs have always existed, this was a notable step in a new direction and suggests the future of UIKit and AppKit is a unified "native" SwiftUI implementation.
They've also been ripping out UIKit/AppKit implementations of SwiftUI views... IIRC List is no longer a UITableView for instance (could be confusing with another component though).
SwiftUI to Jetpack Compose: https://skip.tools
And a less mature but very interesting project with a SwiftUI-like API for UI across macOS/Linux/Windows plus some emerging support for Android and even a TUI target contributed by Miguel de Icaza: https://swiftcrossui.dev
> It's a description language that system frameworks interpret and create NSViews and UIViews and CGLayers etc out of.
This is out of date. FYI parts of SwiftUI are "native" now. Notably the new Liquid Glass UI was written in "native" SwiftUI. UIKit and AppKit actually wrap SwiftUI views to render Liquid Glass now. Although SwiftUI-exclusive APIs have always existed, this was a notable step in a new direction and suggests the future of UIKit and AppKit is a unified "native" SwiftUI implementation.
They've also been ripping out UIKit/AppKit implementations of SwiftUI views... IIRC List is no longer a UITableView for instance (could be confusing with another component though).
I think using a closed source solution (except the platform native solution) for such a core part of an application is a big no.
I agree it makes me very nervous. Though as I understand it, it's mostly open source (edit: not the build tool tho).
Their transpiler solution at least results in maintainable Kotlin code that one could begin working in directly without needing Skip. But the transpiler way is more limiting than the native Swift SDK on Android.
I'm considering using it just as a way to bootstrap as my main focus has been iOS/Mac. If I can use it to generate enough of a new revenue stream on Android, I could then afford to hire an Android developer to take care of doing it without Skip, too.
Their transpiler solution at least results in maintainable Kotlin code that one could begin working in directly without needing Skip. But the transpiler way is more limiting than the native Swift SDK on Android.
I'm considering using it just as a way to bootstrap as my main focus has been iOS/Mac. If I can use it to generate enough of a new revenue stream on Android, I could then afford to hire an Android developer to take care of doing it without Skip, too.
That makes perfect sense imho. I don't see it as a long term solution.
They didn't port SwiftUI to windows; they wrote a Swift wrapper for WinUI. Impressive in its own right, but not SwiftUI.
[deleted]
Is their code available somewhere.
I need this for UIKit so that I can make my UIs in Go. I have the gist of what it would require but have yet to implement everything. (if swiftUI allowed more control over the UI tree, I would even target it but full declarative à la react with vdom diffing is no bueno for fine grained rendering control)
I need this for UIKit so that I can make my UIs in Go. I have the gist of what it would require but have yet to implement everything. (if swiftUI allowed more control over the UI tree, I would even target it but full declarative à la react with vdom diffing is no bueno for fine grained rendering control)
SwiftUI in many cases generates views that were written specifically to back the description you requested. I think that’s pretty native.
> 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.
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.
> 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.
Key word _aiming_ lol
Key word _aiming_ lol
Didn’t Flutter decide not to support Liquid Glass, because it’ll be too much work?
> 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 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.
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.
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.
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.
Apple wants everyone to conform because historically their ux is on point but the last update really reinforces my view.
IMHO, Apps can look (and maybe even "feel") any way they want. But when it comes to integration into the system, they should be as native as possible. It'S 2025 and I can't drag and drop from/to the Gmail app on iOS - that's ridiculous (especially because I can't have real-time push notifications for IMAP in the mail app for Gmail account, which as far as I know is also a limitation by the Gmail servers, not by IMAP itself).
I would like to see an UX research of what is actually important to match to the platform for the users.
The matching of the look is, from my experience, pretty low on the list. It's usually some interaction that doesn't exist or match that people complain about.
The matching of the look is, from my experience, pretty low on the list. It's usually some interaction that doesn't exist or match that people complain about.
The debate has been settled anyways, none of the top apps (Facebook, Whatsapp, Youtube, Tiktok..) uses the native design, users simply do not care.
For the big ones the consistent familiar design language of the app becomes more important, or at least they can argue/get away with that, for the random crap companion app to a £5 drop-shipped FYGUIO-'brand' gizmo, it's much nicer and better-working app if it just follows the platform.
I share your unpopular opinion.
While I understand that having identical UI elements across apps aids in discoverability, I just love it so much when an app has its own bespoke interface that was clearly made with love.
Like you, it might be my love of games that has given me this preference. Would StarCraft II have a better UX if its menus used the standard Windows widgets where applicable? I think certainly not. And I think the same can be true for many non-game apps.
While I understand that having identical UI elements across apps aids in discoverability, I just love it so much when an app has its own bespoke interface that was clearly made with love.
Like you, it might be my love of games that has given me this preference. Would StarCraft II have a better UX if its menus used the standard Windows widgets where applicable? I think certainly not. And I think the same can be true for many non-game apps.
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.
[deleted]
Liquid Glass is meh anyway. Apple's Windows Vista moment.
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.
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.
> Almost always … 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.
But not always, and when it’s not true, it sticks out like a sore thumb. It’s convenient for developers, but produces apps that have this uncanny valley “this isn’t quite right” quality to them. Adobe used to do this when I worked there 20 years ago (honestly don’t look at modern Adobe software if I can help it so I don’t know if they still do) with an internal component called Adobe Dialog Manager that was built expressly so developers didn’t need to worry about native widgets. The result was this “adobeness” to all the ui elments on both platforms (at this point we are talking windows vs macOS). There was no os-level button. There was an ADMButton on both platforms and it was hand-rolled behavior for rollovers and drawing styles and general interaction rules and it was this pleasantly uniform experience that sucked equally everywhere.
But not always, and when it’s not true, it sticks out like a sore thumb. It’s convenient for developers, but produces apps that have this uncanny valley “this isn’t quite right” quality to them. Adobe used to do this when I worked there 20 years ago (honestly don’t look at modern Adobe software if I can help it so I don’t know if they still do) with an internal component called Adobe Dialog Manager that was built expressly so developers didn’t need to worry about native widgets. The result was this “adobeness” to all the ui elments on both platforms (at this point we are talking windows vs macOS). There was no os-level button. There was an ADMButton on both platforms and it was hand-rolled behavior for rollovers and drawing styles and general interaction rules and it was this pleasantly uniform experience that sucked equally everywhere.
> 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.
They don't give a fsck. Compare Windows, Adobe, Apple, Google products from 10 years ago with the present ones.
Think of this more like Kotlin Multi Platform. Shared logic, not UI.
> 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?
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?
Looks like this is package compatibility, not a cross-platform UI system (although maybe that’s in the works. SwiftUI could probably port well).
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
Only the UX has to feel native, the pixels are yours
I wrote this in another thread: I'm confident that with Liquid Glass, even more companies aren't interested anymore in the Apple UI look and rather want their own UI language, because Liquid Glass is just that bad.
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.
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.
> 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)
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)
It probably varies from area to area, but in the US iOS first is common.
Having developed both, it makes sense.
iOS is by far the more profitable of the two platforms and its support burden is substantially lower — far fewer versions to think about with the bulk of users running 0-2 versions behind, single form factor (only size variants), zero manufacturer skin quirks/bugs to deal with. It’s a more fertile environment for getting up and running and getting the core product shaken out.
Android can come later when you’re out of rapid iteration and have the bandwidth to deal with the idiosyncrasies of the Android world.
Having developed both, it makes sense.
iOS is by far the more profitable of the two platforms and its support burden is substantially lower — far fewer versions to think about with the bulk of users running 0-2 versions behind, single form factor (only size variants), zero manufacturer skin quirks/bugs to deal with. It’s a more fertile environment for getting up and running and getting the core product shaken out.
Android can come later when you’re out of rapid iteration and have the bandwidth to deal with the idiosyncrasies of the Android world.
In large parts of the world, the iOS and Android revenue share are roughly 50/50 with the higher $/user of iOS and the higher market share of Android cancelling each other out. And that means everyone makes hybrid apps unless they're in a niche where that's impossible, which is rare. Only if they become very successful or raise massive funding (for that country), then they might switch to two native apps.
It's probably a US centric take you're replying to.
Having worked at multiple companies making apps in the US and the company I work at right now which is a company almost everyone knows the name of and the vast majority of our revenue comes from our native apps - practically every feature we build is iOS and web first and only if it performs well do we even consider adding to android most of the time. And it's primarily because product/execs know iOS users are more likely to pay for things.
It's sad as an android user myself, but android is very much a second class citizen in the US
Having worked at multiple companies making apps in the US and the company I work at right now which is a company almost everyone knows the name of and the vast majority of our revenue comes from our native apps - practically every feature we build is iOS and web first and only if it performs well do we even consider adding to android most of the time. And it's primarily because product/execs know iOS users are more likely to pay for things.
It's sad as an android user myself, but android is very much a second class citizen in the US
It's not really about the number of developers. If you're running a company in the US at least, most of your revenue is going to come from iOS users.
The US still has a strong iOS market share, shipments just never go below 50%
https://counterpointresearch.com/en/insights/us-smartphone-m...
https://counterpointresearch.com/en/insights/us-smartphone-m...
Even ignoring global OS marketshare, iOS app store customers just simply spend a lot more money per user on the App Store vs Google Play (Google's Android app store). You gotta go where the money is to some extent to get paid.
Global revenues on the iOS app store have always been significantly larger than Google play, even with only ~30% of the global smartphone market.
> https://sqmagazine.co.uk/iphone-vs-android-statistics/
Global revenues on the iOS app store have always been significantly larger than Google play, even with only ~30% of the global smartphone market.
> https://sqmagazine.co.uk/iphone-vs-android-statistics/
Average amount of money spent means little in the context of parent's comment (revenue for a US company).
For instance, if you're Netflix, do iOS user bring you more revenue in the US ? What if you're Hertz ? What about Walmart or Costco ? The only factor will be how many of your users are on iOS vs android. It's a different story if you're a gaming company and target whales of course.
For instance, if you're Netflix, do iOS user bring you more revenue in the US ? What if you're Hertz ? What about Walmart or Costco ? The only factor will be how many of your users are on iOS vs android. It's a different story if you're a gaming company and target whales of course.
Even if you're a social media company, where network effect is everything and getting into everyone's pocket matters, you can still go iOS first. Snap ran with that strategy at first, and it hardly killed the company.
Notably, that's a situation that actually matters for cross-compatibility. There's no web client for SnapChat. Hertz & Costco could point Android users to the web with few repurcussions, IMO
Notably, that's a situation that actually matters for cross-compatibility. There's no web client for SnapChat. Hertz & Costco could point Android users to the web with few repurcussions, IMO
This is still about the actual market share. iOS being 55%+ of the market makes that strategy viable in the US. You'd start with android instead if you were to launch in Korea for instance.
for us its pixel phones, you can choose iphone if you want but most of us want pixel. so for me its macbook + pixel. I think the iphone only is unique to US.
> 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.
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.
[deleted]
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).
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).
OTA updates are definitely nice to have and I'm surprised there's not a way to do so with native iOS since RN and Flutter already support it. Technically it is possible with dynamic frameworks.
In practice though it's somewhat easy to workaround the lack of OTA with dynamic server configuration for clients.
In practice though it's somewhat easy to workaround the lack of OTA with dynamic server configuration for clients.
It used to be allowed, then Apple banned it outright. You're technically not supposed to do it even with RN...
This is not actually true. It’s allowed as long as you don’t make significant alterations to the app as a way to get around the App Store review process. It’s confusing because there are 2 areas of the policy that seem contradictory on this matter, but it is allowed.
This is false.
yes. there is an aspect you are missing.
no one in their right mind wants to bundle Chromium with every app install, and every Discord user hates mobile Discord app, which is, guess what? uses Chromium!
no one in their right mind wants to bundle Chromium with every app install, and every Discord user hates mobile Discord app, which is, guess what? uses Chromium!
Your profile is full of incorrect assertions about software. What do you do for a living
There’s no Chromium in RN, that’s the whole idea behind Native part. It ships optimized JS runtime called Hermes.
And Discord mobile app on iOS doesn’t even use RN, it’s a native application.
And Discord mobile app on iOS doesn’t even use RN, it’s a native application.
For JS driving the business logic you do not need a browser to run it. On iOS there is JavaScriptCore and there are other Javascript runtimes out there that are quite small.
That said, it is true that Javascript may not be the right choice for every app and some developers may be used to better language features and performance than that.
That said, it is true that Javascript may not be the right choice for every app and some developers may be used to better language features and performance than that.
React.Native doesn't use Chromium.
Just curious - how does React.Native implement native UI if it doesn't use chromium
It’s more complex now since they shipped the new renderer, but essentially serializes the react UI tree to JSON and passes it to native which parses and renders native components
By mapping some “low-level” components to platform primitives: https://reactnative.dev/docs/intro-react-native-components
React Native asks the native layer to render the UI natively.
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.
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.
Exact opposite experience :)
You like xcode and think iOS state of the art is ahead of android?
At Proton they use Rust for shared logic (their claim is more than 80% of the codebase iirc), and platform specifics for the rest.
https://proton.me/blog/authenticator-rust - I think this is what you're referring to? Looks really nice
afaik 1password also does something similar
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.
Xamarin with .NET and MvvmCross falls into the same bucket as RN and Flutter IMO, unless something changed since the last time I looked.
Not at all, but it’s important not to mix up Xamarin (nowadays just .NET) which is basically native bindings for C# and Xamarin.Forms UI framework (nowadays MAUI) which is write-once approach like RN.
The former is exactly what you are talking about: building native UIs twice and then sharing the common logic.
The former is exactly what you are talking about: building native UIs twice and then sharing the common logic.
Very neat, thanks for explaining. The only drawback I've seen in the past with apps using .NET is the binaries end up pretty huge due to the runtime. I'm assuming that's still the case here? I wouldn't be surprised if this is also an issue with Swift for Android but I haven't looked yet.
It's not too bad, about 12-15 MB for the runtime on iOS. I'd say the main downside compared to other cross-platform frameworks is the lack of official hot reload (it's possible but really clunky) for building UIs.
Otherwise, I’ve been working with it since 2018, my app now has around 500k installs on both stores, and I’ve encountered very few issues related to the stack itself. Mobile .NET has been steadily improving, and LLMs have made the two-native-UI approach much easier: after building an iOS UI, I ask Claude to repeat it on Android for the same view model and get about 80% done instantly.
Otherwise, I’ve been working with it since 2018, my app now has around 500k installs on both stores, and I’ve encountered very few issues related to the stack itself. Mobile .NET has been steadily improving, and LLMs have made the two-native-UI approach much easier: after building an iOS UI, I ask Claude to repeat it on Android for the same view model and get about 80% done instantly.
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 it uses native UI by wrapping the underlying frameworks, but that still means there is a layer in between that has to be updated with fixes and new features. Every RN project I've tried in the past turned into a dependency mess since you find edge cases that are not supported by the framework.
It's definitely gotten better like you said but I just prefer to work with the native platform code even if it's a bit of extra effort.
It's definitely gotten better like you said but I just prefer to work with the native platform code even if it's a bit of extra effort.
Thank you. Please kill RN and Flutter already. I'm done with square UI apps that handle touches after two days
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
Flutter has a long-standing issue where every interaction is subject to a 1-frame delay on iOS (P2 since 2022)…
https://github.com/flutter/flutter/issues/110431
Not to mention the stuff with shader compilation lag
https://github.com/flutter/flutter/issues/110431
Not to mention the stuff with shader compilation lag
Sure you can find some issues if you look at it hard enough. In the real world scenario, it's very possible to ship a performant, functional app in Flutter and has been for some time now. It also brings some of the best development experiences with Dart, consistent declarative paradigm & hot reload. Like all things, it's a trade off, for me it's very hard to merit maintaining 2x native apps.
There are many, many people out there shipping Flutter apps, and many, many users using those apps. So please stop the hate maybe?
There are many, many people out there shipping Flutter apps, and many, many users using those apps. So please stop the hate maybe?
I'm not hating, I'm actually working on a Flutter project currently. I don't understand why we need to pretend like the platform is perfect
[deleted]
This seems like a pretty defensive comment in response to pointing out some objective flaws in Flutter. It’s fine to admit it’s a trade off, but a trade off necessarily means there are some downsides.
Flutter apps on iOS just do not feel native, that’s a fact. It doesn’t mean you’re a bad person for using Flutter.
Flutter apps on iOS just do not feel native, that’s a fact. It doesn’t mean you’re a bad person for using Flutter.
It's not a fact, it's the opinion of a rather small group of elitist iOS super users. Native is an utterly overrated concept these days and in no way the solution to build an app with good UX. Users don't care whether you use SwiftUI, Components or Widgets. Users don't even know what a native app is. Stop acting like it's the only true holy way.
"native" is a term that has meaning, and Flutter is not native.
I’m curious to hear where you think this is a showstopper. I’ve been testing some Flutter apps lately and other than some mismatches in platform UI elements they have been smooth. I wonder what you would think of apps like Kagi News.
I don’t mean to say it’s a showstopper, but it is certainly noticeable to anyone accustomed to using iOS devices. I suspect the situation on Android is better where Google has access to the native platform code.
Flutter has a secondary problem which is (IMO) a dearth of well-made libraries and showcase apps. Most everything feels half-baked.
The Kagi News app, which I have just installed, doesn’t seem to fall into this category. But like most Flutter apps the fully Material design makes it feel very out of place on iOS. Flutter typography is still broken, with characters tracked out way too far. And the scrolling and touch interaction feels, well, Flutter-y. It’s inherent to the platform
Flutter has a secondary problem which is (IMO) a dearth of well-made libraries and showcase apps. Most everything feels half-baked.
The Kagi News app, which I have just installed, doesn’t seem to fall into this category. But like most Flutter apps the fully Material design makes it feel very out of place on iOS. Flutter typography is still broken, with characters tracked out way too far. And the scrolling and touch interaction feels, well, Flutter-y. It’s inherent to the platform
Kagi News is definitely a well-made app but it also definitely does not look or feel iOS native.
Shader compilation lag hasn’t been a thing for years
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.
If anything, Apple will launch this and quickly forget this exist.
although Apple has tremendous influence over Swift, Swift for Android is a grassroots effort, as said in the link. if community needs it, community will maintain it, and Apple won't get in the way. why would they?
I guess that goes to the larger point then. OP was saying Swift for Android will finally solve all the issues of Flutter & RN, presumably meaning Apple with its $$ and might will do it.
If it is a grassroots project, it has even bleaker outlook then? I wish them success however.
If it is a grassroots project, it has even bleaker outlook then? I wish them success however.
It's also a false dichotomy. My money is all on KMP over any of the 3.
React isn't going anywhere but I expect 5 years from now KMP will be the tool of choice for native app startups.
React isn't going anywhere but I expect 5 years from now KMP will be the tool of choice for native app startups.
> 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.
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.
Having worked with Flutter, I also have the same opinion, I don't think you could pay me enough to use xcode and care about all these half documented apple frameworks.
The app build and upload process is painful enough as it is, I don't want more of it.
The app build and upload process is painful enough as it is, I don't want more of it.
Xcode's upload process is painful? I think it's pretty nice. At least Android Studio doesn't have the feature, so you gotta upload the APK/AAB manually via web browser.
Disclaimer: I work on RN nowadays.
Disclaimer: I work on RN nowadays.
It's so bad that Apple has created a in-house third party tool to bypass it.
imo, Flutter is awesome.
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.
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.
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.
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.
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).
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.
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.
[deleted]
guard let self = self else { return }
`guard let` is great what’s there to hate?
The big problem with swift is “expression has ambiguous type” and “expression took too long to type check”. Those don’t trade in code aesthetics but are problems I’ve never had in another language.
The big problem with swift is “expression has ambiguous type” and “expression took too long to type check”. Those don’t trade in code aesthetics but are problems I’ve never had in another language.
There's a shorter form of it:
guard let self else { return }
Not much better, to be honest.
Ha! But that's not semantically meaningful Swift code in any normal context, nor is it idiomatic. `self` is equivalent to `this` in C++, and is never normally null.
You use this construct for unwrapping nullable fields, for example something like this:
guard let httpResult else { return }
Note that you don't need to assign the value to itself in modern Swift. This line takes an optional (httpResult?) and returns early if null. If not, you can use it with strong guarantees that it's not nullable, so no need for ? or ! to unwrap it later in the scope.
You use this construct for unwrapping nullable fields, for example something like this:
guard let httpResult else { return }
Note that you don't need to assign the value to itself in modern Swift. This line takes an optional (httpResult?) and returns early if null. If not, you can use it with strong guarantees that it's not nullable, so no need for ? or ! to unwrap it later in the scope.
I've seen that exact pattern used to safely unwrap a weakly captured 'self' within a closure (to avoid retain cycles)
> But that's not semantically meaningful Swift code in any normal context, nor is it idiomatic. `self` is equivalent to `this` in C++, and is never normally null.
It is, when `self` is captured weakly in a closure, and that closure is outliving the instance.
It is, when `self` is captured weakly in a closure, and that closure is outliving the instance.
It’s nil in Swift, and what the other comment said ;)
Most use of this is misguided unfortunately :(
This can now be guard let self else { return }
> 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.
Yet Apple has managed to create WatchOS. I don’t know what is the portion of Swift, however.
WatchOS is hardly embedded though. An Apple Watch is basically a small iPhone tied to your wrist in terms of architecture. That’s got a whole lot more in common with a full desktop computer than it does with a microcontrollers, where they often have rather weird architectures by desktop standards, and it’s quite rare to have MMUs and things like that. Also, there is no underlying OS, and no heap allocator (unless you provide one). That’s the kind of challenge that an embedded language runtime has to provide.
Which might be one of the reasons why battery lifetime on Apple Watch is so bad.
"You got Kotlin in my iOS."
"You got Swift in my Android."
"You got Swift in my Android."
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
https://kotlinlang.org/docs/native-overview.html
[deleted]
Dart runs natively. It only uses a VM in dev builds for hot reload.
In fact, you can even link native frameworks into your Dart code.
[1] https://dart.dev/overview#native-platform
[2] https://dart.dev/interop/c-interop
In fact, you can even link native frameworks into your Dart code.
[1] https://dart.dev/overview#native-platform
[2] https://dart.dev/interop/c-interop
I don’t think anything runs in a vm on iOS since they don’t let you JIT compile code. Unless they’re doing pure interpretation, but I can’t imagine that being good for performance.
How solid is Kotlin on iOS?
If you mean Kotlin Multiplatform, it works pretty well. Not easy to debug, the GC is a bit weaker than the Android implementation and optimized builds can get crazy slow as the app grows. The interface uses auto-generated ObjC headers which are very verbose. Native Swift API is in beta. Overall still worth it for a commercial app, I think.
We use it in my team and it works well enough, but iOS is a bit second class citizen. Everything translates to Obj-C (NSObject at the root), so even something as simple as a data class becomes NSObjects with a cumbersome dev experience rather than a native swift enum.
We're looking forward to native swift export to go stable - it's currently experimental / beta.
We're looking forward to native swift export to go stable - it's currently experimental / beta.
Thanks.
> looking forward to native swift export to go stable - it's currently experimental
What are the timelines given for a stable release?
And when it does, what else would you say are the next big things annoying/missing in terms of devex?
> looking forward to native swift export to go stable - it's currently experimental
What are the timelines given for a stable release?
And when it does, what else would you say are the next big things annoying/missing in terms of devex?
Nothing certain, but I reckon it'll be a while: https://kotlinlang.org/docs/components-stability.html#stabil...
The other big problem is debugging. It's impossible to breakpoint kotlin when debugging from swift, so some bugs that are realised only from the swift client side can be tricky and time consuming to fix.
The other big problem is debugging. It's impossible to breakpoint kotlin when debugging from swift, so some bugs that are realised only from the swift client side can be tricky and time consuming to fix.
[deleted]
incremental native builds are getting better at least
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.
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.
idk about Android, but native iPhone dev is pure torture. Hence React Native.
Android is way worse. iOS has way better APIs.
Android studio is way better than XCode though
Android studio is way better than XCode though
Agreed on SDKs/APIs. Compose improved the Android situation but it’s still a mess compared to UIKit.
I’m more mixed on Android Studio. It’s fine I guess, but I wish its UI were more deeply customizable. Many of its design decisions irritate me.
I’m more mixed on Android Studio. It’s fine I guess, but I wish its UI were more deeply customizable. Many of its design decisions irritate me.
Xcode is dogshit though…
I’m mostly in Neovim writing typescript (react native) luckily.
I’m mostly in Neovim writing typescript (react native) luckily.
I've not had much trouble with Xcode in the past 15+ years I've been using it. Its biggest warts involve Interface Builder, which is easily avoidable by using code for UI instead of XIBs or storyboards.
With Android Studio, I'd say the ways that it being an IntelliJ IDE puts it above Xcode are cancelled out by other aspects of Android development, which can be abysmal. Swift Package Manager and Clang/llvm code stripping have never made me want to tear my hair out the way that Gradle and Proguard have for example.
With Android Studio, I'd say the ways that it being an IntelliJ IDE puts it above Xcode are cancelled out by other aspects of Android development, which can be abysmal. Swift Package Manager and Clang/llvm code stripping have never made me want to tear my hair out the way that Gradle and Proguard have for example.
Gradle is the single most confusing build system tool of all time. It’s so bad.
I agree that other than JetBrains everything else about it sucks ass.
I agree that other than JetBrains everything else about it sucks ass.
I've never seen a build system that makes sense, aside from make which is more for individual binaries. If the higher layer build system were just some Python scripts I can look at and understand, that'd be neat.
Xcode with Swift v1-3 was broken. Compiler was insanely slow and would segfault from bugs in the type system.
> 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?
What happens in the Java/Kotlin case?
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).
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).
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.
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.
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.
Cannot agree more. The UI concepts and capabilities differ too much. Any cross platform UI solution will always be missing some hard to implement things and many recently introduced UI features. And so far I haven't seen a single non trivial app from RN / Flutter world which would feel native on iOS.
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.
Do you build desktop apps, too, with Kotlin Multiplatform? How mature is it overall?
I want to know this as well. My only interaction with a Kotlin Multiplatform app is Jetbrains Toolbox, and it's slow to start, has a lot of input lag and overall feels sluggish.
Jvm desktop is honestly the target with the best support. I always build on desktop during mobile dev first because I don't need to deal with connecting a phone or emulator. Second resizable windows by default is so helpful when building for many screen sizes. Also it has hot-reload now
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.
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.)
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.)
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
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
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.
Thanks - I see, so swift packages for everything.
What would be the equivalent shader / GPU language on Android? OpenGL?
What would be the equivalent shader / GPU language on Android? OpenGL?
OpenGL or Vulkan, you might be able to have some luck transpiling metal shaders to spirv-cross at a cursory look
Sometimes it is easiest to have an agent like Codex rewrite the shader instead...
Vulkan with glsl to spirv compiler would be equivalent
Yeah I would also like to see SwiftUI but its apple ecosystem only.
https://skip.tools ported SwiftUI to Android.
[deleted]
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.
Less necessary to be fluent nowadays with LLMs.
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.
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.
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?
> 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
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
What do you mean?
This doc you linked is from August.
The blog post from today includes, in fact at the very top an XCode Swift project emulating a Pixel 9.
The docs include a detailed Getting Started for Android and they even have an Android examples repo.
Hence the SDK.
By all means, it very much is possible to build Android Swift apps in XCode.
https://www.swift.org/documentation/articles/swift-sdk-for-a...
This doc you linked is from August.
The blog post from today includes, in fact at the very top an XCode Swift project emulating a Pixel 9.
The docs include a detailed Getting Started for Android and they even have an Android examples repo.
Hence the SDK.
By all means, it very much is possible to build Android Swift apps in XCode.
https://www.swift.org/documentation/articles/swift-sdk-for-a...
The post doesn't display Xcode but Android Studio. While with Skip you can build & run through Xcode, that's not something we support right now.
You can build the Swift part in Xcode, VSCode or your favorite editor. But the Android builds don't work with Xcode today.
You can build the Swift part in Xcode, VSCode or your favorite editor. But the Android builds don't work with Xcode today.
Isn't it kinda a bad sign that people on HN have to argue in comments about what your library/framework/sdk even does?
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.
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
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)
(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.
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.
Same way there are C compilers for Windows and Linux, but that does not mean binary compatibility.
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...
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...
> 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...
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...
It's worth pointing out that the example you linked with the cdecl is not showcasing the swift-java interoperability but using "raw" JNI patterns as if you would do it with C.
This example does showcase the interoperability: https://github.com/swiftlang/swift-android-examples/tree/mai... you don't have to annotate or write any "weird" cdecls or really touch JNI details yourself when using the swift-java interop support https://github.com/swiftlang/swift-java
This example does showcase the interoperability: https://github.com/swiftlang/swift-android-examples/tree/mai... you don't have to annotate or write any "weird" cdecls or really touch JNI details yourself when using the swift-java interop support https://github.com/swiftlang/swift-java
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.
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.
> android (in an economic sense) is dead weight
Well it depends on your business model. Android has much smaller user LTV in most cases (especially in apps with no ads and only IAPs/Subscriptions), but the CPI is also smaller, so the economies of scale are different. In certain situations it happens that iOS is not profitable but android is.
Well it depends on your business model. Android has much smaller user LTV in most cases (especially in apps with no ads and only IAPs/Subscriptions), but the CPI is also smaller, so the economies of scale are different. In certain situations it happens that iOS is not profitable but android is.
[deleted]
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?
Does anyone know/understand what's the story for using Swift's interop with c++ on Android? Should this work right now? How?
Future - Is it possible to run swift built OS to run on Android devices 100%? Is that a threat to Android as an OS?
Maybe, if someone builds this first. Same could be said about Apple running iOS (as it stands) on Android hardware. It can be done, but there are no incentives for doing this.
> 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
Really!!! Would love to know more how that statement is true. I could not find any resources to support that claim
It is probably true in that you can actually do all of that with Swift. How much is actually used on a larger scale is another question.
This looks not bad, but why would anyone use this in a world where Kotlin Multiplatform exists?
Because some of us prefer writing Swift over writing Kotlin.
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?
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?
Related: https://skip.tools <-- SwiftUI for Android
This looks like a Fluttter competitor where the UI is rendered by the Swift SDK side (vs Android-provided library).
Can somebody explain what goes into making a new language compatible with Android?
Interop with Android SDK / NDK, plus a simple way to get started with development.
Does this result in the Swift code being compiled or transpiled?
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.
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.
So this still uses the JNI for the ui? Unfortunate that is
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 am unable to try it as downloading the swift language doesn't work on fedora 42
> Over 25% of packages in the Swift Package Index already build for Android
That's... not encouraging.
That's... not encouraging.
Whole modern stack is upside down this is a waste of talent
Sweet, now I can make a cursed android app with views written in switft that use kotlin viewmodels
Rip flutter
Why can’t everything just be a progressive web app
Because hardware capabilities exist outside the realm of web technologies.
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.
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.
Meanwhile I considered PWAs necessary evil on iOS. I would gladly use native tools but paying developer subscription just to install private/personal apps is no-go.
What does this mean for React Native?
Is Swift now going to be the de facto language for Mobile (and maybe Desktop) development?
Is Swift now going to be the de facto language for Mobile (and maybe Desktop) development?
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
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
> Also React dev experience makes anything Swift related look like stone age technology
How so?
How so?
Presumably hot reload and IDE integrations that actually work. Xcode is really crappy compared to other IDEs, so platforms that can avoid it for most of your work tend to be an advantage. Xcode 26 generally broke anything that relies on indexing, like autocomplete, edit in scope, or refactoring, among others.
- Hot reload that actually works.
- OTA updates, skipping Apple review for every little thing. Really speeds up builds too.
- Repack and module federation aren’t even possible on native
- running tests on iOS - 2 minutes minimum and having to boot the simulator in most cases. RN - seconds
- IDE with all sorts of plugins, that are impossible on Xcode, Rozenite
- AI trained on lots more React code, where they usually struggle to use Swift 6 properly
and a bunch more things
- OTA updates, skipping Apple review for every little thing. Really speeds up builds too.
- Repack and module federation aren’t even possible on native
- running tests on iOS - 2 minutes minimum and having to boot the simulator in most cases. RN - seconds
- IDE with all sorts of plugins, that are impossible on Xcode, Rozenite
- AI trained on lots more React code, where they usually struggle to use Swift 6 properly
and a bunch more things
I assume all the extra work you have to do to make it work instead of using the native language.
If the project is simple to port over then it should have just been a website.
If the project is simple to port over then it should have just been a website.
[deleted]
> React Native is popular because there’s a thousand times more React devs than native devs.
Exactly this. And they come cheaper. JS dominance in development stems from business logic, not from quality of development environment or tools, or developers preference.
Exactly this. And they come cheaper. JS dominance in development stems from business logic, not from quality of development environment or tools, or developers preference.
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.
> It is already far, far ahead of anything Swift has to offer
Please share what Kotlin has that Swift doesn't
Please share what Kotlin has that Swift doesn't
Look up Kotlin multiplatform and Compose multiplatform.
Ah, so you are talking about frameworks and ecosystem, not the language
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.
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.