Swift Ported to Android(github.com) |
Swift Ported to Android(github.com) |
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 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.
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 friction is reduced because it's java-based, or if you'll experience just as much friction using Swift on Android as you would using Kotlin on Android. Worth evaluating if you're starting a project 6 months to a year from now as the Swift tooling for Android starts to mature.
As it stands now, I would have a look at Kotlin, but almost definitely write any projects started today in Java. Swift is nowhere near ready, and the advantage of writing in the platform's "native" language usually outweighs any benefits there are to using a "better" language.
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.
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 doesn't work for you.
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.
There is certainly a niche where it can be useful, but for most developers, it makes it a no go.
Kotlin on the other end is indeed a very good stand-in replacement for java on Android.
The target is probably iOS developers.
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.
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.
I think there are lot of iOS programmers in the wild for whom SWIFT is first language and hence the fascination.
* 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 platform would need.
Also, there are also a bunch of support things for libICU which is not an official component on Android we are allowed.
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.
On Android, Swift will likely be in the same position as the NDK, which isn't a great place to be for UI, but it's doable. You'll be able to make the same UI calls you'd make from C code.
http://appleinsider.com/articles/16/01/18/apple-making-spars...
A lot of devs take this to mean Swift should be avoided for now.
Edit: To be clear, I don't agree with this sentiment! Swift is awesome. Just trying to clear up the parent comment's confusion!
Xamarin's big selling point is a cross platform ui library.
Each platform requires UI work to make it really fit the platform in question.
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).
In Swift's case it compiles down to native processor code instructions and can have optimisations applied ahead of time. This allows the app to run faster than a VM+JIT would do and therefore longer batter management. The overhead of the runtime is a lot lower since memory is ref counted and doesn't need to run GC periodically.
Both good and bad. Visual Studio isn't cross-platform, for example.
How much time does it take to create a thread in mono on my Linux VM?
How much does it cost a license for Visual Studio?
But please correct me if I'm wrong.
https://www.binpress.com/tutorial/objectivec-lesson-1-hello-...
On the other hand the Frameworks are quite expressive for applications, but one needs to use Java 6.5 or resort to third party solutions like retrolambda and Kotlin.
Also, let's see how both languages gain traction in the next 3-5 years.
Have you used the NDK? You cannot even access the filesystem outside the APK deployment tree without a few JNI calls.
Free if your revenue is under $1m, then $40/month including CI, source hosting and issue tracker.
How much does licensing a set of Windows keys run?
How does the .NET GC impact me versus Swift's ARC?
How much RAM does Visual Studio eat up after you've been coding for a while?
How slow, unresponsive or buggy is it these days?
of course there's "ecosystem creep"... If I'm going C# on mobile, I'll naturally be influenced to consider C# on the server... how much do Windows servers cost? and since they're a "first class citizen" on windows, what about SQL Server?
[1] https://developer.apple.com/library/ios/documentation/Swift/...
I think that ARC is probably an overall better solution but as far as GC pauses are concerned, we have reached the point where they don't impact performances.
C# is compiled to native code on Windows Phone since version 8.
The C# extensions for Singularity (Sing#) and Midori (System C#) generate static binaries. Work which served as starting point to MDIL on WP 8.x and .NET Native.
The new .NET Native compiler even exposes SIMD.
Mono also supports AOT compilation since a long time.
As always language != implementation.
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 this.
https://github.com/apple/swift-corelibs-foundation https://github.com/apple/swift-corelibs-libdispatch
Works is well under way.
What helps a lot is that the kotlin team has written many helper methods allowing a better flow between the android API and kotlin code : while you don't need it in order to get interop, it allows to more easily write idiomatic kotlin code while interacting with Android.
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.
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)
>As for performance both have performance penalties. Automatic reference counting delivers a more consistent performance, no pauses, but slows down your application as a whole as every assignment of an object to a variable, every deallocation of an object, etc, will need an associated incrementation/decrementation of the reference counter, and taking care of reassigning the weak references and calling each destructor of each object being deallocated. GC does not have the performance penalty of ARC when dealing with object references however it incurs pauses while it is collecting garbage (rendering unusable for real-time processing systems) and requires a large memory space in order for it to function effectively such that it is not forced to run, thus pausing execution, too often.
>As you can see both have their own advantages and disadvantages, there is no clear cut ARC is better or GC is better, both are compromises.
>PS: ARC also becomes problematic when objects are shared across multiple threads requiring atomic incrementation/decrementation of the reference counter, which itself presents a whole new array of complexities and problems.
Most of the existing apps aren't written in Swift because they predate Swift's creation. The balance will change over time.
http://daringfireball.net/thetalkshow/139/federighi-gruber-t...
"FEDERIGHI: We have all types here within Apple. They start out with the “I love Objective-C. I don’t want to change” to “OK, maybe there’s something to this Swift thing” to “Let me give it a try” to “I love it.” We’ve gone through all the phases internally. You know, we’ve had some really great adoption by teams like … 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. Part of what our internal teams need to deal with, though, is that they’re working on, let’s say, the current version of Swift 2.0 while it’s not done yet. I mean, while it’s not even WWDC-level done yet, right? And they’re working on the interfaces in terms of our internal frameworks that haven’t been modernized for Swift. And so, they’ve got it rough. They’ve got to really love it to make that leap because they’re working on a very, very bleeding-edge environment when we use it internally. Thankfully, with Swift 2.0 now well out the door, that’s stabilized things a good bit and they’re really open to it.
But there’s been just lot of feedback. And a lot of it has helped with the impedance, making sure the impedance between Objective-C and Swift is absolutely minimized because of course we have and will continue to have and continue to write more Objective-C code, and so the ability of Swift and Objective-C code to work together completely naturally is a huge focus. A bunch of things like generic collection, support for lightweight generics in Objective-C, were big pain points internally and something we fixed in the language, and is now great for all of our app developers externally. So, it’s been a not dissimilar road for us internally to what you see outside. But in terms of Swift and writing big apps, it’s certainly the case that when Swift 1.0 came out — heck, we didn’t support incremental compilation in the very first update. And so that was going to be a limiting factor for productivity for people who had big apps. A lot of that stuff has changed. And then in 2.0 having a good error-handling model, having the availability check so you could span API versions — these sorts of things. I think it really addressed the vast majority of pain points that we were experiencing, that I think the community was experiencing about writing larger apps. And so much about Swift is actually inherently better for building big apps because it handles modules and namespaces in a way more naturally than in Objective-C. It makes the API contracts a little more clear, the code more obtainable. So, we’re very comfortable."
> 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...
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 considered essential but aren't part of Swift's stdlib.
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.
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...
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 not like an HTML page, a Xamarin form input will look different on Android and iOS by default.
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
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.
most business users would accept that their apps, look slighly ... unlike common apps on the platform
" 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.
[1] http://8th-dev.com/I'm intrigued by 8th - in a good way - and happy you've introduced me to it - but I do wonder what kind of uptake something like this will get.
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.
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)."
http://stackoverflow.com/questions/22281265/is-javascriptcor...
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
We use Clang 3.5.