


Apple's Swift Coding Language Is Working On Android Support (9to5google.com) 44
Apple's Swift programming language is expanding official support to Android through a new "Android Working Group" which will improve compatibility, integration, and tooling. "As it stands today, Android apps are generally coded in Kotlin, but Apple is looking to provide its Swift coding language as an alternative," notes 9to5Google. "Apple first launched its coding language back in 2014 with its own platforms in mind, but currently also supports Windows and Linux officially." From the report: 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
- 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
you know why? (Score:3, Insightful)
Because a whole lot of people don't want to bother maintaining two code bases, so they use some kind of shitty compatibility layer on iOS which means the iOS apps suck ass. This at least would make the iOS apps work properly and if there are any deficiencies they would be on the Android side.
The funny thing is, the iOS APIs are insanely robust but don't get used that much because these short-sighted idiots want to program to the lowest common denominator. Not sure how much this helps if, say, you want to use Core Data on iOS. That's a pretty fundamental architectural decision and can't be papered over by just supporting Android with Swift.
Re:you know why? (Score:4, Interesting)
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:5, Insightful)
Re: (Score:2)
Re: (Score:1)
Maybe.
But generally-speaking, I have low expectations of people.
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
Re: (Score:2)
Swift is not iOS and Mac only.
It was "all platforms" nearly from the beginning.
A standard App has not much to integrate with the system.
How hard can it be to open a file? Obviously if one ports a language, he would add at least a few libraries on top of the foreign system calls that adapt them to the original OS.
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 side use that's growing (mainly by replacing Java), Swift is iOS and Mac only. They'll find a lot more people willing to learn Kotlin than Swift. Of course Apple won't consider that due to NIH and control issues.
Nothing inherently prevents Apple from porting SwiftUI to Android. It would probably be enormous, but...
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
I've seen Swift backends in production serving millions of people (billions even.)
Neither is a particularly difficult to learn Language and TBH, I suspect anyone who knows one can learn the other with minimal investment.
To be honest ... (Score:3)
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.
need small language and large built-in library (Score:3)
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: (Score:3)
And stupid me thought he was talking about Swift, like the article ...
Re:need small language and large built-in library (Score:4, Insightful)
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.
Re: (Score:2)
Listen, you ruptured ass pimple, I too come equipped with an arsenal of synthetic rage so unhinged that it won the Iowa caucus—twice.
You throw around the word "tool" like you’re not the showroom model for misused implements. You’re the kind of tool that comes with no instructions, stripped threads, and a recall notice for psychological damage.
You’re not making a point—you’re making a public case for adult supervision. Now go sit back down in whatever Reddit thread spawned
Re: need small language and large built-in library (Score:4, Insightful)
On consumer computers and workstations and servers: nearly any language is the right language for the job.
Specialized languages, you only need under special circumstances, where speed, tightness of the code, code that can access peripherals, special CPUs or memory constraints matter.
For anything else, what high level language you use is a matter of taste and/or skill and/or available libraries.
Some people would e.g. not like to write a REST server from scratch. But rather would use a library. Others won't care.
Swift is a general purpose language (nearly) on par with Dart. Dart and Swift are basically the 'better' Java/C# - language wise, not talking about libraries, frameworks and infrastructure.
Re: (Score:2)
Our idea of "right tool for the job" differ. I see it as a balance of manpower, execution speed and target environment. Not strictly "I can write REST in C, so it is the right tool for the job".
python is 100% better if you need to get something easy done quickly, it's also useful just as a user to run other people's stuff, like their AI models for example
C/C++ is better if you need something that is performant and it's worth spending time on
Shell scripts are the best if you need to work with the filesystem
Re: (Score:2)
There are several Python environments for the iPhone/iOS. .NET languages), and real scripting languages.
With the Python game library based on SDL, it is most likely easy to write games even for iOS.
On the other hand there are tools like Unity, wich mostly scripted in C# (which is remotely similar to C++ -- and I would assume you can use managed C++ as well, and other
Then there is the portable Godot Game Engine, that also supports iOS. It uses GDScript as language, which is not really a scripting language bu
Re: (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
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 now to build a medium to large application with only handful of third party packages. That was very much not the case 5-10 years ago. If you look at any modern Swift app it looks nothing like the swirl of madness that is a modern React application.
???
Other than the SwiftUI framework, approximately everything that's in Swift was in Objective-C 5–10 years ago. It was very practical to build a medium-to-large app back then with few or no third-party packages, too. React is almost always a mistake for native apps.
Swift is more advanced... (Score:1)
Other than the SwiftUI framework, approximately everything that's in Swift was in Objective-C 5â"10 years ago.
Not the concurrency framework (GCD is not the same), SwiftUI doesn't have things like Swift structs, only supports integers enums, Generics, no guard statement. Also finer grained access control.
Mind you they have improved Objective-C over the years by bringing in some Swift features as Swift improved! Like nullability annotations.
I still do like Objective-C as a language but even with Swifts
Re: (Score:2)
Flutter/Dart? (Score:4, Informative)
Re: Flutter/Dart? (Score:2)
I've been a fan of Dart for over a decade, I haven't used Flutter much but if I was building an app it's obviously where I would start :)
Re: (Score:2)
Re: (Score:2)
I used to rock a Nokia N900. The idea of a phone with a full Linux setup with X11 and stuff (including a Firefox-derived browser) seems great at first but the software stack was full of binary blobs (including but not limited to GPU driver blobs, PulseAudio blobs, power management blobs, cellular blobs and hardware related blobs) that made actually updating the software to anything modern nearly impossible.
At the time my N900 bit the dust, it was impossible to even visit a large chunk of the web because the
Re: (Score:2)
It seems they want to integrate with Android's Kotlin/Java SDK.
So it will be "native" by default.
Is it better than Kotlin? (Score:2)
Re: (Score:3)
I've been using Kotlin recently and quite like it. Dunno why Apple doesn't just adapt it instead of making yet another language.
Other than the linear flow of time? Swift was first developed by Apple starting in 2010 internally before a general release in 2014. Kotlin was first developed in 2010 with the 1.0 release in 2016 before Google adopted it in 2019. While the Reality Distortion Field is powerful, it does not allow Apple to go back in time and change things knowing future events. It is the same answer why Apple didn't adopt USB-C connectors instead of Lightning connectors.
Obligatory– (Score:2)
Beleaguered Apple spreads programming language legs in hope of overcoming Apple Doesn't Make Serious Computers; Only Good For Games But Isn't A Gaming System' image.
Already here for a while (Score:1)
Swift on Android is already here. Its called skip.tools.
We have been able to do this for about 8 months now - https://skip.tools/blog/native-swift-on-android-1/
Compatibility layers usually suck (Score:2)
Anyone who has done development in a cross-platform system like Xamarin or Qt can tell you that, while these systems do provide some help, there are a million little platform-specific details that still have to be handled. In the end, it's often true that using these cross-platform tools results in an inferior-quality product on *every* platform.