16 ms·

Running Swift code on Android

196 points by Ecco 11y ago

alediaferia 11y ago
This is awesome resource. Thank you for sharing.
- Ecco 11y ago
  You're welcome!
Alupis 11y ago
Just curious why someone would want to do this? According to the article, you would have to use the NDK to make this work and... > And of course since we're missing the SwiftCore library this is restricted to a small subset of Swift. So, it seems more of an academic exercise than a practical thing?
- AndrewKemendo 11y ago
  Practical research often starts as academic exercise.
  - Alupis 11y ago
    True - but is there a compelling reason we'd want Swift running on Android? I mean, we can say we want it just because (and maybe that's just fine), but is there a stronger reason to want it given many frameworks for mobile apps already compile into more-or-less native apps for each device?
    - melling 11y ago
      Isn't the compelling reason always write once, run everywhere? Pick your favorite language and wouldn't you want to use that on Android and iOS? Swift is fast becoming the standard for iOS development. So, if you want to support Android too, any effort you can reuse is a win.
    - gorena 11y ago
      Not sure of the state of Scala on Android, but having a language that actually has real closures is appealing. To say nothing of ADTs, nullability, etc...
      - jsmith0295 11y ago
        From my understanding it isn't that great. But Kotlin works well and it's far better at those things than Java. Theres also Clojure but I don't know how well supported it is. Running both of those on iOS is also possible via RoboVM - no need to wait for a good Swift on Android solution.
        sandGorgon 11y ago
        are you using Kotlin personally ? I have heard a lot of good things about Kotlin (especially the fact that Kotlin code seamlessly works with existing java code). But not sure if I should wait till 1.0
        jsmith0295 11y ago
        I haven't for any real projects, I've only played around with it. But it seems like there's a decent number of people using it today, so my guess would be that waiting isn't necessary. If I were working on a cross platform mobile/web app today, I'd probably choose Kotlin.
    - BinaryIdiot 11y ago
      > but is there a compelling reason we'd want Swift running on Android? Yes because it's a language of higher level than C++ that can theoretically run on all platforms. Now I don't know about you but I'd much rather write the core of my software in a language that can be used on all platforms. This way I can leverage the same business logic everywhere and just have different, dedicated logic for UIs. I once tried to use C++ for this but the STL is supremely lacking in almost every way compared to the standard libraries that come with almost every other language. There just isn't much choice out there.
      - Alupis 11y ago
        Doesn't Java (what Android is already written in) provide that same benefit? Surely it's easier to get a basic JVM running on the iOS?
        BinaryIdiot 11y ago
        > Surely it's easier to get a basic JVM running on the iOS? Gah, I'm not sure how you'd do that and still be able to deploy an application to the iOS app store. I would imagine cross compiling Swift would be orders of magnitude easier.
        jsmith0295 11y ago
        You already can (sort of): http://RoboVM.com http://RoboVM.com It also works with other JVM languages such as Kotlin which is somewhat similar to Swift.
        BinaryIdiot 11y ago
        Oh I hadn't seen that one, that's actually pretty neat. Their pricing is...interesting though. Zero company support at all for the solo package which seems insane to me but other than that it's pretty cool. I wonder how well it works and how it supports third party Java libraries (if at all).
        pjmlp 11y ago
- Ecco 11y ago
  At this point, exactly! Now once Apple fully open-sources Swift, one might try to push things further.
AndrewKemendo 11y ago
This is really cool! Also interesting because of Microsoft's efforts to make iOS apps cross compatible with Windows through what I would expect is a similar process of cross-compiling and porting libraries.
jevinskie 11y ago
Have you thought about extracting the XAR archive of LLVM bitcode from Xcode 7.0+'s libswiftCore.dylib's __LLVM,__bundle section and linking your NDK project against that? You'll probably quickly run into linking dependencies outside of libswiftCore but perhaps you could A) stub out those missing dependencies B) build them from opensource.apple.com's CF, libobjc, etc projects or C) try and extract the __LLVM,__bundle's of the dependencies themselves. Rinse and repeat until everything works? :)
- Ecco 11y ago
  That's a very smart idea! I might give this a try, thanks :)
