Haskell has one of the best FFIs I've ever seen; calling C code from Haskell is quite trivial, and you can write all of the necessary wrapper code and objects (such as automatic memory management or object destruction) in Haskell using common wrappers.

I'd also highly recommend c2hs for writing new wrapper libraries.

Part of the problem is that iOS APIs tend to be Objective-C, which is somewhat harder to wrap in Haskell.

Not really, it's quite easy to call Objective-C methods (or more correctly, to send messages to Objective-C selectors) and perform other Objective-C-related tasks from C. See: https://developer.apple.com/library/mac/documentation/Cocoa/...

This is actually what the Objective-C compiler does. It translates your Objective-C code to C method calls.

It's not that easy. I mean, just sending a message could entail one of objc_msgSend, obj_msgSend_stret or objc_msgSend_fpret, and which one you want to use is not always as clear-cut as you might prefer (http://www.sealiesoftware.com/blog/archive/2008/10/30/objc_e...). And then there's the hassle of defining classes dynamically, which entails six function calls just to create a class with one empty method, and one of those essential functions is not actually provided for you AFAIK unless you're using Apple's compiler where it's a builtin, so you'll need to write it yourself.

It's not ridiculously hard, but it's somewhat less easy than normal C FFI.

The other hard part about it is that Haskell's FFI doesn't support variadic functions in a friendly way, which makes argument passing that much trickier.

If you just need to call variadic functions with a specific parameter list determined at compile time, that's easy with the existing FFI; just write a prototype for the function for any given set of arguments you want to call it with. (For instance, you can have an FFI binding printf_int_float :: CString -> CInt -> CFloat -> IO CInt .)

If you really need to construct calls at runtime and you don't know the argument list at compile time, there's a Haskell binding to libffi. However, you generally only need that if you're writing a language interpreter or similar.

There is a similar problem with objc_msgSend in C: Methods with certain argument types can't be called with a normal objc_msgSend(). Instead, you need to create a specifically typed function pointer and assign objc_msgSend to it. I think a similar solution would be necessary with Haskell.

I'd appreciate seeing a link to an example of this. I put a decent amount of work (a few years ago) into writing some bindings in Haskell to the objc runtime, but ended up shelving it until I could come up with a satisfactory solution to the variadic function dilemma.

Here are a couple of Stack Overflow answers that illustrate how you do it in Objective-C:

http://stackoverflow.com/a/2573949

http://stackoverflow.com/a/18689338

If you're interested in the nitty-gritty of how objc_msgSend works, bbum from Apple wrote up a great low-level walkthrough a few years back: http://www.friday.com/bbum/2009/12/18/objc_msgsend-part-1-th...

Doesn't calling C code interact poorly with green threading? (I assume that handlers that make it act slightly sanely exist, but I imagine the cost of setting up native threads for FFI is rather high.)

Native threads for FFI calls are pooled. It's not cheap, but it's not too expensive either.

I think the idea is that you would use the standard tools for the edges of the program with a Haskell core underneath handling the thinky bits. (I have no experience at all doing this, but it seems like the natural use case.)