Is Swift now going to be the de facto language for Mobile (and maybe Desktop) development?
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
How so?
If the project is simple to port over then it should have just been a website.
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.
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.
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.
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).
What happens in the Java/Kotlin case?
Android studio is way better than XCode though
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.
My app [0] uses a lot of metal shader code - I'm guessing there's no easy way to bring that across?
What would be the equivalent shader / GPU language on Android? OpenGL?
I am not joking. I have done this. Shaders are pretty simple. You'll have some weird artifacts but thats more because of platform differences than translation errors.
That's... not encouraging.
"You got Swift in my Android."
We're looking forward to native swift export to go stable - it's currently experimental / beta.
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.
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.
https://github.com/flutter/flutter/issues/110431
Not to mention the stuff with shader compilation lag
There are many, many people out there shipping Flutter apps, and many, many users using those apps. So please stop the hate maybe?
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
If anything, Apple will launch this and quickly forget this exist.
If it is a grassroots project, it has even bleaker outlook then? I wish them success however.
I've been toying around with multiplatform frameworks like RN and Flutter for a side project of mine but they never feel right. I'd rather use the native UI per platform and have a nice way to share business logic. KMP exists but I think for most developers wanting to build an app it's more common to build for iOS first, and then port to Android later if the app gets traction. With a little foresight of keeping shared code in a Swift Package, it seems like that's getting more and more possible which is great to see.
The former is exactly what you are talking about: building native UIs twice and then sharing the common logic.
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.
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).
In practice though it's somewhat easy to workaround the lack of OTA with dynamic server configuration for clients.
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!
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.
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)
https://counterpointresearch.com/en/insights/us-smartphone-m...
Global revenues on the iOS app store have always been significantly larger than Google play, even with only ~30% of the global smartphone market.
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.
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 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 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.
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.
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...
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...
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
What does it add to the linked "swift-java project" then at all, perhaps some lifetime events and a sort of batteries-included standard library?
Adobe products (both the Creative Suite, and their Flex Builder environment for Flash app) had their own design system that felt foreign on every platform it shipped on. If you wanted something that felt native, you had to reimplement e.g. Apple Aqua in Flash yourself.
Flutter goes out of its way to do that work for you, aiming for a "Cupertino" theme that looks-and-feels pixel-perfect on iOS.
React Native tries to delegate to platform primitives for complex widgets, so scroll views still feel like Apple's when on Apple's platform.
Just about every top-level comment here is talking about that in one way or another; yet the blog post doesn't mention it at all.
It's possible that Apple/Swift's mindshare among developers will lead to a significant number of apps shipping the Swift version for Android even if it means using Apple's UI, simply because they can't be bothered to make something bespoke for Android. Then again, Apple takes so much pride in its design language that it might not be willing to implement anything that feels good on a platform they don't own. If they were to ship an API-compatible widget toolkit, it might e.g. use intentionally bad spring physics to remind you you aren't on an iPhone.
I wonder how big the community part of this is. Is this an open source project of non-Apple people who are trying to break Apple's platform out of its walled garden? Is a lot of it funded by Apple? Ultimately, that's going to shape a lot of how this plays out.
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.]
https://www.swift.org/documentation/articles/swift-sdk-for-a...
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.
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.
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.
> 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...
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.
Amen!
Retrofitting an iOS-only React Native app to Android later is possible but can be of a pain, at least initially.
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.
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 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).
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]
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.")
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.
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?
Apple wants everyone to conform because historically their ux is on point but the last update really reinforces my view.
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.
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.
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.
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.)
chrsstrm•8h ago
samtheprogram•8h ago
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.
objclxt•8h ago
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
thenaturalist•7h ago
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...
joanniso•7h ago
You can build the Swift part in Xcode, VSCode or your favorite editor. But the Android builds don't work with Xcode today.
brookst•8h ago
Same way there are C compilers for Windows and Linux, but that does not mean binary compatibility.
joanniso•8h ago
Without Skip, you can still share other code through JNI - similar to Kotlin Multiplatform.
Larrikin•7h ago
But it's not there yet
marcprux•5h ago
(disclaimer: I work on the Skip.tools product)