Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Android Programming Apple

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

Apple's Swift Coding Language Is Working On Android Support

Comments Filter:
  • you know why? (Score:3, Insightful)

    by Anonymous Coward on Thursday June 26, 2025 @09:16PM (#65479030)

    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)

      by registrations_suck ( 1075251 ) on Thursday June 26, 2025 @09:32PM (#65479056)

      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.

    • by AuMatar ( 183847 )

      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

      • 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.

      • by dgatwood ( 11270 )

        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...

      • Only a fool or an expert would write a c backend to an app. And there aren't many experts...
      • by keltor ( 99721 ) *
        I've yet to see Kotlin outside of Android Apps. I've heard some Fintech startups were using it, but I have not seen it despite my job being Fintech consulting. What I do see is Clojure.

        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. 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.
  • by will4 ( 7250692 ) on Thursday June 26, 2025 @09:28PM (#65479044)

    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.

    • You mean C, don't you?

    • 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.

      • 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.

        • 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

          • There are several Python environments for the iPhone/iOS.
            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 .NET languages), and real scripting languages.
            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

  • Flutter/Dart? (Score:4, Informative)

    by CommunityMember ( 6662188 ) on Thursday June 26, 2025 @11:40PM (#65479208)
    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.
    • 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 :)

    • It seems they want to integrate with Android's Kotlin/Java SDK.
      So it will be "native" by default.

  • I've been using Kotlin recently and quite like it. Dunno why Apple doesn't just adapt it instead of making yet another language.
    • 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.

  • 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.

  • 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/

  • 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.

Almost anything derogatory you could say about today's software design would be accurate. -- K.E. Iverson

Working...