OCaml support on iOS is really cool but it needs more tooling and a critical mass in community size before it'll gain any kind of traction.
Many developers still won't use Swift, for instance, because they think it's not ready for production yet. And there have been over three dozen Swift books published in 18 months: http://www.h4labs.com/dev/ios/books
There are a number of issues with Swift, though I'm sure they will improve:
1) No backwards compatibility: developers must keep rewriting their Swift code with each new Swift release, since syntax and features often change.
2) Swift's interaction with C++ is a non-starter, and many, many apps use C++.
3) Some C APIs are still quite difficult to use from Swift. Objective-C, being a strict superset of C, makes it very easy to use Core Audio, for instance. OpenGL interop can also be a bit frustrating.
4) Swift's "functional" idioms are weak and poorly implemented. If you can't provide a true functional backdrop to these features, they probably shouldn't even be in there. Coming from a real functional language, you're in for nasty surprises in Swift if you casually use higher-order functions all over the place, because there is a lot of copying going on.
5) Swift's performance is definitely not, shall I say, "swift," though hopefully that will eventually improve.
6) Poor and confusing compiler errors.
I actually realize now that I could go on all day about this.
Yes, I'm sure 20% of the iOS developer community finds it difficult to use Swift for any number of reasons. However, for the other 80% Swift is more than sufficiently baked. You may have a few difficulties over the next 12 months but at least your code will be in Apple's "new improved language" and you will not have to figure out what to do in then 24-36 months when you realize ObjC disappeared faster than you expected or Apple decides enough people use Swift that it doesn't need to be quite as compatible with ObjC:
Agreed. I'm not sure why you were downvoted. If we are speaking strictly about iOS, you are 100% right. Swift is king.
Swift is set to replace Objective-C and it has risen in popularity and adoption at an insanely rapid pace.
Everyone is adding swift to their code base. Our watch-client for example, is written exclusively in Swift. We have a ton of C++ code too. It's not a problem because it's all wrapped in an Objective-C API anyways.
Besides, Swift brings a lot more to the table than just saner syntax and less boiler plate. It also includes: a good type system, optionals, functional constructs, excellent OOP support, excellent error handling, scripting support, a repl, a great intermediate language in SIL, cross-platform (freeBSD soon) native code.
Sure, it's not purely functional by any means, but it's neither is Rust. It's a good (not perfect) multi-paradigm language that can and will eat up a lot of the domain space C++/Go/Rust share for native applications.
I even predict it will go a step further. Swift will, in my prediction, eventually allow for safe, zero-overead memory management abstractions similar to Rust (and to a lesser extent C++). This will make it a head on competitor with Rust and C++ for virtually all their use cases (except legacy support).
My speculations is based on comments from the language's creator expressing desire for these features in Swift [0] [1].
I'd say most of your criticisms are unimportant nitpicks from a pragmatic perspective (i.e. from the perspective of: I work on iOS apps and I want to get. things. done.).
> 1) No backwards compatibility: developers must keep rewriting their Swift code with each new Swift release, since syntax and features often change.
Nobody cares. We are very used to this. If you program iOS apps for a living, you know this has always been the case. Every new version of Xcode and iOS breaks code. With Cocoa and CocoaTouch, the language can at times feel like nothing more than a way to call the ever-changing SDK APIs.
It doesn't matter if your app is written Objective-C (a language that also continues to change every year), Swift, Ruby-motion, whatever... it'll break on the new Xcode. If not, you think something is wrong and pray the issue does not arise later.
Anyways the syntactic and semantic updates to Swift are automated fairly well, anyways, so this not really a major pain point IMO.
> 2) Swift's interaction with C++ is a non-starter, and many, many apps use C++.
True, many apps use C++. While, I, personally, would love to see C++ intro arrive before Swift 4.0 or 5.0, it's a feature that for all practical purposes is a luxury that we can live with out.
Use an Objective-C wrapper, then call it from Swift. All C++ that is called in the UIKit layer should be wrapped in an Objective-C API's anyways (UIViewController.mm is harmful!), so no big deal. The exception to this is, if you were trying to write an app in pure Swift. In that case, using C++ breaks the purity anyways, so you might as well use Objective-C wrappers.
> 3) Some C APIs are still quite difficult to use from Swift. Objective-C, being a strict superset of C, makes it very easy to use Core Audio, for instance. OpenGL interop can also be a bit frustrating.
Support is definitely good enough. Again, if you need more you can (and should) use both languages. Swift was designed to be used in an Objective-C codebase.
> 4) Swift's "functional" idioms are weak and poorly implemented. If you can't provide a true functional backdrop to these features, they probably shouldn't even be in there. Coming from a real functional language, you're in for nasty surprises in Swift if you casually use higher-order functions all over the place, because there is a lot of copying going on.
I disagree. I believe the functional constructs add a ton of utility to the language. The key is to understand how they were designed to fit into the langauge. It helps to be a bit of a language lawyer, but the compiler can optimize away copied value types in a way that references cannot be optimized.
WWDC spoke a lot on value types, functional programming, and their possible design implications in Swift 2.0
> 5) Swift's performance is definitely not, shall I say, "swift," though hopefully that will eventually improve.
Swift is more than fast enough for applications development. Once an alternative to ARC rises (see comments bellow), it will be a competitor for real time systems.
ARC guarantees that there will be no pauses. With a language like go, you are blazing fast until the GC pauses everything. With ARC trade raw execution speed for a consistent and stable speed with no pauses or fluctuations in performance. This is because ARC is static. The retain/release code is injected at compile time. So while there is a performance overhead for allocating and deleting on the heap, there is no pause. To avoid the overhead, you can use structs instead of classes and protocol extensions for polymorphism.
6) Poor and confusing compiler errors.
The language was released in 2014. The error messages are being actively worked on. They were vastly improved with 2.0.
EDIT: to be fair, you did say "I'm sure it will improve".
There's nothing technically wrong with it, and there are definitely situations that may require it. But IMO, in a huge ViewController, you ideally want to avoid using Objective-C++ code directly. It's better to use wrappers. This is mostly because Objective-C++ has many surprises and is poorly documented. It can be a PITA to debug.
It's a better practice, IMO, to isolate your Objective-C++ code into individual .mm files if you can. Try to keep the majority of your code in .m, or .cpp files and use wrappers. The idea is to try and work with a pure C++ or Objective-C compiler for each compilation unit, wherever possible. The saner compiler will save you a few headaches.
What would be really cool is some kind of cross-platform framework that would make OCaml viable for both Android and iOS development. If you're going to go to the effort to switch languages, you'll probably want cross-platform support in that language.
