Tag Archives: Mac

Business Development OS X

Mac user base by country: my figures so far

As many of you probably know, almost a year ago now I decided to take the plunge and move my primary development activities to the Mac. I taught myself Objective-C, got properly to grips with Cocoa at last, and started a new Mac OS X-specific project which would eventually become SourceTree, learning a ton along the way (a process which is by no means complete!).

Happily, things have turned out very well – SourceTree continues to sell, reassuring me that there’s enough interest out there for me to keep expanding and improving it (I’m looking forward to getting the next major release in people’s hands soon), and I’ve also been getting some Mac/Ogre-based contract work which I’ve enjoyed a great deal. In short, my Macbook Pro and I are now pretty inseparable, Windows 7 is powered off 99% of the time, and I saved hundreds of pounds by not upgrading to Visual Studio 2010 ;)

Out of interest, I thought I’d share some of my SourceTree sales information, in terms of the country distribution. Mac use is typically associated primarily with the USA, and while that’s certainly reflected in my absolute numbers, there’s some quite interesting figures revealed when you take into account population size. SourceTree is aimed at developers of course, so all numbers reflect this audience alone (and of course those that chose to buy it) but in practice I suspect that the proportions of developers to non-developers is fairly uniform in most developed countries.

So, firstly the absolute distribution:

No surprises there, the USA is the single largest source, followed by Germany and the UK (who are constantly scrapping over second place!). To me though, Switzerland stuck out as the most interesting, because it’s up there in 4th place yet has a relatively small population (under 8m). So I wondered – what would the chart look like if I scaled it by the population size? Here’s the result:

And there you go – as expected Switzerland jumps right to the top, and to my surprise Luxembourg and Denmark are up there too, beating the UK which I expected to come in second. Quite a lot of European countries are punching above their weight in per-capita Mac development, if SourceTree sales are any indication. In fact, on a per-capita basis, the USA is only just sneaking into the top 10, despite it being by far my best overall customer in sheer sales volume.

I’m aware that scaling by population isn’t all that scientific, since it is sensitive to the proportion of non-developers (and even non-computer users), but as I say, I think in developed countries at least, the comparisons are reasonably valid.

So the perception that Mac development is more popular in the USA than elsewhere may be inaccurate, based on my numbers at least (which of course are not massive in the grand scheme of things, but still a statistically relevant sample I think). Sure, simply because of the sheer population size of the USA it’s bound to dominate anyone’s sales numbers, but if you asked the question ‘of 1000 randomly selected developers in a country, what percentage are using a Mac?’, the result may not be skewed in the way you might expect. It was surprising to me, anyway.

I wonder if anyone else who has been doing this for longer has had similar results?

OGRE Personal

Farewell 2010

I don’t blog as much as I used to, for reasons which are somewhat relevant to this post – rather you can usually find fragments of my consciousness floating around the Twittersphere instead, since its enforced brevity requires considerably less of my time to populate. Maybe I’m old fashioned, but I believe that if you’re going to write a blog post about something, you should probably make sure it’s written in a half-decent way, and that’s fairly time consuming, particularly when you’re ever so slightly anal about language as I am. Nevertheless, the receding silhouette of 2010 is a worthy enough subject to invest a bit of time in, so here I am, verging once again on being dangerously verbose. I guess the post should have started with a warning banner or something – but if you’re a repeat visitor, you know the score.

So, 2010. I started this year with three significant and intersecting goals: to significantly simplify my working life, to reduce my stress levels, and to spend more time in the company of my own creativity by working on my own projects. The reason was this: by the end of 2009 several factors had led me to a situation where I had my fingers in too many pies, too many balls in the air, too many – well, you get the picture. The thing with being a consultant / contractor is that work comes in with a very uncertain frequency; projects have a tendency to ‘bunch up’, and because of the inevitable lean periods in between you don’t really want to say ‘no’ to anything. The economic situation since late 2008 also led to projects being noticeably more cost-sensitive, meaning more juggling required to fill out a coherent schedule than it had been before that. All this could get quite stressful, and with a back problem to nurse and an open source project to run on top, things weren’t that much fun at times. So my resolution for 2010 was to stop just trying to make the status quo work, and instead to do things my way – to ditch smaller pieces of work, to only get involved in larger projects that I found personally interesting, and to spend the rest of the time investing in my own projects instead. Fundamentally it was about taking control back.

