Swift on Android? | Hacker News Reader

Swift on Android?

macrumors.com

45 pointsausjke31 comments

Some people seem to think that getting swift on android would solve the portability problem of apps. Don't be mistaken, if you are going for the native experience, you will still have to write your ui and io layers twice, since there won't be a UIKit or CoreFoundation on android. (And even if someone made a uikit-esque translation layer, android's activities+intents+services model is not a 1:1 mapping to uiviewcontrollers...)

You still use same language (that is not java) for everything else and that can be cross platform.

Also for games this should be even better since you will just draw on surface mostly- that problem is already solved by Haxe language with great success however.

Which means OpenGL, as the 2D API is a in memory framebuffer, back to the days of 8 and 16 bit programming.

Using the same language (Swift) is a great advantage. Java has reached the retirement age, it's time for a better language.

"for a better language" that interoperate seamlessly with existing java apis and codebases, and had android restrictions in mind during the design phase.

Fortunately, this language already exists

https://kotlinlang.org/ http://try.kotlinlang.org/

Kotlin doesn't solve any problems for Google from a legal perspective (for example, moving away from the Java ecosystem because of the protracted litigation from Oracle).

Google created those problems in first place, by trying not to pay Sun.

"Moving away from the jvm" means getting rid of the Android ecosystem. That would be the smartest project management decision since the codebase of Netscape 4 was thrown away

Most such attempts run up against the particular way that a Java-like runtime is used in Android: The max heap size is tiny compared to desktop, nevermind server Java defaults. You have LOTS of instances of the runtime that depend on the Zygote and copy-on-write so as not to eat all of memory. Component lifecycle has to be handled or you will hate life. Inter-component and inter-process communication and cooperation are deeply rooted in the Android architecture. Lots of the Android OS is built in Java, and takes advantage of Android's runtime limitations and capabilities. In other words, unless you replace Java with another JVM language, you are implying a different OS, not Android with a "better" language.

Lots of truth here, a new language isn't going to solve things.

React Native is probably the closest that you're going to get.

I think outside NDK users,most developers aren't aware how it is constrained and full of hurdles.

This article is more like a comment and summary on the original article, which was in NextWeb:

http://thenextweb.com/dd/2016/04/07/google-facebook-uber-swi...

To be fair, macrumors did give credit to NextWeb. But I still recommend the original because it has more information and because I prefer giving credit to the people who actually create the original content rather than the me-too articles.

This is bullshit based on anonymous "Sources" of which we are not told their credibility or how they are connected to Android or Google. Anyone that thinks Google is going to rewrite the millions of lines of Android Java framework in a non-JVM language just doesn't know what they're talking about. I suppose it could be used for unmanaged native code, meaning games, but that's mostly already cross platform via things like Unity.

The automated translation of Java source to Swift would be trivial. Google already has a Java->Objective C translator. Once the source was automatically translated the developers can start optimizing. The days of Java being the only first class language on Android are numbered.

If somebody figures out how to compile Swift to JVM or Dalvik byte code then I'll believe it's happening.

I think it's more likely that Google will support Swift on NDK. That's quite doable - there are already many other languages (C, C++, Rust, Haskell, Python) that will work on Android via NDK. And Swift is LLVM-based, just like the existing C++ and Rust toolchains.

If you've ever done NDK programming, you'll know that this brings with it it's own set of hassles; it's not at all like writing Android apps in Java. But it could be quite useful for companies who have "headless" business logic that they want to share between iOS and Android.

I find this very hard to believe. One would expect Google to adopt Go, or perhaps Dart, since they were developed by Google.

Bruce Miller, an Engineer at Google, answers this here:

https://www.quora.com/Why-wouldnt-Google-use-Go-instead-of-J...

Despite Android's market share, some developers still write for iOS first and port to Android later (if at all). By moving to Swift, Google could reduce this friction and help prevent Android from being a second-class citizen among developers.

Also, Go is a great language for writing networked systems software in. But it's not necessarily great for GUI-based application development. And there really hasn't been much effort to change that, from the Go team or externally.

Go was originally written to replace the things C++ is usually used for. There are many other languages which work well for higher level uses. I think the motivation behind creating Go was there weren't many new languages made to make writing systems level software easier.

> Go was originally written to replace the things C++ is usually used for.

Go was originally written to replace the things C++ is usually used for within Google. C++ is used for many other things (embedded programming, games and graphics engines, etc.) that it doesn't seem like the Go authors were targeting. In fact, Pike said "we were pleased and a little surprised to find [Go] suitable for general-purpose programming" [1]. This suggests they weren't intending to create an across-the-board replacement of C++, since C++ is certainly a general-purpose programming language. Perhaps to a fault.

> I think the motivation behind creating Go was there weren't many new languages made to make writing systems level software easier.

The authors ran into issues describing it as a "systems language," since it's not really a systems language in the conventional sense (i.e., low-level language with fine-grained control over hardware and memory) [1]. Because C++ is used for conventional systems programming, and the Go team described Go as a C++ replacement, this probably ended up doing Go's reputation more harm than good.

Pike and the Go team have essentially redefined "systems language" for their purpose, as a language targeting servers and interconnected systems. And it excels there.

[1] http://www.informit.com/articles/article.aspx?p=1623555

[2] https://en.wikipedia.org/wiki/System_programming

Many developers do that because that's where the money is.

While Android has a larger market share Apple brings more money through app sales than Android.

The Android ecosystem is also utterly segmented which means you have to support multiple versions of the API and a very wide range of hardware profiles which turns developing a consistent UX into a nightmare.

On top of that you have to deal with emerging markets that sell android devices that don't even come with a play store and Google's APIs.

I think you overestimate the extent to which Google acts as a top-down, unified company.

It took about 5 years to get a single unified Google login. It took another couple before every property supported multi-login. GWT and Angular.js are both Google projects, but the vast majority of Google production services use Closure instead, and the Chrome team is pushing Polymer. AppEngine is used extensively internally, but the largest public-facing service on AppEngine that I know of is Fiber, which is totally dwarfed by the largest external customer of AppEngine (SnapChat).

[At least, it was when I left in 2014; there was gonna be a big push into Cloud, so it's possible several other services have rewritten on top of GCP.]

Neither Go nor Dart are JVM languages. Both would have to be adapted to run in ART. It is difficult for Android to have more than one app runtime for apps that make more than trivial use of Android's framework.

"Hello, world" on Android: https://github.com/apple/swift/blob/master/docs/Android.md

I wonder if, given the giant set of existing Android libraries written in Java, they'd need to create a swift <-> java FFI.

Maybe we'll get JSwift running on the jvm so we can just import anything that compiles to bytecode.

This story is 3 weeks old, was there a new update to this?

nope

more likely a move to kotlin or C# than swift imo.

This article (which contains nothing but speculation) has been posted here already at least once.

Reply on news.ycombinator.com