Q:

Accessing OSX APIs from iOS app running in Simulator for debugging

For debugging purposes I am looking for a way that a iOS app (whose source code I have access to) can communicate with a separate OSX app, e.g. via sockets.
Since an iOS app running in the Simulator runs natively on the Mac, by using specially designed iOS simulator frameworks that route I/O through OSX frameworks, there must be a way that I can achieve that with my own code as well.
Simply adding standard OSX frameworks to the project and using them from within the iOS app does not work:
If I try to load a OSX framework that exists already as a iOS framework, the iOS framework will always be preferred, meaning if a framework function is only available on OSX but not in iOS, I can't get to it. If the framework doesn't exist yet, like Carbon.framework, then I can get the linker tries to load it. For instance, if I'd try to get to SysBeep(), which is part of Carbon.framework, the linker then fails with an error msg when it wants to resolve external symbols that point to other libs that are already loaded as a iOS-only lib.
I've also tried loading a OSX specific framework using dlopen(), but that fails just the same.
In other words:
How can my iOS code get access to the OSX-specific libs additionally?

A:

That's a lot of questions at once. Let's go step by step:

For debugging purposes I am looking for a way that a iOS app (whose
  source code I have access to) can communicate with a separate OSX app,
  e.g. via sockets.

It's definitely possible to use OS X facilities from within the iOS app process running in the simulator. Using plain sockets would be very simple as the BSD library is identical in both iOS and Mac OS. You can simply compile your C code and it would use the underlying OS transparently.
If you wanted to use an Objective-C API like NSURLConnection you can do this as well. In the simulator your app uses the Mac OS version of Foundation and Core Foundation. In most cases you would not recognize this as the API is very similar.

[...] the linker will have trouble keeping things apart due to name space
  collisions [...]

It's not really clear what you are trying yo achieve here. As I explained, the simulator process uses proper Mac OS lower level frameworks directly. It does not make sense to link to higher level frameworks like AppKit since the app does not make use of Cocoa desktop components. That's why there is no NSApplication symbol and the app does not instantiate one. Instead it uses the UIApplication class from the simulator's specially crafted UIKit framework located in
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.1.sdk/System/Library/Frameworks/UIKit.framework

[...] Building the above then leads to a linker error [...]

That's because the linker is directed to only look into the iPhoneSimulator SDK where no AppKit is present (using a linker flag like -isysroot <path-to-SDK>).
But at this point it's probably worth asking yourself why you want to link to AppKit in the first place. You can set up you interprocess communication without AppKit.

Oh, and to prove that it must be possible somehow, take a look at RubyMotion [...]

In the simulator event handling is done in the "iOS-Simulator.app" process (which is a Mac OS application). To get at these events from within your simulator process you could probably use Quartz Event Services.

