Call OCaml from Objective-C, run on iOS, code sample and build steps

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:

http://www.tiobe.com/index.php/content/paperinfo/tpci/index....

Few new iOS books are written using ObjC and few developers blog with it. Take notice when you read your next blog or see a new iOS book published.

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

see: https://developer.apple.com/videos/play/wwdc2015-408/

and: https://www.youtube.com/watch?v=av4i3x-aZbM

and: https://www.youtube.com/watch?v=vgK8jaf8nlk

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