Whew. Scott, thanks for steering us away from the Carbon vs. Cocoa debate yet again.
I have recently worked on 2 cross-platform applications, both of which had a core C++ base. The difference was whether the Mac UI was an afterthought or not.
In the first, it was Mac Carbon and Windows MFC from the start, but we evolved the UI to Cocoa on the Mac side and .NET on the Windows side, with almost everything directly below the UI in cross-platform C++. This takes a bit of planning and coordination (not to mention experts on both platforms), but is absolutely the right way to approach development because you are thinking about the whole of both platforms at the same time, and you have the flexibility to embrace Mac conventions and technologies.
In the second project, I started with an MFC Windows app that was several years old and which was not really going to change. I ended up re-implementing my own subset of MFC and Win32 in Cocoa so that I could maintain compatibility with the Windows code, while still being able to go in with NIBs and tweak the UI. While it had many advantages over a pure cross-platform framework, some parts of the Cocoa UI were still driven from Windows code, so weird artifacts and usability problems will poke through.
by Manton Reece — Mar 22
I have recently worked on 2 cross-platform applications, both of which had a core C++ base. The difference was whether the Mac UI was an afterthought or not.
In the first, it was Mac Carbon and Windows MFC from the start, but we evolved the UI to Cocoa on the Mac side and .NET on the Windows side, with almost everything directly below the UI in cross-platform C++. This takes a bit of planning and coordination (not to mention experts on both platforms), but is absolutely the right way to approach development because you are thinking about the whole of both platforms at the same time, and you have the flexibility to embrace Mac conventions and technologies.
In the second project, I started with an MFC Windows app that was several years old and which was not really going to change. I ended up re-implementing my own subset of MFC and Win32 in Cocoa so that I could maintain compatibility with the Windows code, while still being able to go in with NIBs and tweak the UI. While it had many advantages over a pure cross-platform framework, some parts of the Cocoa UI were still driven from Windows code, so weird artifacts and usability problems will poke through.