
Running Swift code on Android - Ecco
http://romain.goyet.com/articles/running_swift_code_on_android/
======
e28eta
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/S...](https://github.com/remobjects/SwiftBaseLibrary/blob/master/Source/Array.swift)

~~~
j_s
Wow, going after Xamarin (prioritizing iPhone developers instead of
Microsofties) and only asking for donations!

This is a great find; thanks for the link.

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

~~~
oblio
Have you by any chance used JavaFXPorts?
[http://docs.gluonhq.com/javafxports/](http://docs.gluonhq.com/javafxports/)

~~~
philbarr
No I haven't I'm afraid. But it's definitely something to look at from the
RoboVM world. Bit overloaded with work at the moment unfortunately.

And just the use of the words JavaFX and iOS in the same sentence seems weird!
More than happy to be proved wrong though....

------
jevinskie
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
That's a very smart idea! I might give this a try, thanks :)

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

      > 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 :)

~~~
SneakerXZ
You need to write your bridging yourself and it might not always be possible
because you need to bridge Rust <-> Objective-C.

Swift with Objective-C is bridged automatically.

~~~
anonova
I use rust with ios, and my bridging header just includes a single C header
file. I don't see how it's any more complicated than using a C library.

~~~
SneakerXZ
Yeah, it bridges to C so you need to build another bridge to have nice
Objective-C API. Not mentioning, you will have hard times calling Objective-C
API from Rust.

You don't have this problem with Swift.

~~~
autoreleasepool
You don't need to involve Objective-C to use a C API in Swift. You can call C
functions directly in Swift and wrap them in a nice Swift API.

~~~
SneakerXZ
I know that but if I decide to use Rust instead of Swift, why would I be
wrapping Rust in Swift through C? And still it doesn't solve a problem how
Rust can call anything from Cocoa or my existing code.

~~~
autoreleasepool
> if I decide to use Rust instead of Swift, why would I be wrapping Rust in
> Swift through C?

To avoid the unnecessary overhead of dynamically dispatched Objective-C method
calls.

To me, it seems more sensible to go

    
    
      Rust -> C -> Swift
    

vs

    
    
      Rust -> C -> Objective-C -> Swift

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

~~~
TheMakeA
> Yep, it is easier to make languages target DEX than suffer the pain of the
> NDK.

So what does this look like in practice? Genuinely curious :-)

~~~
on_and_off
[https://kotlinlang.org/](https://kotlinlang.org/)

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

------
randyrand
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
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!

------
Alupis
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
Practical research often starts as academic exercise.

~~~
Alupis
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?

~~~
BinaryIdiot
> 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
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
> 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
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
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).

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

------
tpaksoy
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
How would it resolve the differences in types without mangling?

------
alediaferia
This is awesome resource. Thank you for sharing.

~~~
Ecco
You're welcome!

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

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

