
Swift Ported to Android - adamjernst
https://github.com/apple/swift/pull/1442
======
V-2
Surprised noone mentions Kotlin. It's quite Swift-like, backed by JetBrains
(Android Studio is based on their IntelliJ Idea), and 1.0 has only just been
released. It has full interoperability with Java.

Given the above, I don't see much point in using Swift, unless it's one of
these projects that are about proving a point (nothing wrong with that and
often very interesting).

~~~
Fargren
I love Kotlin, but being able to develop libraries in one language and use
them in both Android and iOS is huge. I have been using J2Objc for this until
now, and while it's a great tool, it forces me to use Java, which I don't
love. I would prefer being able to use Kotlin on iOS, but using Swift for
Android development is a great boon.

~~~
moonchrome
>but being able to develop libraries in one language and use them in both
Android and iOS is huge

I have no doubt that there are mobile only apps that would find this valuable
- but swift is still _only_ linux/android and osx/ios - if you want truly
portable code - that can compile to browser/mobile/server/desktop you're stuck
with C++ for the foreseeable future.

~~~
eggy
I've tried Haxe, Racket, TCL/tk, MOAI (Lua based), and others, but I am now
using 8th, a Forth-like language that compiles to Android, iOS, Windows, OSX
and Linux [1]. The only downside is that I still need a Mac to publish iOS
apps. For Android, Windows and Linux, I am good to go. It uses the JUCE
library for gui implementation. I have made two toy apps for Android so far,
and I am still learning. It has a good library so far, but some people find
Forth difficult. I find it concise, expressive and still readable after 6
months. The shortness makes code review a breeze.

    
    
      [1] http://8th-dev.com/

~~~
andybak
What a strange beast! A closed source language is always a tricky sell. Forth
is never an easy sell in itself (unless you've already been bitten by the bug
;-) in which case it's a wonderful bonus). The tutorial is PDF only - which
just seems a bit odd.

I'm intrigued by 8th - in a good way - and happy you've introduced me to it -
but I do wonder what kind of uptake something like this will get.

~~~
eggy
It is a bit odd, but I am rocking with it. I have done Java and NDK in C++
tutorials to get simple programs running, but nothing original, or beyond what
the tutorial provided. With 8th, I can whip up something quick with a GUI,
using the sensors and other libs it comes with, and deploy it. It looks the
same on Windows, Android and Linux. The developer makes him self available,
and quite honestly, the code is succinct enough and the documentation good
enough that I only asked a lot the first week. You should give it a try. I am
by no means a 'Forth programmer', and 8th is not a compliant Forth.

------
manojlds
Interesting, in the context of Xamarin acquisition by Microsoft. Swift can
very well spoil C#'s steam.

~~~
miguelrochefort
Swift isn't a significant improvement over C#. Also, keep in mind that C#
benefits from the whole Microsoft ecosystem, which includes Visual Studio.

Beyond the language, what's even more important is the application model.
That's where frameworks like React Native have the edge. This might change if
Microsoft upgrades Xamarin.Forms into full-blown Universal Windows App support
(think WPF on iOS and Android).

~~~
alblue
You might just be looking at the language from a syntax perspective. However
the two are very different in the way that you compile and run them. In C# the
code is translated into a custom bytecode (IR) and then the CLR is used to
execute that and manage the memory through GC.

In Swift's case it compiles down to native processor code instructions and can
have optimisations applied ahead of time. This allows the app to run faster
than a VM+JIT would do and therefore longer batter management. The overhead of
the runtime is a lot lower since memory is ref counted and doesn't need to run
GC periodically.

~~~
pjmlp
C# has always had support to AOT to native code since the early days via ngen.
The only issue was that more effort was spent in the JIT compiler and ngen
requires dynamic linking.

C# is compiled to native code on Windows Phone since version 8.

The C# extensions for Singularity (Sing#) and Midori (System C#) generate
static binaries. Work which served as starting point to MDIL on WP 8.x and
.NET Native.

The new .NET Native compiler even exposes SIMD.

Mono also supports AOT compilation since a long time.

As always language != implementation.

------
ungzd
Why Android requires special support? Isn't it just linux with quite standard
libc and ABI to interact with Java counterpart?

~~~
sspiff
If you look at the changes, you'll see most things are pretty simple:

* CMake files are expanded to handle an Android target.

* Code that checks for specific defines or values like __FREEBSD__ || __LINUX__ now have an added condition to also check for __ANDROID__.

* Some tooling scripts to integrate adb into the Swift SDK.

* Some minor fixes elsewhere.

So, special support is a really minimal set of changes that any platform would
need.

~~~
ewmailing
In addition to the Bionic short-comings already mentioned here, there appears
to be other work to deal with the fact that things must be cross-compiled in a
way that you can build a compiler for your host machine, but generate Android
binaries (and for each architecture).

Also, there are also a bunch of support things for libICU which is not an
official component on Android we are allowed.

------
bsimpson
UI in Swift is heavily tied to Cocoa, right? What tools exist to draw UI in
Swift on another platform?

~~~
mikeash
Swift doesn't have the slightest concept of UI. If you want to do UI work in
Swift, you use whatever UI frameworks are available on your target platform.
Since Swift interoperates very nicely with C and Objective-C, those frameworks
can be written in those languages and still be usable from Swift. On OS X the
framework happens to be Cocoa, but Swift isn't in any way tied to it.

On Android, Swift will likely be in the same position as the NDK, which isn't
a great place to be for UI, but it's doable. You'll be able to make the same
UI calls you'd make from C code.

~~~
azinman2
And that there in is an issue. Android will never have a complete ndk API
parity with Java. They've made this clear, and would be difficult since the
Java API is implemented in Java (it's not a wrapper of ndk).

~~~
fotidim
Don't expect to write entires Android apps in Swift. The best thing we can
hope for is sharing crossplatform code among iOS, Android etc. And with
Foundation ported this is fair amount of code.

------
akerro
Interesting, but even Apple doesn't use switf on iOS. So is there really a
point?

~~~
hnbroseph
On that note, MS doesn't use C# that much outside of websites. Maybe people
should take the hint there as well.

~~~
V-2
My impression was that Visual Studio's UI (not all of it, but presentation
layer) is C# / WPF.

