Use C++ with Cocoa Instead of Objective-C?

Question

You cannot write a Cocoa application entirely in C++. Cocoa relies heavily on the late binding capabilities of Objective-C for many of its core technologies such as Key-Value Bindings, delegates (Cocoa style), and the target-action pattern. The late binding requirements make it very difficult to implement the Cocoa API in a compile-time bound, typed language like C++ⁱ. You can, of course, write a pure C++ app that runs on OS X. It just can't use the Cocoa APIs.

So, you have two options if you want to share code between C++ apps on other platforms and your Cocoa-based application. The first is to write the model layer in C++ and the GUI in Cocoa. This is a common approach used by some very large apps, including Mathematica. Your C++ code can be left unchanged (you do not need "funky" apple extensions to write or compile C++ on OS X). Your controller layer will likely make use of Objective-C++ (perhaps the "funky" Apple extension you refer to). Objective-C++ is a superset of C++, just as Objective-C is a superset of C. In Objective-C++, you can make objc-style message passing calls (like [some-objc-object callMethod];) from within a C++ function. Conversely, you can call C++ functions from within ObjC code like:

@interface MyClass {
    MyCPPClass *cppInstance;
}
@end

@implementation MyClass
- (id)init {
    if(self = [super init]) {
        cppInstance = new MyCPPClass();
    }
    return self;
}
- (void) dealloc {
    if(cppInstance != NULL) delete cppInstance;
    [super dealloc];
}
- (void)callCpp {
    cppInstance->SomeMethod();
}
@end

You can find out more about Objective-C++ in the Objective-C language guide. The view layer can then be pure Objective-C.

The second option is to use a cross-platform C++ toolkit. The Qt toolkit might fit the bill. Cross-platform toolkits are generally despised by Mac users because they do not get all the look and feel details exactly right and Mac users expect polish in the UI of Mac applications. Qt does a surprisingly good job, however, and depending on the audience and the use of your app, it may be good enough. In addition, you will lose out on some of the OS X-specific technologies such as Core Animation and some QuickTime functionality, though there are approximate replacements in the Qt API. As you point out, Carbon will not be ported to 64-bit. Since Qt is implemented on Carbon APIs, Trolltech/Nokia have had to port Qt to the Cocoa API to make it 64-bit compatible. My understanding is that the next relase of Qt (currently in release candiate) completes this transition and is 64-bit compatible on OS X. You may want to have a look at the source of Qt 4.5 if you're interested in integrating C++ and the Cocoa APIs.

---

ⁱ For a while Apple made the Cocoa API available to Java, but the bridge required extensive hand-tuning and was unable to handle the more advanced technologies such as Key-Value Bindings described above. Currently dynamically typed, runtime-bound languages like Python, Ruby, etc. are the only real option for writing a Cocoa app without Objective-C (though of course these bridges use Objective-C under the hood).

Well, it may sound silly, but actually we can write pure C++ code to create GUI for Mac OS X, but we must link against Cocoa framework.

/*
 * test1.cpp
 * This program shows how to access Cocoa GUI from pure C/C++
 * and build a truly functional GUI application (although very simple).
 * 
 * Compile using:
 *   g++ -framework Cocoa -o test1 test1.cpp
 *
 * that will output 'test1' binary.
 */


#include <CoreFoundation/CoreFoundation.h>
#include <objc/objc.h>
#include <objc/objc-runtime.h>
#include <iostream>

extern "C" int NSRunAlertPanel(CFStringRef strTitle, CFStringRef strMsg,
                               CFStringRef strButton1, CFStringRef strButton2, 
                               CFStringRef strButton3, ...);


int main(int argc, char** argv)
{
    id app = NULL;
    id pool = (id)objc_getClass("NSAutoreleasePool");
    if (!pool)
    {
        std::cerr << "Unable to get NSAutoreleasePool!\nAborting\n";
        return -1;
    }
    pool = objc_msgSend(pool, sel_registerName("alloc"));
    if (!pool)
    {
        std::cerr << "Unable to create NSAutoreleasePool...\nAborting...\n";
        return -1;
    }
    pool = objc_msgSend(pool, sel_registerName("init"));

    app = objc_msgSend((id)objc_getClass("NSApplication"),
                       sel_registerName("sharedApplication"));

    NSRunAlertPanel(CFSTR("Testing"),
                    CFSTR("This is a simple test to display NSAlertPanel."),
                    CFSTR("OK"), NULL, NULL);

    objc_msgSend(pool, sel_registerName("release"));
    return 0;
}

Yes, you can just use C++ (i.e. writing it in *.cpp files) and even mix C++ and Objective-C inside *.mm files (standard Objective-C code is stored in *.m files).

Of course, you still have to use Objective-C for your user-interface and create Objective-C wrappers for your C++ objects. Another option is to switch to Qt which is a C++ Framework that supports Windows, Mac OS X, and Linux -- and will be released under the LGPL with the next version 4.5.

Yes you can mix them.

You need to use Objective-C to directly operate on your GUI objects and receive notifications from them.

These Objective-C objects can directly call C++ logic if you put them in .mm files, instead of the pure Objective-C .m files. Note that you may see (much) older advice suggesting using an uppercase .M to indicate Objective-C++ but this is very flaky and likely to confuse you as well as the compiler.

You don't need to wrap each and every C++ object but your Objective-C code will need to contain pointers to them.

Apple no longer publish any samples showing how to do this.

There's a great video by Peter Steinberger hosted at Realm [Objective] C++: What Could Possibly Go Wrong? I highly recommend for anyone still using Objective-C++ and you can quickly skim the transcript.

If you're just looking to use plain vanilla C++, this is absolutely supported and really no different than any other platform. Xcode even has a template for it under File > New Project > Command Line Utility > C++ Tool. Also, a number of the popular open-source libraries (libcurl, libxml2, sqlite, etc) come with OS X and are available for dynamic linking. You don't have to use Cocoa or anything Apple-specific if you don't want to.

If you do want to use Cocoa in certain portions of your app, take a look at Objective-C++. You can mix C++ and Objective-C in the same file by giving it an extension of .mm, or by right-clicking on the file in Xcode and selecting Get Info > General then changing the File Type to sourcecode.cpp.objcpp. The second option is useful if you have a .cpp file where you want to use Objective-C within a Mac-specific #ifdef.

Though this is years old question...

I have tried to make C++ wrapper of some Cocoa classes.

It was pretty nice experience. C++ provided better type safety than Objective-C, and made me to write less code. But compile time and memory safety are worse. It is possible but some dynamic based features were not easy to handle. I think it doesn't make sense to deal with it on C++.

Anyway my project was finally abandoned due to announcement of Swift. It cleared all the reasons I wanted to use C++ at first, and provides even more and better.