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.
Swift Ported to Android
131–140 of 153 posts
Re: Swift Ported to Android
#132Earlier 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.
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
#133Earlier 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?
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
#134Earlier 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.
Re: Swift Ported to Android
#135Surprised 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.
Re: Swift Ported to Android
#136Earlier 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.
[1] http://8th-dev.com/Re: Swift Ported to Android
#137Surprised 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.
Re: Swift Ported to Android
#138Earlier 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.
Re: Swift Ported to Android
#139UI 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…
Re: Swift Ported to Android
#140Why 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.