e28eta 11y ago
A coworker showed me this project, which does the same but also includes .NET and regular Java: http://elementscompiler.com/elements/silver/ http://elementscompiler.com/elements/silver/ Looking at their github, they appear to be making progress against re-implementing the Swift core library by binding to native classes with similar functionality. Like Arrays: https://github.com/remobjects/SwiftBaseLibrary/blob/master/Source/Array.swift https://github.com/remobjects/SwiftBaseLibrary/blob/master/S...
- j_s 11y ago
  Wow, going after Xamarin (prioritizing iPhone developers instead of Microsofties) and only asking for donations! This is a great find; thanks for the link.
  - mwcampbell 11y ago
    The other language front-ends (C# and Oxygene, their Pascal-based language) are commercial products. IMO, making the Swift front-end free indefinitely wasn't a smart business move, because now any savvy developer will just use the Swift front-end and not have to pay anything.
    - oblio 11y ago
      They could do what Qt does and charge for commercial addons. The Qt ones are pretty compelling: in-app purchases, for example. Plus I imagine that people using the other front ends are doing it for other reasons. C# and Pascal seem like enterprise moves (for the enterprises of >2005 and <2005).
  - philbarr 11y ago
    Let's not forget RoboVM, which is free (with paid options): https://robovm.com/ https://robovm.com/ I've used this before and was amazed how well it worked, particularly with libgdx: https://libgdx.badlogicgames.com/ https://libgdx.badlogicgames.com/ Not affiliated with either, by the way.
    - 11y ago
autoreleasepool 11y ago
I'm excited to see what happens in the Linux and BSD space when they finally open source Swift. I hope it finds an audience excited enough to help reimplement some of the functionality that will be missing from the lack of Apple APIs. It would be great to see an open source ecosystem for Swift, written in Swift on all *nix platforms.
- ajross 11y ago
  Honestly the desktop Linux (and BSD) world is rather better served by fun new language technologies than iOS or Android is. In an environment already targetted by Go and Rust and C++14 and Haskell and Erlang and Clojure and Scala and Perl6, what exactly does Swift (much less Java) really have to distinguish itself?
  - pjmlp 11y ago
    I also don't get it. What makes Swift better than other ML like languages for the mainstream developer is the tooling. e.g. Playgrounds and IDE support, and Apple forcing developers to adopt it (Objective-C had only a few WWDC sessions). For anything else, Haskell, OCaml, Rust and even F# are better options, as they are more mature, already portable and lots of libraries to choose from.
    - SneakerXZ 11y ago
      It is the other way around. Using Rust on iOS is pain. Using Swift is not pain because it is supported by Apple. So it is easier to bring my Swift code and knowledge that I use on iOS to other platforms because other platforms (Linux) don't require sophisticated tooling and support. So I can create apps in Swift for iOS but also backend in Swift for Linux and it is the major benefit.
      - steveklabnik 11y ago
        > Using Rust on iOS is pain. Is there something more specific than the general fact that cross-compilation is a bit involved at the moment? Just curious :)