At that time I didn’t plan to retire from OGRE, but in hindsight I think subconsciously I’d made the decision already, I just hadn’t admitted it to myself yet. I’m extremely proud of what I managed to accomplish with OGRE with the help of countless contributors, and was sad to put that role aside after 10 years, but in many ways it had become a rod for my own back. Not only was it a hugely time consuming, 24/7 job to look after, but there was an inherent assumption, from others and from myself, that projects I chose to work on would naturally be associated with OGRE in some way. That was quite a pair of blinkers to have on, even if I didn’t know I was wearing them. If success with a product or in a subject area has a downside, it’s probably that it can become a gravity well which resists you exploring other areas of interest. So while I’m sad to have retired from OGRE and look back on my time on the project with a great deal of fondness and pride, I can’t deny that I don’t regret casting off and returning to the open seas, even if the security of the harbour was comforting. Ok, I’m done with the sailing metaphors now. ;)

One unexplored continent (damn!) which was calling me siren-like (ok, I really am done now) was native Mac development. I bought my first Mac in 2007, initially only to support OGRE on it (before masterfalcon came along with his superlative Apple-fu), but I’ve since been converted to a fully card-carrying Mac nutcase. So, I decided to finally go all-in and learn Objective-C and Cocoa, and make my own Mac-only tool, which of course turned out to be SourceTree. I’m very pleased with it, and if anything my predilection for the Mac platform has increased significantly during this time – I’ve barely used Windows in the last 8 months, and now when I do I find it quite unpleasant. I also went from hating Obj-C (as a C++ user) to really liking it in the space of a few months, and I’m quite happy to include it on my resume now.

The other thing I find, now that I’m juggling fewer balls and am less narrowly focussed, is that my creativity has ramped up considerably. My ‘Project Ideas’ file has swelled significantly during 2010, and I hope to have chance to pick off some of the juiciest of them later in 2011.

So, I guess the important thing in a retrospective is to decide whether I achieved my goals in 2010. Given that my back is much better now, I’m less stressed, more creative and I have a new product out, I guess the answer is yes. Not everything went to plan of course – SourceTree launched later than I’d intended (isn’t it ever thus?) and still has quite a way to go to recoup its investment, my only Mac died a month into me starting Mac-only development (but on the plus side that gave me an excuse to buy a new one, and Apple ended up repairing the other one free even out of warranty), and I’m still not completely recovered health-wise, but all in all, even if it’s not a double rainbow, it’s gotta be at least a rainbow and a half. ;)

My best wishes to everyone for the New Year celebrations, and I hope we’ll all have a happy, healthy and prosperous 2011.

Business Cocoa Development Objective C Personal Tech

Introducing: SourceTree

I’m pleased to announce that I’m finally ready to make my first fully-fledged commercial Mac OS X application available to the world!

SourceTree is a user-friendly Mac OS X front-end for Mercurial and Git, the two most popular distributed version control systems used today. The goal was to create a single tool which could deal with both systems efficiently, and to give a developer quick and intuitive access to the things (s)he needs to just get on with building software.

I thought I’d answer a few background questions on this that I get asked on occasion:

Why Mercurial AND Git?

Other apps tend to concentrate on just one version control system, so why am I supporting two? Well, as a developer I’m regularly coming across projects from both sides of the fence, and in practice I find I need to use both fairly regularly. I personally chose Mercurial for my own projects (and discussed why here), but I still use Git when dealing with other projects, and spend a fair amount of time hopping between the two. It struck me that even though they have their differences, they are both based on the same distributed principles, so having to use two separate tools was just unnecessary. I wanted a single tool which provided a common interface where that made sense, while still exposing the things they do differently where that was useful too. SourceTree 1.0 is my first attempt at that.

Why only Mac OS X?

