Getting Started with Swift on Android | Hacker News Reader

Getting Started with Swift on Android

github.com

65 pointsantfarm29 comments

"Getting Started with Swift on Android"

"FAQ [...]

Does this mean I can write Android applications in Swift?

No."

To clarify - you cannot currently write GUI applications for Android in Swift, because no UI toolkit exists for this task at the moment.

Well, thanks. I kind of figured it out, but still I believe it should be stated explicitly, because it looks quite confusing

Consider it's a getting started, not a develop android apps with swift. Then it's explained in the FAQ, IMHO it makes sense.

Not explicitly, in the sense that it tells me what can't be done instead of what can

Getting started is a phrase often used for tutorials. Tutorials most often are for things that one can actually do.

Which begs the question of why anyone thinks it's worth getting started if the outcome isn't something that anyone could do anything with.

Aha: it's "(getting started with swift) on android", not "getting started with (swift on android)".

I personaly hope Google will replace Java with Dart at some point - it will be easier to switch for average Java dev (syntax) and there is already Dart for Android project - Flutter

Flutter is a very very very long way from being a replacement for the native UI kit though.

It is stuck in an uncanny valley where the effects sorta looks like those of the platform, but are different enough to make the discrepencies very visible.

A simple list skips a lot of frames on my Nexus 6P, I can't imagine what I will look like on the regular user's phone.

None of the samples do anything interesting, they are just very tiny fragments of UI and even then there are many things missing.

Bringing Flutter up to speed with the native UI toolkit would demand a titanic amount of work

Has anybody used Silver ? http://www.elementscompiler.com/elements/silver/ It seems to offer a working Swift compiler which can also create android apps (and ios and .net)

I haven't used it yet, but intrigued by your comment I did a bit of research, and here's the gist of what I have understood: the company behind Silver is RemObjects, and they offer a cross-platform compiler suite called Elements, which supports three languages: C#, Oxygene (their own creation, apparently heavily influenced by Object Pascal) and now Silver, which is Swift with "a few features" added to bring it in line with the other two languages. They're trying to downplay the additions for obvious reasons, but they sound pretty hefty to me: Exception Handling, Partial/Static Classes, External/Inline Functions, Events etc. Imagine what Rob Pike would say if someone came along and added all that to Go ;) (see https://docs.elementscompiler.com/ and https://docs.elementscompiler.com/Silver/LanguageExtensions/ for details).

That being said, the compiler (and IDE for Mac) are freely available, so you can try it out. RemObjects have been around for a while and I was pleased with their products back in the day when I was developing in Delphi, so I'm sure Elements is a solid product as well, just maybe not what you are expecting...

Is there a reason Google didn't make the UI framework language agnostic? Had they coded the Framework API in C/C++ they could easily have made any language a first class citizen by supplying the necessary API wrappers/facades for the languages that needed it.

They chose Java because it made sense at the time. Most mobile apps before the current smartphone era were Java based using j2me (or whatever it was called). Just like most iOS developers were existing Mac developers using Obj-C.

Still don't know why they don't have hooks for other languages. Your option is to use NDK (I think haven't coded for Android in ages) for those that insisted on C/++

I'm aware of why they selected Java (mindshare) for their development platform, but that doesn't exactly explain why they coded the majority of their framework in Java. Had they used C/C++ the interoperability with other languages for UI based applications would have been trivial with the respective API wrappers in place.

But they do, just those APIs aren't exposed to other NDK applications.

For example, the 2D rendering engine is implemented in Skia.

Symbian and PocketPC are much older than Android.

"Most mobile apps before the current smartphone era were Java based using j2me"

Which was routinely criticized for being absolutely terrible, second only to BREW.

The Android team is politically against anything but Java.

I bet if they weren't forced by game developers to add the NDK on Android 2.2, the NDK wouldn't exist at all.

Even today, Android Studio barely offers a comparable C++ experience to what xCode and Visual Studio do and Gradle support for NDK is still work-in-progress that doesn't support all ndk-build features.

Android Studio has C/C++ support courtesy of CLion. Are you implying that CLion is really inferior to xCode? I find that very hard to believe. As for CLion and VS, well, last time I installed VS 2015 it sprayed 30GB of files all over my SSD. To say VS 2015 is a pig would be an understatement.

Yes I am, the C++ developer experience in Android Studio is a second class one, even when compared to xCode.

Since I also have Windows customers I have VS anyway on my hard disk. Microsoft is offering better support for Android development in C++ that Google seems capable of doing.

Android Studio is unable to make use of And and ndk-build like Visual Studio does, offers a crippled experience in terms of intellisense and debugging tools versus Visual Studio support for Android NDK development.

Also the Android team seems unable to make Gradle match 1:1 the ndk-build features. Still catching up, after deprecating Eclipse CDT + ndk-build almost 2 years ago.

The first plan was to support 3 languages :

-Javascript for small apps such as homescreen widgets -Java for more complete apps -C++ for the cases where its power is necessary.

Along the way they dropped Javascript since they decided that Java was not too bothersome to write Android apps in, even small ones. They have also restricted C++ to the NDK.

These decisions have been taken a long time ago though. If somebody were to create Android today, the landscape has changed a lot since then.

Swift, Kotlin, Rust, C#, ... there are a lot of new developments.

Android port has been merged into the swift code-base:

https://github.com/apple/swift/pull/1442

Is it just 'Rumour' at this point Android will officially adopt Swift as their primary application development language?

I'd actually like this. Swift is a really great language, even though them adopting it is very unlikely. I think Google is more likely to keep Java than it is to adopt Swift, or even Go or Kotlin.

Yes. There are probably internal discussions about the future of the platform, but we have no official information.

This 'android port of swift' only allows to target the NDK, not to build an Android app from A to Z.

This is exciting! I can only wonder if Oracle has been enough trouble to pester Google into using a language such as Swift.

I pity the fool JNI

Would this work to create games for android with OpenGL?

Reply on news.ycombinator.com