pjmlp 11y ago
> Generally speaking, the NDK makes sense only for a small percentage of apps, so in the general case Google advise against trying to write a whole Android app using the NDK. Yep, it is easier to make languages target DEX than suffer the pain of the NDK. They not only advise against it, they make it really uncomfortable for us to use it (vs iOS and WP experience).
- mwcampbell 11y ago
  > Yep, it is easier to make languages target DEX than suffer the pain of the NDK. Why do you say that? Plenty of Android apps use non-trivial amounts of C/C++ code, and Dropbox has a tool called Djinni that can automatically generate JNI glue code. My guess is that if it's feasible to use pure Dex bytecode, then debugging is easier (because there's only one kind of call stack), memory can be managed more effectively (because the Dalvik/ART garbage collector can manage everything), and performance isn't impacted by the overhead of JNI. But I have nothing to back that up.
  - pjmlp 11y ago
    Yes there are plenty of apps that use a lot of C and C++, and we all join in the Anonymous NDK user group meetings. - The bug tracker is full of NDK issues - GDB works, eventually. If one has the right set of versions and mobile firmware - Integration with the first official IDE (Eclipse CDT) kind of worked, after one turned off indexers, did a few plugin customizations, and even then not really - When Android Studio was announced, silence ensued about NDK future. When Jetbrains announced CLion, there was the hope that it might came to Android Studio, still silent all the way up to Google IO 2015. - No pre-defined templates for mixed code applications - Even today Gradle support for NDK builds is flaky and not final. I am yet to be able to have the samples build out of the box. - The set of official C++ libraries is quite limited, most game related APIs are exposed. Even C++ libraries used by the Java layers like Skia are not exposed to the NDK. - By limiting NDK to a few basic POSIX APIs and Android game related APIs, everyone has to pack into their APK everything from JNI wrappers, image loaders, network access, the whole stuff. Now compare this with using C++ in iOS with help of Objective-C++ or on Windows Phone with help of C++/CX. First class tooling support, mixed debugging that works and no need to keep on writing wrappers. Even Microsoft's tooling for Android NDK is looking better than what Google does for their own platform. As for Djinni, I am yet to make it work on Windows.
nashashmi 11y ago
> Namely, instead of generating machine code targetting a specific architecture, LLVM generates assembly code for an imaginary machine, and then converts that intermediate representation to actual code for whichever architecture we're interested in. Why is that not possible for real-world languages? e.g. have one language which would include the specifics and complications of each language of the world and use it as intermediary for going back and forth to any language in the world.
- 0x0 11y ago
  It's not really that easy even in LLVM. Just like how real world languages don't map 1:1 to each other with all their idioms and untranslatable phrases, LLVM IR isn't a generic virtual machine. Instead, LLVM IR targets various overall architectures such as "64bit ARM processor" with "such-and-such ABI", so there is a limit to which processors the final assembly can be generated for.
tpaksoy 11y ago
Having to deal with mangled symbols is pretty annoying. Is it not possible to give a directive to the Swift compiler to disable mangling? Like rust has: #[no_mangle]
- gorena 11y ago
  How would it resolve the differences in types without mangling?
- plorkyeran 11y ago
  No. Currently to call Swift from C (or any other language that supports C-like things) you either have to use the mangled names or write an obj-c wrapper.
annacollins 11y ago
Presently I am a student of the Swift language and always in the back of my mind is the tedious thought that I will have to learn how to do this for ‘Android, one day. Having a compiler do this for you, makes sense. It would be a real blessing.
arsalanb 11y ago
Wow, sorry for slightly going on a tangent, but this is really cool. Imagine all the products had a single syntactic guide to follow. Underlying tech may differ, but a uniform process for creation. There are a million flaws with this, but just a thought. And can I just add — WOOOOOO!! Okay. Sorry.
maykr 11y ago
actually, you could build an Android command-line executable by using NDK target BUILD_EXECUTABLE. This way is imho clear for the demo purposes by leaving the JNI stuff out of scope
randyrand 11y ago
Why can't they just compile the swift core library into the executable? I imagine some things are architecture specific, like launching new threads (iOS calls down to objectiveC code which then handles the system call,etc). I imagine the problem is that you can't compile just the non architecture specific parts. Unless you wrote some code to strip out those parts...hmm is that possible? Also, how come it doesn't look like they had to provide the path to the runtime? Built into the compiler I guess?
MikeMJ 11y ago
With regard to LLVM, the concept of emitting code for a "virtual machine" that is then translated to code for any of several target machines is ancient. One example is the Pascal-P environment from the 1970s. The compiler emitted "P-code" that was then translated to machine language. Oddly enough, P-code was so close to the machine language of the PDP-11 that the translator was trivial!

