Giving up the leadership of OGRE was a sad moment for me, but in hindsight it has also been rather liberating. For 10 years I’d spent most of my energy on OGRE or on projects that were related to OGRE. There was an implicit understanding both from the community and from myself that everything I embarked on would in some way tie into OGRE – and indeed my business has always been based on a constant balancing act between how I can make a living while also promoting and advancing OGRE. I’d tended to major on the latter rather than the former most of the time as it happens, because I had an emotional attachment to the project and a feeling of responsibility and custodianship that I took very seriously. So when I finally admitted to myself that my back couldn’t take the ongoing demands of being an open source leader as well as making a living, the big question was: what next?
Over the years I’ve learned a couple of things about choosing what projects to work on – follow your gut, and work on things you’d do even if there was no money in it. Yes, you need to do a business case and convince yourself that there’s a viable market for what you have in mind, but all that’s irrelevant if you don’t feel strongly about what you’re doing, because it’s passion and enthusiasm that will get you through the difficult times. So I sat down and gave some thought to what really excited me these days, what I liked using and what technical directions piqued my interest. I still find 3D and games fascinating, but they’re far from my only interests.
So, I realised that one area that I’ve been dying to get my teeth into properly for ages but had never found the time before, was coding specifically for Mac OS X. In 3 years I’ve gone from a total newcomer to the platform, to a staunch advocate of it. However until now I’d never really had time to play with developing on it, beyond porting cross-platform C++ code and providing / using intermediate libraries. One thing I learned in those 3 years as a user was how much better applications designed for OS X felt to use compared to those that were just ported via a common UI layer (like wxWidgets / Qt), and I’m convinced now that while cross-platform infrastructural code is great, user experiences are far better when designed with the specific platform in mind – increasingly that means OS and physical device now of course. Sure, cross-platform UIs save the developer time, but the result is often a watered-down experience – early on I liked OS X applications that felt like Windows, or ran the same on both platforms – now I do not. Such carbon-copying applications were helpful while I was unfamiliar with the platform, but now it’s just glaring to me how basic their compatibility with the OS typically is, and how the UI styles clash with the expected standards.
So, I decided I wanted to learn how to target OS X specifically, and had a couple of ideas for projects I could do with it, which meant learning Objective-C. At first, I hated it and tried to escape via more familiar technologies like Objective-C++ and PyObjC. Ultimately I found shortcomings and limitations of those routes and returned to Objective-C, and the more I used it, the more my animosity toward it diminished. In the end I realised the problem was that I needed to adapt to the environment, rather than try to adapt it to my previously learned styles and behaviours. Sure, missing elements like namespaces might still nag me, but on balance the blend of static and dynamic language elements works very well for the intended use. And besides, I really didn’t want to be ‘that guy’ – the programmer that having decided one language / tech is ‘the best’, then tries to apply it everywhere, regardless of suitability; I like to think I’m a bit more flexible & multicultural than that.
I’ve also learned that Cocoa is a very, very smart system. Mad as a bison if you’re used to other systems beforehand, but persevere with it and resist the urge to hide it under some vanilla layer that you’re already familiar with, and you discover it’s really very powerful. Not to mention the Core Animation and Core Graphics frameworks are a lot of fun.
It’s funny, I’ve spent so many years concerning myself with providing compatibility across multiple OS’s, multiple GPUs, multiple render APIs, and multiple drivers, it’s a genuine joy to actually forget all that for a while, and concentrate on an end goal with a finite number of permutations for a change – and not to shy away from using platform-specific features.
While I’m still very much an advocate of open systems, I look at things slightly differently now – that data & protocols should be open, and that we should all re-use & collaborate on common, preferably open source infrastructure (like OGRE), but that the ‘last mile’ to the user is the least suitable for generalisation, because the more specific you can make that interface to what the user expects on their OS & device, the better that experience will be. And at the end of the day to the user, that experience is the application, and thus all that really matters – and I feel that Apple gets that, in a way that very few others do.
So, I’m having a great time learning to be an Apple developer so far, I’m going to see where this takes me for a while. My gut says it feels right, and I’ve learned to listen to my gut 
I love the platform, it’s a total change of pace and technology, it’s something I’ve had an interest in for a while, and the Mac has quite a thriving community of quality independent app developers that I can try to join – what’s not to like?
A common requirement in any Cocoa application is a preference pane style window where each toolbar item switches to a different view in the main window, resizing as necessary. I’ve used 
Home