Live data from Hacker News

Swift Ported to Android

github.com

131–140 of 153 posts

Re: Swift Ported to Android

#131

Earlier quoted context omitted.

Thanks. I wonder how much of that is due to the fact that JavaScriptCore can't use JIT compilation when running in an iOS application other than Safari.

I haven't used React Native, but I've done quite a bit with native bridging with JavaScriptCore and v8. If your performance bottlenecks are crossing the Javascript-to-native boundary, JIT can't help you. And crossing the bridge boundary isn't the cheapest operation.

That isn't an issue with React Native, which runs JS on its own thread and implements an asynchronous, batched bridge between JS and native.

Re: Swift Ported to Android

#132

Earlier quoted context omitted.

> So I think your point, while valid, does not apply in any way to Xamarin! I'm afraid GPs point is still valid - UX (the experience) is more than just native/native-looking widgets, but how the app conforms to platform conventions. For example, iOS apps typically include(d?) a back button at the top left corner; even if the button is rendered faithfully as an Android widget - that app will feel alien on Android (it…

That was his point though. You build the UI in Xamarin.Forms and on the iPhone there is a back button in the top left corner, on Android there isn't. Automatically rearranging and conforming to the platform guidelines.

Yes, the most noticeable differences are implemented. But this is very a superficial look. From the developer's page:

https://xamarin.com/forms

Xamarin.Forms is best for: • Apps that require little platform-specific functionality

Xamarin.iOS & Xamarin.Android are best for: • Apps with interactions that require native behavior

Re: Swift Ported to Android

#133
post #123

Earlier quoted context omitted.

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

Aren't these "performance gains" a wash due to the overhead of ARC?

Not really, reference counting is generally considered to be more performant than GC. GC can end up thrashing the cache and doesn't work very well when using more than 8 to 16 GB of RAM.

Even the linux kernel uses reference counting as you need a rc / gc system to solve some problems.

ARC just inserts the retain/release calls that you'd make anyway, pretty much everyone agrees that there are very few degenerate cases with ARC and in the vast majority of cases it does the best that can be done, which is why almost everyone uses ARC now. (You can still turn it off if you really want in ObjC)

Re: Swift Ported to Android

#134

Earlier quoted context omitted.

This 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-0F7... As much as I enjoy using Apple products, their history says that they would not directly support something like t…

We are long long days since that. https://github.com/apple/swift-corelibs-foundation https://github.com/apple/swift-corelibs-libdispatch Works is well under way.

Omg, I had no idea. Awesome!

Re: Swift Ported to Android

#135
post #98
post #57

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

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

How in the world so is Java better?

Re: Swift Ported to Android

#136
post #66

Earlier quoted context omitted.

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.

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

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/

Re: Swift Ported to Android

#137
post #66
post #57

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

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.

Yeah for an example of what I would love to be able to use on both android and ios : http://createdigitalmusic.com/2015/01/free-audiokit-lets-ios...

Re: Swift Ported to Android

#138

Earlier quoted context omitted.

Two 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 fr…

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

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

Re: Swift Ported to Android

#139
post #39

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

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…

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

Re: Swift Ported to Android

#140
post #35
post #10

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

No, for example UNIX IPC isn't available. Google has ripped most of the stuff they see as fluff for Android. Edit: Any C and C++ API not listed as stable and public on the NDK docs is not guaranteed to exist in all devices.

Google has ripped out most of the stuff that would have made smart phones actual computers rather than smart terminals.
Post reply on HN