196 points by Ecco 11y ago

alediaferia 11y ago

This is awesome resource. Thank you for sharing.

Ecco 11y ago
You're welcome!

Alupis 11y ago

Just curious why someone would want to do this? According to the article, you would have to use the NDK to make this work and... > And of course since we're missing the SwiftCore library this is restricted to a small subset of Swift. So, it seems more of an academic exercise than a practical thing?

AndrewKemendo 11y ago
Practical research often starts as academic exercise.
- Alupis 11y ago
  True - but is there a compelling reason we'd want Swift running on Android? I mean, we can say we want it just because (and maybe that's just fine), but is there a stronger reason to want it given many frameworks for mobile apps already compile into more-or-less native apps for each device?
  - melling 11y ago
    Isn't the compelling reason always write once, run everywhere? Pick your favorite language and wouldn't you want to use that on Android and iOS? Swift is fast becoming the standard for iOS development. So, if you want to support Android too, any effort you can reuse is a win.
  - gorena 11y ago
    Not sure of the state of Scala on Android, but having a language that actually has real closures is appealing. To say nothing of ADTs, nullability, etc...
    - jsmith0295 11y ago
      From my understanding it isn't that great. But Kotlin works well and it's far better at those things than Java. Theres also Clojure but I don't know how well supported it is. Running both of those on iOS is also possible via RoboVM - no need to wait for a good Swift on Android solution.
      - sandGorgon 11y ago
        are you using Kotlin personally ? I have heard a lot of good things about Kotlin (especially the fact that Kotlin code seamlessly works with existing java code). But not sure if I should wait till 1.0
        jsmith0295 11y ago
        I haven't for any real projects, I've only played around with it. But it seems like there's a decent number of people using it today, so my guess would be that waiting isn't necessary. If I were working on a cross platform mobile/web app today, I'd probably choose Kotlin.
  - BinaryIdiot 11y ago
    > but is there a compelling reason we'd want Swift running on Android? Yes because it's a language of higher level than C++ that can theoretically run on all platforms. Now I don't know about you but I'd much rather write the core of my software in a language that can be used on all platforms. This way I can leverage the same business logic everywhere and just have different, dedicated logic for UIs. I once tried to use C++ for this but the STL is supremely lacking in almost every way compared to the standard libraries that come with almost every other language. There just isn't much choice out there.
    - Alupis 11y ago
      Doesn't Java (what Android is already written in) provide that same benefit? Surely it's easier to get a basic JVM running on the iOS?
      - BinaryIdiot 11y ago
        > Surely it's easier to get a basic JVM running on the iOS? Gah, I'm not sure how you'd do that and still be able to deploy an application to the iOS app store. I would imagine cross compiling Swift would be orders of magnitude easier.
        jsmith0295 11y ago
        You already can (sort of): http://RoboVM.com http://RoboVM.com It also works with other JVM languages such as Kotlin which is somewhat similar to Swift.
        BinaryIdiot 11y ago
        Oh I hadn't seen that one, that's actually pretty neat. Their pricing is...interesting though. Zero company support at all for the solo package which seems insane to me but other than that it's pretty cool. I wonder how well it works and how it supports third party Java libraries (if at all).
        pjmlp 11y ago
Ecco 11y ago
At this point, exactly! Now once Apple fully open-sources Swift, one might try to push things further.

AndrewKemendo 11y ago

This is really cool! Also interesting because of Microsoft's efforts to make iOS apps cross compatible with Windows through what I would expect is a similar process of cross-compiling and porting libraries.

jevinskie 11y ago

Have you thought about extracting the XAR archive of LLVM bitcode from Xcode 7.0+'s libswiftCore.dylib's __LLVM,__bundle section and linking your NDK project against that? You'll probably quickly run into linking dependencies outside of libswiftCore but perhaps you could A) stub out those missing dependencies B) build them from opensource.apple.com's CF, libobjc, etc projects or C) try and extract the __LLVM,__bundle's of the dependencies themselves. Rinse and repeat until everything works? :)

