<p>I'm exploring the possibility of writing an application in Erlang, but it would need to have a portion written in Cocoa (presumably Objective-C). I'd like the front-end and back-end to be able to communicate easily. How can this best be done?</p>

<p>I can think of using C ports and connected processes, but I think I'd like a reverse situation (the front-end starting and connecting to the back-end). There are named pipes (FIFOs), or I could use network communications over a TCP port or a named BSD socket. Does anyone have experience in this area?</p>

One way would be to have the Erlang core of the application be a daemon that the Cocoa front-end communicates with over a Unix-domain socket using some simple protocol you devise.
The use of a Unix-domain socket means that the Erlang daemon could be launched on-demand by
```
launchd
```
and the Cocoa front-end could find the path to the socket to use via an environment variable.  That makes the rendezvous between the app and the daemon trivial, and it also makes it straightforward to develop multiple front-ends (or possibly a framework that wraps communication with the daemon).
The Mac OS X
```
launchd
```
system is really cool this way.  If you specify that a job should be launched on-demand via a secure Unix-domain socket,
```
launchd
```
will actually create the socket itself with appropriate permissions, and advertise its location via the environment variable named in the job's property list.  The job, when started, will actually be passed a file descriptor to the socket by
```
launchd
```
when it does a simple check-in.
Ultimately this means that the entire process of the front-end opening the socket to communicate with the daemon,
```
launchd
```
launching the daemon, and the daemon responding to the communication can be secure, even if the front-end and the daemon run at different privilege levels.