Apple's Swift Working to Support Android App Development

[springsup]

Apple have invested a lot in Swift, and their internal services run Swift on Linux. It is also being used on the Secure Enclave processor in an embedded (bare metal) configuration.

They’ve recently been supporting Swift on WebAssembly as well, and Windows support has improved a lot.

A lot of people don’t understand what Swift is: it’s a language. It lets you express programs and has a tool called a compiler which transforms that language in to something a computer can run. That’s it. It comes with some basic components for working with things like text and numbers in an abstract way, but no visual/graphical components.

Swift is a big improvement over Apple’s previous language, and is created by a team of former C++ committee members and other language specialists from across the industry who Apple hired. In many ways it is also a big improvement over C++ and Java, offering the kinds of features people love about Rust but in a way that is more productive and easier to use. The hope is that by making it an option for more programmers, they can convince more people that Swift is a viable option for their projects.

 

[adib]

So, eventually, AI models only have to focus on improving their coding in only one language. That would be my guess.

Which is Python, and then model conversion to the various platforms' preferred formats.

 

[alba_83]

Elaborate. I’m a RN dev. Pure curiousity, if you have valid points I wont bash, only be grateful to hear them.

Huge dependency chain, poor first party support for common native features (navigation, device hardware access etc…), requires you to drop to native to use many commonplace SDKs (Facebook and a lot of analytics/ad-specific things), slower uptake on new platform features (if at all)…

It’s unfortunately a long list. We’ve developed many RN apps, and Xamarin and a few MAUI. But nowadays my go to is always native first for clients. Time to market is tiny in comparison to messing about with making things work natively for each platform in MAUI and RN. Compose and SwiftUI are similar, so it’s easy for devs to switch. React isn’t ReactNative. It’s one of the biggest misconceptions I see with client teams.

 

[DrWojtek]

Huge dependency chain, poor first party support for common native features (navigation, device hardware access etc…), requires you to drop to native to use many commonplace SDKs (Facebook and a lot of analytics/ad-specific things), slower uptake on new platform features (if at all)…

It’s unfortunately a long list. We’ve developed many RN apps, and Xamarin and a few MAUI. But nowadays my go to is always native first for clients. Time to market is tiny in comparison to messing about with making things work natively for each platform in MAUI and RN. Compose and SwiftUI are similar, so it’s easy for devs to switch. React isn’t ReactNative. It’s one of the biggest misconceptions I see with client teams.

Thanks!

 

[Shalev Lazarof]

You tell us, you have the knowledge

My guess? Fight Cross Platform development tools like flutter by replacing them with swift, reaching to a point where apple's AI models would be great tool for developers on each platform (others to follow in the future maybe)

 

[SpanishAppleNerd]

My guess? Fight Cross Platform development tools like flutter by replacing them with swift, reaching to a point where apple's AI models would be great tool for developers on each platform (others to follow in the future maybe)

What we economists call "saturation of the market", right? Offering several versions of the product until ours is the most sold (used)

 

[bernaferrar]

Does this include the UI components too? Write once, run on both without differentiating Android and iOS UI components? That would be nice, but probably not the case.
Our company uses currently .NET MAUI for cross platform iOS/Android - it's ok, but lots of UI limitations and you still have often to write platform dependent wrapper for certain native controls or operations.

No idea what they will do, but iOS being closed sourced doesn't help

 

[un_homme]

Don't get too excited. This is a community-based effort, an evolution of an ongoing endeavor, not a new Apple project. See their forums. To quote this post:

>mostly a community initiative for the last decade, but a couple Apple employees have been pitching in a bit lately

 

[Madd the Sane]

Huh, that makes sense: WWDC 2025 did mention Java interoperability. It would make more sense if they were working on Android support.

 

[Wx_Man]

I don’t think most of the negative commenters have a freaking clue as to how big this could possibly be. Probably because they’ve never programmed anything in their life or developed anything for either of the planet’s two biggest software ecosystems in human history. Swift, technically, is the heir apparent of the venerable C language and its Frankenstein offspring C++. In fact, as Swift is the evolution of Objective-C, which was how C and C++ should have been engineered with objective oriented type programming, albeit without the nearly Java amounts of verbosity, Swift is really the only future oriented and type safe C/C++ equivalent that doesn’t need a virtual machine like Java or an IL like C#, both being C derivatives as well. Swift’s syntax now is WAY more pleasant than either it’s forefather Objective-C and Java while being type safe and cleaner in ways that neither C or C++ can ever be, even with some people’s furtive and futile attempts recently to make them so in the face of the onslaught of Rust. Now, if this project to make Swift a first class programming citizen on Android proves effective, then an iOS / iPadOS developer can more easily than ever make cross platform apps for both ecosystems and gives Android developers an easier path to cross over to iOS / iPadOS. That is a WONDEFUL thing for the Swift ecosystem and the Apple ecosystem as well. I also will dare say it could have good knock on effects for the Linux world but as I am also a part of that world and use Linux as well as MacOS and iOS there is definite suspicion and downright hate for anything Apple in Linux Land. But when I can I do sing Swift’s praises in Linux forums from time to time.

 

[Wx_Man]

Just. Use. React. Native.

Just. Don’t.

 

[LawJolla]

I've used it plenty. We rewrote all our React apps because like I said, it's trash.

Link to the app store?

Wait let me guess... it's super secret and you can't share. 😂

 

[LawJolla]

React sucks.

Native or nothing at all.

SwiftUI sucks.

 

[thefredelement]

I think they're going to update Swift to run via the Android NDK, kind of going back to its C++ roots, then shim SwiftUI with native android UI APIs.

 

[Audentia]

This is a very good thing. What's happening now is that there are a lot of different code language providers and those are challenging languages that were previously thought to be untouchable. Rust is threatening C and C++ which has really thrown the C++ into gear to make it better. Java has a million alternatives (including Kotlin). When Apple stopped using Objective C, it immediately died because it absolutely was not worth using for anyone else. Apple trying to make Swift work outside of Apple is one way of making sure the language is not accidentally rotting and they're not realizing it because people are forced to use it. If they can get interest from people outside of Apple it proves the language has merit.

Yes, well said.

I'm not sure based on the comments that many people here understand the technical tradeoffs of languages, platforms, and the benefits when one is used among multiple companies and orgs and because people like it, not because they have to. Apple indirectly benefits from this and it's important to keep Swift competitive. Rust and Swift are really both special languages, performance of C++, ergonomics of Python (loosely speaking).

Also, multiplatform Swift is a whole different animal compared to technologies of the past whether Xamarin or React Native or Flutter. Swift has deeper technical benefits, primarily speed and memory efficiency, which Dart, JavaScript, C#, Kotlin / Java will never be able to touch. Apple is already directly benefiting from this on the server https://www.swift.org/blog/swift-at-apple-migrating-the-password-monitoring-service-from-java/

Write once, (with platform specific customizations) and get actually performant, actually debuggable, actually native code on each platform. The tools are just early, but the foundations with Swift are better.

Skip

Skip brings SwiftUI app development to Android

skip.tools

SwiftCrossUI

https://xogot.com/