9 ms·
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 release
by V-2 11y ago
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).
- kennywinker 11y agoTwo points for using Swift on Android: 1) shared code between your ios, mac, and android apps. 2) you already know swift. That said, there is always a cost to using a non-standard language to develop for a platform. Things like having to translate documentation as you read it, friction between system libraries and your languages standard library, etc. I've not looked at Kotlin in detail, but I wonder how much that friction is reduced because it's java-based, or if you'll experience just as much friction using Swift on Android as you would using Kotlin on Android. Worth evaluating if you're starting a project 6 months to a year from now as the Swift tooling for Android starts to mature. As it stands now, I would have a look at Kotlin, but almost definitely write any projects started today in Java. Swift is nowhere near ready, and the advantage of writing in the platform's "native" language usually outweighs any benefits there are to using a "better" language.
- izacus 11y agoThe alternative of course being C++14 with first party support for each OS out there and maturer ecosystem.
- on_and_off 11y ago>friction between system libraries and your languages standard library Well, that's the thing : Kotlin emits bytecode. It is entirely interoperable with Java. All the Java APIs of the platform are accessible in Kotlin. Swift on the other end can only target the NDK, which limits it to a very specific niche on Android.
- drdaeman 11y agoI haven't ever wrote an Android app (just toyed around and patched a few projects, but never had an idea and a necessity to do a full one from scratch), but what's the limitation here? Can't a native library call just anything from the Android/Java world? I mean, NDK library has JNIEnv* pointer and it can call FindClass/GetMethodID/Call*Method. And it can create objects/functions if it needs to be called back. Of course this isn't fun in the raw form, but don't see any reason it can't be well sugared.
- izacus 11y agoYou don't gain anything except a huge debugging pain and a large loss of performance. Debugging JNI and performance loss of translation makes not using JVM downright madness.
- kennywinker 11y agoJust because they are accessible, doesn't mean using them is seamless. For example all of Objective-C's runtime and classes are available to Swift but there is some friction e.g. methods that emit untyped NSArrays rather than typesafe swift arrays, or cases where you have to avoid using Swift structs because they can't be passed into the Objective-C runtime. Apple's done a lot of hard work, and each release of Swift has made this better, but it's still not entirely without hiccups... without having used Kotlin, I can't say for sure, but I would guess there are some analogous issues.
- on_and_off 11y agoSo far, it seems pretty seamless. I guess that with a couple of years working on a production app in Kotlin, I would have to discover some hairy corner cases though. What helps a lot is that the kotlin team has written many helper methods allowing a better flow between the android API and kotlin code : while you don't need it in order to get interop, it allows to more easily write idiomatic kotlin code while interacting with Android.
- geodel 11y agoSome people like to avoid Java and languages dependent on JVM. For them any non JVM based solution on android is welcome change. So efforts towards that need no justification as to why any of numerous JVM language is not used first.
- pjmlp 11y agoExcept all major Android APIs are Java only, even pure native apps are actually loaded as .so into a Java process.
- geodel 11y agoThe point is lot of application logic can be written in Go and Swift hopefully soon. That code can be shared across iOS / android app. It is still net win for people who do not like Java/JVM.
- pjmlp 11y agoAs someone that mainly codes in C++ across Android and Windows Phone for hobby projects, there is no escape from JNI for any application of significant size. Have you used the NDK? You cannot even access the filesystem outside the APK deployment tree without a few JNI calls.
- Fargren 11y agoI 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.
- untog 11y agoCould you develop libraries that way, though? It would have to be absolutely pure Swift, not using any iOS libraries, like NSURL etc. etc. - surely incredibly limiting.
- LeoNatan25 11y agoNot true. Both Foundation and Core Foundation libraries will be eventually ported and open sourced.
- bluejekyll 11y agoThis feels a little like wishful thinking. Remember YellowBox back when Apple originally bought NeXT? YellowBox was going to be a cross-platform updated version of the OpenStep APIs. While I remember some alphas of it, it basically got nixed. http://www.roughlydrafted.com/RD/RDM.Tech.Q1.07/4B800F78-0F75-455A-9681-F186A4365805.html http://www.roughlydrafted.com/RD/RDM.Tech.Q1.07/4B800F78-0F7... As much as I enjoy using Apple products, their history says that they would not directly support something like this.
- LeoNatan25 11y agoWe are long long days since that. https://github.com/apple/swift-corelibs-foundation https://github.com/apple/swift-corelibs-foundation https://github.com/apple/swift-corelibs-libdispatch https://github.com/apple/swift-corelibs-libdispatch Works is well under way.
- 11y ago
- melling 11y agoGuess what. No one cares if you don't use Swift. Go with Kotlin. It's probably a great choice for you. It seems like a great language and I hope it gains traction. You're doing that nerd thing where you need to tell the world why something isn't good for you. We'd waste a lot less time if we simply found the group we desired and added value there rather than find another group and tell them why what they're doing doesn't work for you.
- _3u10 11y agoI wish I had a thousand up votes for this post. it's easier to change your group than to change the group.
- barbs 11y agoHe's saying that Kotlin is similar enough to Swift, but integrates far easier with the Android ecosystem and development environment, such that it's probably a better choice for a lot of people wanting to make Android apps with a modern "swift-like" language. I think that's pretty relevant. You're doing that nerd thing where you're assuming we're divided into groups based on the technology we're using. We'd waste a lot less time if we simply tried to find the best tool for the job, rather than joining with a group and sticking with them blindly.
- melling 11y agoIf all you're doing is Android programming Kotlin is probably a better choice at this time. If you're a Java programmer, Kotlin is probably a better choice. If you're already a Swift programmer... Also, let's see how both languages gain traction in the next 3-5 years.
- on_and_off 11y agoThe main problem with Swift on Android is that AFAIK it is going to be limited to NDK. There is certainly a niche where it can be useful, but for most developers, it makes it a no go. Kotlin on the other end is indeed a very good stand-in replacement for java on Android.
- vmorgulis 11y agoSwift is compiled. One can expect better performance. The target is probably iOS developers.
- on_and_off 11y ago? Android apps are also compiled ahead of time right now (whether they are written in java or kotlin).
- r00fus 11y agoDon't you still have GC issues for heap allocation/destruction? Swift uses the ARC pattern so no GC lockups or performance issues. [1] https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/AutomaticReferenceCounting.html#//apple_ref/doc/uid/TP40014097-CH20-ID49 https://developer.apple.com/library/ios/documentation/Swift/...
- on_and_off 11y agoI have spent a large amount of time optimizing Android apps and GC pauses are generally not the issue (as long as you don't do something stupid like allocating objects in draw calls). I think that ARC is probably an overall better solution but as far as GC pauses are concerned, we have reached the point where they don't impact performances.
- sangnoir 11y ago> Swift is compiled. One can expect better performance.Swift is compiled. One can expect better performance. Since we are discussing targeting Android: Java (and Kotlin) are also compiled ahead of time by the Android Runtime (ART). This has been the case since Android 4.4 (KitKat) when ART became an optional replacement to Dalvik.
- fleitz 11y agoSwift gets most of its performance gains by not doing GC and better struct support. I have a distaste for Java but it's performance problems stem mostly from the way people write it and how hard it discourages writing in a performant style.
- giarc 11y agoCan you use Xcode for Kotlin? Serious question.
- tn13 11y agoI do not understand people's fascination with SWIFT. It is a great language compared to the atrocity of Objective-C but then no where close to Java. I think there are lot of iOS programmers in the wild for whom SWIFT is first language and hence the fascination.
- deleted 11y ago[deleted]
- azinman2 11y agoHow in the world so is Java better?