Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift Ported to Android

github.com

Post reply on HN
Print view View original

101–110 of 153 posts

Re: Swift Ported to Android

#101

Post by pjmlp »

geodel wrote: post #88
pjmlp wrote: post #77

Earlier quoted context omitted.

Except all major Android APIs are Java only, even pure native apps are actually loaded as .so into a Java process.

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

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

Re: Swift Ported to Android

#102

Post by zepto »

mwcampbell wrote: post #50
seivan wrote: post #47

Earlier quoted context omitted.

Run some lists with images on them on iPhone 5. Anecdotal, and I am sure you can dig into metal to improve performance, but out of the box, it's kinda poor. I still like React and I'm hopeful React-Native will improve.

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.

This has been false for years.

Re: Swift Ported to Android

#103

Post by vram22 »

JonathonW wrote: post #51
stormbrew wrote: post #29

Earlier quoted context omitted.

Swift String, Array, etc. are not part of Foundation, they are part of the swift runtime library. They have mechanisms for converting to and from NSArray/NSString representations, though (and because of that, their internal structure is quite similar). But that mechanism is disabled in Linux (and obviously I assume Android).

That's correct-- Swift's native String/Array/etc. are part of Swift's native stdlib. NSString/NSArray and friends (along with the bridging code to go between them and the Swift stdlib types) are part of the open-source Foundation, though. Eventually, that should be present in any reasonably complete Swift runtime environment-- it includes APIs, like networking and date/time handling, that would typically be considere…

Whats with all the NS prefixes? Stands for NextStep?

Re: Swift Ported to Android

#104

Post by Fargren »

josephearl wrote: post #93
Fargren wrote: 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.

AFAIK there's nothing stopping you using Kotlin on iOS with RoboVM since it is a JVM language - https://robovm.com .

True enough, but I really don't like depending on closed source solutions for something so fundamental as getting my code to run on a platform. I feel like I am betting the future of the product on the future of this company. Of course, I am already betting on the future of iOS and Android, but I have a lot more confidence on those too than on RoboVM

Re: Swift Ported to Android

#105

Post by stormbrew »

JonathonW wrote: post #51
stormbrew wrote: post #29

Earlier quoted context omitted.

Swift String, Array, etc. are not part of Foundation, they are part of the swift runtime library. They have mechanisms for converting to and from NSArray/NSString representations, though (and because of that, their internal structure is quite similar). But that mechanism is disabled in Linux (and obviously I assume Android).

That's correct-- Swift's native String/Array/etc. are part of Swift's native stdlib. NSString/NSArray and friends (along with the bridging code to go between them and the Swift stdlib types) are part of the open-source Foundation, though. Eventually, that should be present in any reasonably complete Swift runtime environment-- it includes APIs, like networking and date/time handling, that would typically be considere…

The bridging is actually in the swift libraries. Much of it in C++, not in swift, but still. https://github.com/apple/swift/blob/master/stdlib/public/cor... is where the magic starts (and mostly refers to where the actual work is done).

AFAIK Foundation does not have any special handling for swift at all. Swift is just taking advantage of the fact that the people working on it can act with authority on the memory layout of Objective-C Foundation objects.

Also the OSS Foundation is... not quite the same thing as what apple ships on their platforms.

Re: Swift Ported to Android

#106

Post by sangnoir »

vmorgulis wrote: post #82
V-2 wrote: 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).

Swift is compiled. One can expect better performance. The target is probably iOS developers.

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

Re: Swift Ported to Android

#107

Post by JonathonW »

stormbrew wrote: post #105
JonathonW wrote: post #51

Earlier quoted context omitted.

That's correct-- Swift's native String/Array/etc. are part of Swift's native stdlib. NSString/NSArray and friends (along with the bridging code to go between them and the Swift stdlib types) are part of the open-source Foundation, though. Eventually, that should be present in any reasonably complete Swift runtime environment-- it includes APIs, like networking and date/time handling, that would typically be considere…

The bridging is actually in the swift libraries. Much of it in C++, not in swift, but still. https://github.com/apple/swift/blob/master/stdlib/public/cor... is where the magic starts (and mostly refers to where the actual work is done). AFAIK Foundation does not have any special handling for swift at all. Swift is just taking advantage of the fact that the people working on it can act with authority on the memory lay…

That's where Objective C bridging happens. That's irrelevant on Linux or Android, since there's no Obj-C runtime.

OSS Foundation (which is composed of pure Swift code, plus the plain C CoreFoundation which is also open) implements bridging between Swift types and Foundation types itself-- see (for example) the Array extension for bridging to NSArray at [1]. That code's what will (again, eventually) ship on Linux and presumably on Android, because it provides compatibility support for Swift libraries originally targeted to Apple platforms and fills out certain core functionality that's not part of Swift's stdlib (networking being a big one). This work is still ongoing and, if one were to try to actually use it right now, you'd run into lots of bits that aren't implemented yet.

[1] https://github.com/apple/swift-corelibs-foundation/blob/mast...

Re: Swift Ported to Android

#108

Post by JonathonW »

vram22 wrote: post #103
JonathonW wrote: post #51

Earlier quoted context omitted.

That's correct-- Swift's native String/Array/etc. are part of Swift's native stdlib. NSString/NSArray and friends (along with the bridging code to go between them and the Swift stdlib types) are part of the open-source Foundation, though. Eventually, that should be present in any reasonably complete Swift runtime environment-- it includes APIs, like networking and date/time handling, that would typically be considere…

Whats with all the NS prefixes? Stands for NextStep?

Yes. It's a poor-man's implementation of namespaces, since Objective C doesn't have them and they didn't want to pollute the global namespace with their core classes.

Re: Swift Ported to Android

#109

Post by sangnoir »

josephearl wrote: post #96
leonatan wrote: post #49

Earlier quoted context omitted.

Lowest common denominator. Terrible for UX for everything but the most basic UI designs, sorry. Each platform requires UI work to make it really fit the platform in question.

I think most people don't understand Xamarin. Up until pretty recently Xamarin had no cross platform UI components. That is although all logic was shared, views had to be written separately for the different platforms - just like React Native. With Xamarin Forms this has changed - you can add a Xamarin Form component and this will work adapt itself across the different platforms. The key word there is adapt - it is n…

> 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 was also an easy way to spot lazy iOS 'ports'). I think edge-swipes are another iOS convention for navigating back/forward, which would be foreign on Android, so I fully agree with GPs statement: Each platform requires UI work to make it really fit the platform in question

Re: Swift Ported to Android

#110

Post by mastazi »

moonchrome wrote: post #79
Fargren wrote: 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'm not sure about how mainstream/supported C++ is in the Android world.
Post reply on HN