Jeff has been maintaining it since, he just released 4.02.3 which is the latest available compiler http://psellos.com/2016/01/2016.01.the-minor-drag.html with iOS 9.2. Not that bad I'd say, that's pretty much bleeding edge. I don't know about swift because I don't know how to compile swift into an object file. Swift is not worth the hassle for me right now.
FWIW apparently it will be officially merged into the mainline compiler soon enough.
Have you encountered any problems with the App Store review process due to the application being written in OCaml?
I thought they don't like applications that are not written in Objective-C much.
These days, there are plenty of other frameworks for writing native iOS apps in languages other than Obj-C/Swift (Xamarin/Mono, RubyMotion, etc).
This wasn't always the case, but IIRC the current review rules only forbid having a runtime scripting language that isn't JS (since Apple can happily sandbox JS), but anecdotally even that isn't a problem these days (e.g. plenty of games use Lua for in-game scripting).
The restriction on scripting says you cannot download and run code, unless it's executed through WebKit or JavascriptCore. So other languages seem to be fine as long as the code to run is bundled with the application.
Here are some things that make ML (and OCaml in particular) a desirable language for mobile development.
1. Sound, static typing prevents entire classes of errors. This becomes even more important when you are shipping an irrevocable binary to users which you cannot update after the fact.
2. That same static typing can prove safe the removal of data boxing, and run-time lookup in order to increase performance.
3. OCaml (`ocamlopt`) does not run your program in a "Virtual Machine" like Java - instead it compiles your code more directly into machine code like C++. Many (but not all) of the other functional languages compilers produce a byte code, and then rely on a JITed Virtual Machine to (hopefully) optimize your code at runtime. `ocamlopt` compiles your program into assembly and you can inspect that assembly ahead of time in order to understand how it will perform. There's always tradeoffs with this approach, but the benefit is that you do not need to wait for (or hope for) a JIT to optimize your code (or re-optimize your code when usage patterns change).
4. OCaml is strict (as opposed to lazy), fairly close to the metal, and maps to lower level instructions in a fairly straightforward way - you would not be very surprised if you were to inspect the assembly. OCaml also has two ways to create bindings to C code. One way is easy and automated, the other way has better performance.
5. OCaml has a reputation for being able to allocate tons of memory at an impressive rate. To the extent that is true (and I've not yet observed anything to the contrary) I would imagine that would make it well suited to building UIs that are rapidly re-rendered.
6. OCaml has an Objects type system extension which makes it easier to create bindings to platform APIs (which tend to follow an OO design).
7. OCaml has two compiler modes: `ocamlc` and `ocamlopt`. Both support separate compilation, which is indispensable when building UI applications, where tweaking/reloading is very common. `ocamlc` would be ideal for that rapid development phase because, although it produces slower programs, it compiles them significantly faster. `ocamlopt` is ideal for shipping because it produces faster executables.
8. OCaml does not require that you write only pure programs. This makes it much easier to integrate with existing platform/mobile code which is also typically not pure.
Yes, for now. Although I have also cross compiled the entire iOS toolchain to Linux, even have objective-C code completion in emacs on Ubuntu! That is however another blog post and detail that I haven't written down about.
TL:DR It is possible for Linux as well, but haven't done it yet.
