Live data from Hacker News

Swift Ported to Android

github.com

121–130 of 153 posts

Re: Swift Ported to Android

#121
post #119

Earlier quoted context omitted.

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

This is good to know. Looks like the only way to make use of JIT (by someone who isn't Apple) is to use a WKWebView to execute the JS.

Re: Swift Ported to Android

#122

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'll believe it when I see it. Cross-platform UI libraries like Qt, Gtk, SWT, etc, just never end up choosing quite the right widgets or having exactly the right look-and-feel as natively-designed apps.

If cross-platform is a bigger requirement than producing the best-possible UX, then perhaps Xamarin could deliver. I see this being a big deal with enterprise software. But that's almost never the case for most consumer-facing software; you're always much, much better off building your presentation code in a native UI toolkit.

Re: Swift Ported to Android

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

Re: Swift Ported to Android

#124
post #75
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).

Guess 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 doe…

I wish I had a thousand up votes for this post. it's easier to change your group than to change the group.

Re: Swift Ported to Android

#125
post #75
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).

Guess 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 doe…

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

Re: Swift Ported to Android

#126

Earlier quoted context omitted.

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++?

Write shared logic in C++ and use JNI/JNA ? Or are you asking about something more specific ?

Re: Swift Ported to Android

#127
post #92
post #85

Earlier quoted context omitted.

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

Federighi said on Gruber's podcast that the Dock team completely rewrote Dock in Swift. However most of the other OS X teams are only testing the waters. A big part of it is lack of 32-bit support for Swift apps.

Federighi said:

" the team that does the Dock and the window management on OS X, implemented all their new features for El Capitan in Swift and started mass-converting all of their code, and say that they couldn’t imagine going back and that they’re more productive with it."

So the window management team is also using it.

Re: Swift Ported to Android

#128

Earlier quoted context omitted.

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

? Android apps are also compiled ahead of time right now (whether they are written in java or kotlin).

Don'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/...

Re: Swift Ported to Android

#129
post #123

Earlier quoted context omitted.

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

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?

Re: Swift Ported to Android

#130
post #18

Earlier quoted context omitted.

Swift isn't a significant improvement over C#. Also, keep in mind that C# benefits from the whole Microsoft ecosystem, which includes Visual Studio. Beyond the language, what's even more important is the application model. That's where frameworks like React Native have the edge. This might change if Microsoft upgrades Xamarin.Forms into full-blown Universal Windows App support (think WPF on iOS and Android).

You might just be looking at the language from a syntax perspective. However the two are very different in the way that you compile and run them. In C# the code is translated into a custom bytecode (IR) and then the CLR is used to execute that and manage the memory through GC. In Swift's case it compiles down to native processor code instructions and can have optimisations applied ahead of time. This allows the app t…

ART also compiles down to native code. As for performance comparisons - last time I checked the benchmarks for Java were still faster than Swift.
Post reply on HN