There were actually multiple reasons for this choice:

  1. I wanted to learn Objective-C and Cocoa on a real project
  2. I know from experience that designing for multiple platforms can be a distraction, with more time spent on compatibility issues, and less on functionality – and that’s before you even consider the compromises  you have to make, particularly on UI conventions which are far from uniform across platforms. I’ve been a multi-platform developer for more than 10 years, and for a change I just wanted to focus on the end user results and nothing else. I’m aware that schedules slip very easily when you overcomplicate, and I’m already supporting multiple DVCS systems (something I consider to be an important feature point), so I deliberately chose to keep this element simple.
  3. Mac OS X has become my own platform of choice for most things now. The combination of stability, user-friendliness, Unix underpinnings and well designed hardware match my current needs perfectly. I’m done with the ‘some assembly required’ PCs that I loved tinkering with over the past 15 years

What about Subversion?

A few people have asked me if I plan to add Subversion support too. I actually did intend to originally, until I realised how much time it was going to take to just do a decent job on Mercurial and Git. Within the time constraints, I focussed on the subject areas that I felt I could contribute most to – there are already quite a few Subversion tools out there for Mac OS X, but Mercurial and Git are much less well served, so that’s where I focussed my efforts.

I still have Subversion support tentatively on my work plan, but it’s not top of the list. I think it’s better to do your most important features well before diversifying. Plus, there are problems with Subversion – it’s very, very slow compared to Mercurial and Git, so to match the performance in SourceTree of things like the interactive searches and dynamic refreshing / log population I’d probably have to do a ton of extra caching just so the user wasn’t sat tapping their fingers.

Edit: I made my decision on this: I don’t plan to support local Subversion, but to support operating with Subversion servers with Mercurial and Git locally via hgsvn and git-svn.

Why didn’t you make it open source?

Sorry folks, while I love contributing to open source (I’ve done a bit on SourceTree too, sending a patch back to BWToolkit), making it work as a business is very hard indeed. I half-killed myself trying to combine being an open source project leader and doing other commercial activities at the same time, so now I’m trying a more traditional approach. One thing I learned in the last few years is that there are some sectors & application types where being an open source maintainer is very compatible with also running a business based on that project, and there are others where you can really only do one or the other simultaneously without flaming out. Sucks, but there it is ;)

What’s Next?

I have a public, official roadmap for SourceTree and encourage users to suggest things they think should be on there, via the support system. I learned from running an open source project for 10 years that being open about your plans can be a big benefit – users like to know where things are likely to be going, and often have better ideas than the developer on what could do with a bit more spit and polish. They can also tell you what’s important to them, which is crucial for prioritising – as developers we tend to get carried away with things we want to work on, but in the end, it’s scratching the customer’s itch that matters most.

And while I’m really quite proud of SourceTree 1.0, there are plenty of features I’d like to continue to add, and definitely more room for some totally unnecessary beautification which I didn’t have time for in the first release. Hey, this is OS X ;)

SourceTree is available now on a 21-day trial license. Go get it already :)

Cocoa Development Objective C

Cocoa tip: using custom outline view cells designed in IB

I only started learning Objective-C and Cocoa in mid-May, and for the first time I think I actually have a tip to contribute to the wider community. It’s about using custom cells in NSOutlineView, but those which you want to design inside Interface Builder rather than drawing manually.

If you’re an iOS developer, you’ll be wondering why this deserves a blog post – it’s easy to do in Cocoa Touch! Well, yes it is easy on iOS, because Apple have specifically allowed you to design table view cells in Interface Builder. When targetting Mac OS X though, it’s actually pretty awkward, and here’s why: in Cocoa Touch, the class which draws the cells in a table is UITableViewCell, which is a subclass of UIView – meaning you can drag one onto the canvas in Interface Builder and lay stuff out right there. In Cocoa, in contrast, the cell is simply represented by NSCell, which is not an NSView subclass. This means Interface Builder will not let you play with them, you draw them by implementing drawWithFrame:inView: instead. I think Apple realised the problem with this design in time for Cocoa Touch but obviously felt they couldn’t break the existing Cocoa interfaces. There are also many differences between the instantiation of NSCell versus UITableViewCell – there’s only one NSCell for all rows in a table / outline view, compared to a type-indexed pool in Cocoa Touch.

