Apple's Swift Coding Language Is Working On Android Support (9to5google.com)
- Reference: 0178197084
- News link: https://apple.slashdot.org/story/25/06/26/2133212/apples-swift-coding-language-is-working-on-android-support
- Source link: https://9to5google.com/2025/06/26/swift-coding-language-android-support/
> A few of the key pillars the Working Group will look to accomplish include:
>
> - Improve and maintain Android support for the official Swift distribution, eliminating the need for out-of-tree or downstream patches
> - Recommend enhancements to core Swift packages such as Foundation and Dispatch to work better with Android idioms
> - Work with the Platform Steering Group to officially define platform support levels generally, and then work towards achieving official support of a particular level for Android
> - Determine the range of supported Android API levels and architectures for Swift integration
> - Develop continuous integration for the Swift project that includes Android testing in pull request checks.
> - Identify and recommend best practices for bridging between Swift and Android's Java SDK and packaging Swift libraries with Android apps
> - Develop support for debugging Swift applications on Android
> - Advise and assist with adding support for Android to various community Swift packages
[1] https://9to5google.com/2025/06/26/swift-coding-language-android-support/
[2] https://forums.swift.org/t/announcing-the-android-workgroup/80666
need small language and large built-in library (Score:2)
Sometime, if we are lucky, we will get a small programming language that does not collect new features every year just for the sake of progress, where that language comes with a very broad set of built in and supported by the vendor libraries.
Avoiding the pyramid of 500 third-party packages for a mid-sized application is a good thing.
Re: (Score:2)
You mean C, don't you?
Re: (Score:2)
No, he means C# .net
Re: need small language and large built-in library (Score:2)
We need an environment where people use the right language for the job.
Or in the world we have now: the mountains of c, python and javascript that AI have trained on.
But that is what Swift is... (Score:1)
Sometime, if we are lucky, we will get a small programming language that does not collect new features every year just for the sake of progress
Swift does get new features every year but I would argue most have been good quality of life, or quality of code improvements. Especially the latest changes around concurrency are really good.
Avoiding the pyramid of 500 third-party packages for a mid-sized application is a good thing.
Totally agree but that is where Swift has been really great! It is VERY practical
Flutter/Dart? (Score:2)
Flutter/Dart is Google's proposal for a cross platform UI toolkit (and it has iOS support, macOS, with Android (of course), and Windows and Linux). It will be interesting to see how/if swift can manage to feel native on alternative platforms such as Android.
Re: (Score:1)
I was the product manager on a team that was using ReactJS, for cross-platform compatibility. It made the iPhone app look completely non-iPhone App like, and pretty shitty in general.
It would have been a lot better if they had made an ACTUAL iOS app.
Don't fight the platform (Score:2)
More generally, don't fight the platform. Use whatever the recommended language and IDE is for the user interface. Use portable C/C++ code for the app's functionality. Native look and feel everywhere. Common behavior everywhere.
Re: (Score:2)
Except this wouldn't actually solve this. You'd be able to share the business logic, which would be a benefit. But you wouldn't be able to share any of the UI, system, or OS interaction code which is where all the incompatibilities come. If you just wanted to share business logic, there were already ways you could do that (write it in C would be one way).
Also, if they really wanted to do that, they should consider going the opposite way and bringing Kotlin to Swift. Kotlin also has a significant server
To be honest ... (Score:2)
To be honest. Some applications are so trivial. So unlikely to generate much revenue. That the lowest common denominator approach is warranted.
Personally I like to separate UI from app functionality and use native for the former and shared C/C++ for the latter. Proper look and feel, and common behavior. But I have a tendency to over engineer things and I grudgingly accept some projects just don't warrant the effort.