Ecco 11y ago
That's a very smart idea! I might give this a try, thanks :)

e28eta 11y ago

A coworker showed me this project, which does the same but also includes .NET and regular Java: http://elementscompiler.com/elements/silver/ http://elementscompiler.com/elements/silver/ Looking at their github, they appear to be making progress against re-implementing the Swift core library by binding to native classes with similar functionality. Like Arrays: https://github.com/remobjects/SwiftBaseLibrary/blob/master/Source/Array.swift https://github.com/remobjects/SwiftBaseLibrary/blob/master/S...

j_s 11y ago
Wow, going after Xamarin (prioritizing iPhone developers instead of Microsofties) and only asking for donations! This is a great find; thanks for the link.
- mwcampbell 11y ago
  The other language front-ends (C# and Oxygene, their Pascal-based language) are commercial products. IMO, making the Swift front-end free indefinitely wasn't a smart business move, because now any savvy developer will just use the Swift front-end and not have to pay anything.
  - oblio 11y ago
    They could do what Qt does and charge for commercial addons. The Qt ones are pretty compelling: in-app purchases, for example. Plus I imagine that people using the other front ends are doing it for other reasons. C# and Pascal seem like enterprise moves (for the enterprises of >2005 and <2005).
- philbarr 11y ago
  Let's not forget RoboVM, which is free (with paid options): https://robovm.com/ https://robovm.com/ I've used this before and was amazed how well it worked, particularly with libgdx: https://libgdx.badlogicgames.com/ https://libgdx.badlogicgames.com/ Not affiliated with either, by the way.
  - 11y ago

autoreleasepool 11y ago

I'm excited to see what happens in the Linux and BSD space when they finally open source Swift. I hope it finds an audience excited enough to help reimplement some of the functionality that will be missing from the lack of Apple APIs. It would be great to see an open source ecosystem for Swift, written in Swift on all *nix platforms.

ajross 11y ago
Honestly the desktop Linux (and BSD) world is rather better served by fun new language technologies than iOS or Android is. In an environment already targetted by Go and Rust and C++14 and Haskell and Erlang and Clojure and Scala and Perl6, what exactly does Swift (much less Java) really have to distinguish itself?
- pjmlp 11y ago
  I also don't get it. What makes Swift better than other ML like languages for the mainstream developer is the tooling. e.g. Playgrounds and IDE support, and Apple forcing developers to adopt it (Objective-C had only a few WWDC sessions). For anything else, Haskell, OCaml, Rust and even F# are better options, as they are more mature, already portable and lots of libraries to choose from.
  - SneakerXZ 11y ago
    It is the other way around. Using Rust on iOS is pain. Using Swift is not pain because it is supported by Apple. So it is easier to bring my Swift code and knowledge that I use on iOS to other platforms because other platforms (Linux) don't require sophisticated tooling and support. So I can create apps in Swift for iOS but also backend in Swift for Linux and it is the major benefit.
    - steveklabnik 11y ago
      > Using Rust on iOS is pain. Is there something more specific than the general fact that cross-compilation is a bit involved at the moment? Just curious :)

pjmlp 11y ago

> Generally speaking, the NDK makes sense only for a small percentage of apps, so in the general case Google advise against trying to write a whole Android app using the NDK. Yep, it is easier to make languages target DEX than suffer the pain of the NDK. They not only advise against it, they make it really uncomfortable for us to use it (vs iOS and WP experience).