The problem boiled down to this: if the contents of your table / outline cell is non-trivial, or if you just don’t want to write a bunch of layout code, it’s a PITA to implement a custom look in NSOutlineView, such as the one in the picture, especially if you want custom controls embedded in it. For my current Cocoa app, I really wanted to design my cells (and I have 2 different styles for group levels and detail levels) in Interface Builder to save me hassle, including using Cocoa Bindings to hook up some dynamic fields within. Many internet searches later, and mostly the answer I found was that it couldn’t be done. Luckily, I’m too stubborn to take no for an answer, and eventually I figured out a way to do it. Details are after the jump, with an example project to show it in action.

read more »

Development OS X

OS X Localisation: incremental genstrings and UTF-8 files

I came across a couple of interesting issues when I came to do the first pass of writing the text for the user-visible strings I’d been setting up for a Cocoa app I’m writing (painfully slowly as I learn the nuances of the environment), and I thought I’d share them. Full details are after the jump, since I’ve embedded a large script in the post.

The basic principle for text localisation on OS X is that, like most systems, you externalise your user-visible strings in string tables and reference them by keyed aliases in code – in this case using NSLocalizedString. Apple provide a tool called ‘genstrings’ which extracts all these into a template strings file called Localizable.strings which you can then populate per language – localised files are kept in folders called en.lproj, fr.lproj etc and helpfully they’re picked up by default like this.  So far, so good.

read more »

Development OS X Personal

Taking a bite of the Apple

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?

Games OGRE OS X

Monsieur, you are really spoiling us

Yesterday saw a triple-whammy of sugary Apple gaming goodness:

  1. Steam for Mac was released, meaning all the games you own on Steam that are ported to the Mac can also be played there, free.
  2. Torchlight was a day-1 release on the service, meaning Ogre (and therefore code written by me) was among the very first on the service.
  3. Portal became free (for Mac and PC)

Wow. A great day for Mac gaming. I noticed that World Of Goo was up on day 1 too, and since I’d bought it on Steam I could play it right away on my MBP too. Yummy.

Curiously, considering it’s based on Ogre, I don’t actually own Torchlight on Steam – I had a free Windows-only copy from Runic, I bought a physical (Windows-only) copy for my shelf, and I bought copies for both my wife and Diablo-obsessed brother in law on Steam but I never got a copy there myself, so I haven’t tried it on the Mac yet. I need to ask my wife to log in on the MBP so I can try it! :)

OS X Tech

Accented characters on OS X

I can’t believe this is the first time I’ve needed this on OS X, but it came about from needing to write a document for a European customer and suddenly realising I didn’t know how to make an umlaut on my Macbook Pro’s British keyboard. On Windows I might fire up the Character Map, but I didn’t know how to do it on OS X. Here’s what I discovered:

  1. OS X friendly apps like Mail, Safari, iCal and even Firefox have a ‘Special Characters’ entry on the Edit menu which brings up an equivalent of Character Map.
  2. For less OS X friendly apps (like Open Office), you can add a menu bar item to do the same everywhere under System Preferences, Language & Text, Input Sources – check the Keyboard and Character Viewer option and make sure the Show Input On Menu Bar is enabled. Then you just click the new icon on the menu bar every time you need the character browser.
  3. The most common ones have keyboard shortcuts which modify the next character you type afterward – Option-e puts an acute accent on the next character you type, Option-` is a grave accent, Option-u is an umlaut, Option-i a circumflex, Option-n that weird Spanish squiggle ;) While experimenting I found the ® and © symbols too (Option-r and Option-g respectively, Option-c is the cedilla)

So there you go – useful stuff if you’re on a British (or presumably US) keyboard and need to deal with non-English names from time to time. If you already knew this, great – this is just for people in my position who have to use these characters rarely and haven’t encountered it on a Mac yet.