Swift Ported to Android
github.comSurprised 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.
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.
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.
Not true. Both Foundation and Core Foundation libraries will be eventually ported and open sourced.
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 this.
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.
Omg, I had no idea. Awesome!
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
You could this for your own libraries, but I would strongly recommend against doing this for a public lib if you want traction (e.g. if you are making a bunch of SDKs for your APIs) - in this case you should publish your lib in the most popular language(s) for the platform(s) you are targeting.
>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've tried Haxe, Racket, TCL/tk, MOAI (Lua based), and others, but I am now using 8th, a Forth-like language that compiles to Android, iOS, Windows, OSX and Linux [1]. The only downside is that I still need a Mac to publish iOS apps. For Android, Windows and Linux, I am good to go. It uses the JUCE library for gui implementation. I have made two toy apps for Android so far, and I am still learning. It has a good library so far, but some people find Forth difficult. I find it concise, expressive and still readable after 6 months. The shortness makes code review a breeze.
[1] http://8th-dev.com/What a strange beast! A closed source language is always a tricky sell. Forth is never an easy sell in itself (unless you've already been bitten by the bug ;-) in which case it's a wonderful bonus). The tutorial is PDF only - which just seems a bit odd.
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.
It is a bit odd, but I am rocking with it. I have done Java and NDK in C++ tutorials to get simple programs running, but nothing original, or beyond what the tutorial provided. With 8th, I can whip up something quick with a GUI, using the sensors and other libs it comes with, and deploy it. It looks the same on Windows, Android and Linux. The developer makes him self available, and quite honestly, the code is succinct enough and the documentation good enough that I only asked a lot the first week. You should give it a try. I am by no means a 'Forth programmer', and 8th is not a compliant Forth.
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.
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 ?
I guess I found what I was asking about, i.e. NDK: http://developer.android.com/ndk/index.html
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.
Are you using NDK? I was reading about it earlier, it is something that I would like to look into, when I have some time.
Yes, NDK is after all just a name for preconfigured GCC and Clang package shipped by Google :)
We use Clang 3.5.
Yeah for an example of what I would love to be able to use on both android and ios : http://createdigitalmusic.com/2015/01/free-audiokit-lets-ios...
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 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.
>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.
Just because they are accessible, doesn't mean using them is seamless. For example all of Objective-C's runtime and classes are available to Swift but there is some friction e.g. methods that emit untyped NSArrays rather than typesafe swift arrays, or cases where you have to avoid using Swift structs because they can't be passed into the Objective-C runtime. Apple's done a lot of hard work, and each release of Swift has made this better, but it's still not entirely without hiccups... without having used Kotlin, I can't say for sure, but I would guess there are some analogous issues.
So far, it seems pretty seamless. I guess that with a couple of years working on a production app in Kotlin, I would have to discover some hairy corner cases though.
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.
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.
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.
The alternative of course being C++14 with first party support for each OS out there and maturer ecosystem.
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.
As someone that mainly codes in C++ across Android and Windows Phone for hobby projects, there is no escape from JNI for any application of significant size.
Have you used the NDK? You cannot even access the filesystem outside the APK deployment tree without a few JNI calls.
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 doesn't work for you.
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.
If all you're doing is Android programming Kotlin is probably a better choice at this time. If you're a Java programmer, Kotlin is probably a better choice. If you're already a Swift programmer...
Also, let's see how both languages gain traction in the next 3-5 years.
I wish I had a thousand up votes for this post. it's easier to change your group than to change the group.
The main problem with Swift on Android is that AFAIK it is going to be limited to NDK.
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.
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?
Not really, reference counting is generally considered to be more performant than GC. GC can end up thrashing the cache and doesn't work very well when using more than 8 to 16 GB of RAM.
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)
I came across this explanation on StackExchange on the performance penalties with ARC:
>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.
> Swift is compiled. One can expect better performance.Swift is compiled. One can expect better performance.
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.
? 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/...
I have spent a large amount of time optimizing Android apps and GC pauses are generally not the issue (as long as you don't do something stupid like allocating objects in draw calls).
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.
Can you use Xcode for Kotlin? Serious question.
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.
How in the world so is Java better?
Interesting, in the context of Xamarin acquisition by Microsoft. Swift can very well spoil C#'s steam.
People focus far too much on different languages. The fact that Android and iOS have very different UI libraries is usually a much bigger problem.
Xamarin's big selling point is a cross platform ui library.
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.
True, but Microsoft is such an enterprise company that it fits their customer base really well (e.g. "I don't care if it's pretty, I just need an inexpensive-to-build app for my 3,000 workers that runs on either platform").
I get that. But I also think that companies are slowly understanding that UI and UX matters. Even in the enterprise sector.
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 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!
> 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
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.
Yes, the most noticeable differences are implemented. But this is very a superficial look. From the developer's page:
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
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.
but i would say for writing business apps, this isnt really an issue
most business users would accept that their apps, look slighly ... unlike common apps on the platform
Which users? Admins don't care about UX, they care about ticking checkboxes to appease management. End users are people like you and me, they want quality from their software. They may be forced to work with less then stellar software, but that does not mean they accept it.
I would say that React Native is the biggest threat there.
Doesn't perform well enough outside of high-end devices.
Do you have anything to back that up?
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.
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.
This has been false for years.
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.
That isn't an issue with React Native, which runs JS on its own thread and implements an asynchronous, batched bridge between JS and native.
As long as React Native requires the developer to use Javascript to write his code this is a no go for the sane of us.
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 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.
C# has always had support to AOT to native code since the early days via ngen. The only issue was that more effort was spent in the JIT compiler and ngen requires dynamic linking.
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.
You are correct but part of the work being done to get .NET native working is the aot compilation. https://blog.rendle.io/what-ive-learned-about-dotnet-native/
.Net Core can compile AOT as well, and Xamarin already does that on iOS with its Mono runtime too.
ART also compiles down to native code. As for performance comparisons - last time I checked the benchmarks for Java were still faster than Swift.
> C# benefits from the whole Microsoft ecosystem, which includes Visual Studio.
Both good and bad. Visual Studio isn't cross-platform, for example.
Well, Visual Studio Code[1] is, so it may be coming in the future.
They're entirely different products, Code is built from the ground up. So I'm not sure it makes a cross-platform Visual Studio more likely.
I would say the fact MS is shipping products on Linux, considering their historical stance, makes it more likely, but your sentiment is probably correct in that it may not mean it is likely. Ten years ago I would have laughed at the idea. Today, I have to think quite a bit more about whether it's likely.
I would not use the existence of an editor built on web technologies as opening the possibility that something as entrenched in Windows as Visual Studio would be leaping to cross platform.
How much RAM does a single hello world take in C#?
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?
> How much does it cost a license for Visual Studio?
Free if your revenue is under $1m, then $40/month including CI, source hosting and issue tracker.
it's worth also asking:
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?
This was my thought. What is Microsoft's answer to Swift?
React Native is not even on the horizon.
What do you mean?
I would expect this just to be basic Swift support including -perhaps- the Foundation library (String, Array and other "low level" functionality). I don't think this Swift port has currently any easy way to create apps with a graphical user interface using some sort of Java bridge. So compared to Xamarin, using Swift for Android apps would be pretty limited.
But please correct me if I'm wrong.
Swift String, Array, etc. are not part of Foundation, they are part of the swift runtime library. They have mechanisms for converting to and from NSArray/NSString representations, though (and because of that, their internal structure is quite similar). But that mechanism is disabled in Linux (and obviously I assume Android).
That's correct-- Swift's native String/Array/etc. are part of Swift's native stdlib.
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.
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 layout of Objective-C Foundation objects.
Also the OSS Foundation is... not quite the same thing as what apple ships on their platforms.
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 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...
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.
Whats with all the NS prefixes? Stands for NextStep?
Yes. It's a poor-man's implementation of namespaces, since Objective C doesn't have them and they didn't want to pollute the global namespace with their core classes.
C# devs like myself are interested in Xamarin are interested because they don't have too learn new language / tooling to do mobile dev. Learning Swift isn't any more appealing than learning Objective C.
I care about syntax so Swift is far more appealing to me. Compare print("Hello, world!") in Swift to Hello World in Objective-C, which the article jokingly calls "gibberish."
https://www.binpress.com/tutorial/objectivec-lesson-1-hello-...
Why? Microsoft will likely offer Swift support in the UWA platform soon, they already support Objective C. I suspect they will announce Swift is now supported under project Islandwood at Build.
My comment was on C#, and not Microsoft.
Far from likely. For those fed up with Java, Android has Kotlin already.
It would be great if Swift could target .Net Core.
I did a little googling because you sparked my curiosity and it's happening. “Silver” brings Apple's Swift language to .NET and I found at least one mention of Silver and .NET Core.
Just my thought.
F# is already spoiling Swift's feathers. And F# has first class support in Xamarin.
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 platform would need.
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.
Android uses Bionic libc which has its quirks. The Android kernel also has several patches that were at one time quite controversial, though many have moved upstream to the mainline.
Its not just quirks, but bionic doesn't support all the libc apis. For example, bionic does not support pthread_cancel.
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.
Google has ripped out most of the stuff that would have made smart phones actual computers rather than smart terminals.
If you think of C and C++ point of view, yes.
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.
UI 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 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.
And that there in is an issue. Android will never have a complete ndk API parity with Java. They've made this clear, and would be difficult since the Java API is implemented in Java (it's not a wrapper of ndk).
Don't expect to write entires Android apps in Swift. The best thing we can hope for is sharing crossplatform code among iOS, Android etc. And with Foundation ported this is fair amount of code.
Interesting, but even Apple doesn't use switf on iOS. So is there really a point?
Apple doesn't use swift because they already have stable versions of their Apps written in Objective C and there's no reason to rewrite everything in swift because they can mix ObjC and Swift.
On that note, MS doesn't use C# that much outside of websites. Maybe people should take the hint there as well.
My impression was that Visual Studio's UI (not all of it, but presentation layer) is C# / WPF.
What?
Wasn't a very useful comment, but what I think he/she meant was that Apple doesn't actually use Swift much in its own apps:
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!
There is a difference between "starting a brand new app on Swift" and "porting a long-existing Apple app to Swift". How many new apps Apple had started after Swift announcement?
Swift 3 is expected later this year with a fixed ABI. Once that happens we will start to see Swift-only APIs being made available for iOS frameworks.
Most of the existing apps aren't written in Swift because they predate Swift's creation. The balance will change over time.
Don't count on Swift-exclusive APIs anytime soon.
Parts of OS X El Capatian are written in Swift . Source :
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."
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.
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.
Only the dock IIRC.