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

111–120 of 153 posts

Re: Swift Ported to Android

#111

Post by mastazi »

moonchrome wrote: post #83
unfamiliar wrote: post #81

Earlier quoted context omitted.

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 c…

What's the canonical way of targeting Android with C++?

Re: Swift Ported to Android

#112

Post by stormbrew »

JonathonW wrote: post #107
stormbrew wrote: post #105

Earlier quoted context omitted.

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…

That is true. I recognize that to some extent I was talking past you, but I really just wanted to clarify where the responsibility lies when there is an objc runtime.

Re: Swift Ported to Android

#113

Post by mwcampbell »

Fargren wrote: post #104
josephearl wrote: post #93

Earlier quoted context omitted.

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

On top of that, RoboVM uses its own LLVM-based compiler rather than Apple's. So if Apple throws us a new compilation requirement, similar to the requirement to provide bitcode for watchOS and tvOS, then we're stuck until RoboVM is updated. With j2objc, you're using Apple's compiler to produce the machine code.

Re: Swift Ported to Android

#114

Post by drdaeman »

on_and_off wrote: post #99
kennywinker wrote: post #64

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.

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

Re: Swift Ported to Android

#115

Post by izacus »

mastazi wrote: post #110
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.

I'm not sure about how mainstream/supported C++ is in the Android world.

Just as much as everywhere else, we're using it extensively for sharing code. If has a few qurks but it's easy better than windows for example.

Re: Swift Ported to Android

#116

Post by [deleted] »

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.

[deleted]

Re: Swift Ported to Android

#117

Post by izacus »

drdaeman wrote: post #114
on_and_off wrote: post #99

Earlier quoted context omitted.

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

I 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 cou…

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

Re: Swift Ported to Android

#118

Post by ChrisClark »

sangnoir wrote: post #109
josephearl wrote: post #96

Earlier quoted context omitted.

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…

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.

Re: Swift Ported to Android

#119

Post by DerekL »

andrewjl wrote: post #78
mwcampbell wrote: post #50

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.

As of iOS 8 that's no longer the case. JSC JIT compilation can be used in native apps. (It's also used by WKWebView.) http://trac.webkit.org/wiki/JavaScriptCore "JavaScriptCore is an optimizing virtual machine. JavaScriptCore consists of the following building blocks: lexer, parser, start-up interpreter (LLInt), baseline JIT, a low-latency optimizing JIT (DFG), and a high-throughput optimizing JIT (FTL)."

Apps can use JavaScriptCore, and JavaScriptCore can use JIT, but these can't happen together, because third-party apps aren't permitted to execute writeable memory.

http://stackoverflow.com/questions/22281265/is-javascriptcor...

Re: Swift Ported to Android

#120

Post by [deleted] »

tn13 wrote: post #98
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).

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.

[deleted]
Post reply on HN