mwcampbell 11y ago
> Yep, it is easier to make languages target DEX than suffer the pain of the NDK. Why do you say that? Plenty of Android apps use non-trivial amounts of C/C++ code, and Dropbox has a tool called Djinni that can automatically generate JNI glue code. My guess is that if it's feasible to use pure Dex bytecode, then debugging is easier (because there's only one kind of call stack), memory can be managed more effectively (because the Dalvik/ART garbage collector can manage everything), and performance isn't impacted by the overhead of JNI. But I have nothing to back that up.
- pjmlp 11y ago
  Yes there are plenty of apps that use a lot of C and C++, and we all join in the Anonymous NDK user group meetings. - The bug tracker is full of NDK issues - GDB works, eventually. If one has the right set of versions and mobile firmware - Integration with the first official IDE (Eclipse CDT) kind of worked, after one turned off indexers, did a few plugin customizations, and even then not really - When Android Studio was announced, silence ensued about NDK future. When Jetbrains announced CLion, there was the hope that it might came to Android Studio, still silent all the way up to Google IO 2015. - No pre-defined templates for mixed code applications - Even today Gradle support for NDK builds is flaky and not final. I am yet to be able to have the samples build out of the box. - The set of official C++ libraries is quite limited, most game related APIs are exposed. Even C++ libraries used by the Java layers like Skia are not exposed to the NDK. - By limiting NDK to a few basic POSIX APIs and Android game related APIs, everyone has to pack into their APK everything from JNI wrappers, image loaders, network access, the whole stuff. Now compare this with using C++ in iOS with help of Objective-C++ or on Windows Phone with help of C++/CX. First class tooling support, mixed debugging that works and no need to keep on writing wrappers. Even Microsoft's tooling for Android NDK is looking better than what Google does for their own platform. As for Djinni, I am yet to make it work on Windows.

nashashmi 11y ago

> Namely, instead of generating machine code targetting a specific architecture, LLVM generates assembly code for an imaginary machine, and then converts that intermediate representation to actual code for whichever architecture we're interested in. Why is that not possible for real-world languages? e.g. have one language which would include the specifics and complications of each language of the world and use it as intermediary for going back and forth to any language in the world.

0x0 11y ago
It's not really that easy even in LLVM. Just like how real world languages don't map 1:1 to each other with all their idioms and untranslatable phrases, LLVM IR isn't a generic virtual machine. Instead, LLVM IR targets various overall architectures such as "64bit ARM processor" with "such-and-such ABI", so there is a limit to which processors the final assembly can be generated for.

tpaksoy 11y ago

Having to deal with mangled symbols is pretty annoying. Is it not possible to give a directive to the Swift compiler to disable mangling? Like rust has: #[no_mangle]

gorena 11y ago
How would it resolve the differences in types without mangling?
plorkyeran 11y ago
No. Currently to call Swift from C (or any other language that supports C-like things) you either have to use the mangled names or write an obj-c wrapper.

annacollins 11y ago

Presently I am a student of the Swift language and always in the back of my mind is the tedious thought that I will have to learn how to do this for ‘Android, one day. Having a compiler do this for you, makes sense. It would be a real blessing.

arsalanb 11y ago

Wow, sorry for slightly going on a tangent, but this is really cool. Imagine all the products had a single syntactic guide to follow. Underlying tech may differ, but a uniform process for creation. There are a million flaws with this, but just a thought. And can I just add — WOOOOOO!! Okay. Sorry.

maykr 11y ago

actually, you could build an Android command-line executable by using NDK target BUILD_EXECUTABLE. This way is imho clear for the demo purposes by leaving the JNI stuff out of scope

randyrand 11y ago

Why can't they just compile the swift core library into the executable? I imagine some things are architecture specific, like launching new threads (iOS calls down to objectiveC code which then handles the system call,etc). I imagine the problem is that you can't compile just the non architecture specific parts. Unless you wrote some code to strip out those parts...hmm is that possible? Also, how come it doesn't look like they had to provide the path to the runtime? Built into the compiler I guess?

MikeMJ 11y ago

With regard to LLVM, the concept of emitting code for a "virtual machine" that is then translated to code for any of several target machines is ancient. One example is the Pascal-P environment from the 1970s. The compiler emitted "P-code" that was then translated to machine language. Oddly enough, P-code was so close to the machine language of the PDP-11 that the translator was trivial!