Apple's Swift Coding Language Is Working On Android Support (9to5google.com) 25
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:1)
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 us
Re: (Score:2)
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)
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.
To be honest ... (Score:2)
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: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: (Score:2)
And stupid me thought he was talking about Swift, like the article ...
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:1)
We need an environment where people use the right language for the job.
This is the dumbest take. "People need to use the right tool for the job!" Here's the thing, dipshit: there is no objective 'best tool for the job". People use what they're comfortable using or what they have forced on them.
Christ, this is just as bad as the "it's just another tool in the toolbox" like you morons throw out there to avoid thinking. Some "tools" are so obviously useless that they shouldn't even be classified as tools. Some tools are so shit that the world would be better off had they nev
Re: (Score:1)
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: (Score:3)
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 c
Flutter/Dart? (Score:2)
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)
It seems they want to integrate with Android's Kotlin/Java SDK.
So it will be "native" by default.