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

81–90 of 153 posts

Re: Swift Ported to Android

#81

Post by unfamiliar »

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.

How so? Doesn't this port to Android show that a Windows port is surely possible? Swift is already running on servers afaik. As for compiling to "browser," Swift is based on LLVM so should be just as capable of this as C++.

Re: Swift Ported to Android

#82

Post by vmorgulis »

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.

Re: Swift Ported to Android

#83

Post by moonchrome »

unfamiliar wrote: post #81
moonchrome wrote: post #79

Earlier quoted context omitted.

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

How so? Doesn't this port to Android show that a Windows port is surely possible? Swift is already running on servers afaik. As for compiling to "browser," Swift is based on LLVM so should be just as capable of this as C++.

What's "possible" and what's available and tested in production right now are two very different things. These kinds of ports take at least a year to get over the initial troubles and become usable and then you're at least that time away from a decent size of community libraries to spring up for the mentioned platforms.

By that time Rust will also mature enough and webasm will land so Rust will probably be a better candidate (since it's OSS and developed by a browser company that needs to run on as many platforms as possible they have much better incentives to maintain ports than Apple).

Also in that time C++ will probably get modules working on clang and many c++17 features.

And you might see Xamarin merge into CoreCLR and rolled up into VS integration.

A lot of things are possible - but what's available right now is C++ on every platform and not much else.

Re: Swift Ported to Android

#84

Post by Fargren »

untog wrote: post #70
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.

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

Absolutely I could. In fact, as I said, I already am, albeit with a more limited technology. For building multiplatform apps I build all the business logic in a Java library which I then convert to iOS using J2Objc. IME this is always between a third and half of the code that is now shared between platforms. For classes that will depend on platform specific stuff, like newtork requests that are handled differently by iOS and Android I use interfaces that I later implement (as protocols) on each side. iOS does end up feeling as a second class citizen though, because J2Obj is not exactly fast; if I need a change in the library, a recompile can take a few minutes

Re: Swift Ported to Android

#85

Post by rdsnsca »

kennywinker wrote: post #68
rimantas wrote: post #37

Earlier quoted context omitted.

WWDC app was done in Swift, IIRC. Not the core app by any means, but still.

That turned out not to be quite as true as they said it was... > While the WWDC app does in fact use Swift, it’s not as much as you might think. Out of 281 classes, only 6 are written in Swift. The Apple Store app is also using Swift for its watch app. That’s about all the production Swift I could find from Apple on iOS. Source: https://medium.com/@ryanolsonk/is-apple-using-swift-4a6c80f7...

They are using on more on the Mac. Parts of Mac OS X El Capitan are written in Swift.

Re: Swift Ported to Android

#87

Post by giarc »

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

Can you use Xcode for Kotlin? Serious question.

Re: Swift Ported to Android

#88

Post by geodel »

pjmlp wrote: post #77
geodel wrote: post #65

Earlier quoted context omitted.

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

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.

Re: Swift Ported to Android

#89

Post by ewmailing »

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.

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.

Re: Swift Ported to Android

#90

Post by ewmailing »

sspiff wrote: post #11
ungzd wrote: post #10

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

If you look at the changes, you'll see most things are pretty simple: * CMake files are expanded to handle an Android target. * Code that checks for specific defines or values like __FREEBSD__ || __LINUX__ now have an added condition to also check for __ANDROID__. * Some tooling scripts to integrate adb into the Swift SDK. * Some minor fixes elsewhere. So, special support is a really minimal set of changes that any p…

In addition to the Bionic short-comings already mentioned here, there appears to be other work to deal with the fact that things must be cross-compiled in a way that you can build a compiler for your host machine, but generate Android binaries (and for each architecture).

Also, there are also a bunch of support things for libICU which is not an official component on Android we are allowed.

Post reply on HN