How so? Surely lots of people have done this sort of thing before? Well, that’s true, they have – but the problem is that just about all of the existing examples of this use the Authorization Services API call AuthorizationExecuteWithPrivileges – and this method is deprecated in OS X 10.7 (Lion). Now, of course that doesn’t stop you using it (yet), provided you’re willing to turn off the warning that building against the 10.7 SDK gives you, but any programmer worth his salt should take deprecation as a hint that they should be looking for another way.

There are basically 3 ways to escalate privileges on OS X, and only one of them is now recommended:

1. Use a helper tool which has its setuid bit set so that it runs as root. Risky if that tool gets compromised, and the setuid bit can be lost, needing reinstatement by another privileged task.
2. Execute a command as root via AuthorizationExecuteWithPrivileges. As mentioned above, this is now deprecated, and again if a hacker compromises either the app or the tool being launched, bad things can happen.
3. Ask Launch Services to install a privileged helper tool via SMJobBless. This helper is subsequently run by launchd as root when invoked via a Unix socket, and can perform privileged tasks. Importantly, code signing is verified at both ends by Launch Services at install time to prevent tampering with either binary.

Clearly option 3 was the way to go – the only ‘downside’ about it is that is does require that you have the ability to sign your application and helper tool. I already have valid code signing certificates because I deploy on the App Store, so this isn’t an issue (even though this functionality won’t actually be in the App Store version of SourceTree because Apple disallow installer behaviour there, I still sign with the same certs). In fact, the fact that I know my app and helper tool can’t be interfered with without the code signatures becoming invalid is very reassuring. Given that it only costs $99 per year to be on the Mac Developer Programme which allows you to get certificates (even if you don’t deploy on the App Store), it’s something serious developers should consider strongly.

SMJobBless is ideally suited to installing daemons, but it’s perfectly acceptable to install tools which run simple one-off tasks too. When setting up the plist for the helper, you specify that it is ‘OnDemand’, with no ‘KeepAlive’ which means it’s not started by Launch Services at startup, only when a Unix socket is opened, and shuts down very quickly if there’s no activity. Unfortunately the SMJobBless example doesn’t do anything except to show you how to install a tool, it doesn’t tell you how to implement that tool to do anything useful, or how to call it from your main application.

To see how to do that, you need to refer to BetterAuthorizationSample , which includes a re-usable library for this. Ironically though, this example uses AuthorizationExecuteWithPrivileges to install its helper (this example pre-dated its deprecation in favour of SMJobBless). So you have to remove all the code associated with installation; you won’t need it anyway since SMJobBless does that function better. You keep the rest which gives you a framework for implementing and calling the helper. So here’s what I did:

1. Implement the installation of a privileged helper, based directly on the SMJobBless example. I needed to change the bundle IDs and the certificate CN’s to match my setup of course.
2. Extend the plist files from SMJobBless to register the helper with a socket. This was basically a case of copying the settings from the BetterAuthorizationSample plists, which already does this.
3. Bring in BetterAuthorizationSampleLib.c/.h to assist with implementation of the helper, and the code for calling it in the app, but remove everything in the ‘Installation’ section. This eliminates all the references to AuthorizationExecuteWithPrivileges – we’re doing the install with SMJobBless so don’t need that.
4. Follow the BetterAuthorizationSample for the implementation of the helper, and the bit in the application where you call the helper to perform privileged operations.

So in my case, the following happens when you click ‘Install Command Line Tool’ in SourceTree:

1. A privileged helper is installed in Launch Services using SMJobBless. OS X checks the code signatures on both ends to ensure that the helper and the application asking to install it are valid (must be signed with my cert, and that cert must be issued by Apple).
2. A connection is opened to the privileged helper over a socket which causes launchd to start it up
3. I ask the helper via the BetterAuthorizationSampleLib to install the command-line tool in /usr/local/bin. As an additional check, the helper validates via ‘codesign -v  -R=”conditions”‘ that this tool is code signed with my cert (again, must be issued by Apple) – this is to prevent anyone else sniffing out this socket and trying to use it to install other things. If that passes, it installs the command.

This is quite a long-winded process compared to just calling a ‘cp’ command via AuthorizationExecuteWithPrivileges, but it’s also a lot more secure, since a malicious person can’t alter any of the moving parts without invalidating the code signatures. You’re also insulated from future changes when inevitably AuthorizationExecuteWithPrivileges is removed entirely.

I apologise for the lack of a pre-packaged example here – I haven’t had time to extract one from my own implementation yet. However, as described above if you start with the SMJobBless sample and add-in the BetterAuthorizationSample, removing from the latter everything associated with installation, you’re basically there. If I get chance later I’ll post a shrink-wrapped example.

I hope that helps someone – I found there to be little information on this subject that was up-to-date, and lots of older information that was misleading so maybe this will save someone some time. Ideally, I hope Apple will combine the SMJobBless and BetterAuthorizationSample some time to produce a 10.7-compliant official example.

1. If you want to deploy on the Mac App Store, You have to customise it to remove all uses of private methods, since those are banned on the App Store.
2. It sometimes crashes Interface Builder – usually not fatally but it can get awkward
3. Sometimes it gets the window height slightly too tall when switching panes – I’ve patched it to try to cope with this but it still happens sometimes
4. It relies on using IB plugins. XCode 4 does not support IB plugins anymore – although you can still build the code, you can’t edit the nibs anymore

I’ve just been coping with 1, 2 & 3 so far, but 4 was the killer which made me come up with my own alternative: SSSelectableToolbar.

With SSSelectableToolbar, you can still do the preference pane setup entirely within Interface Builder, but it doesn’t require any plugins. There are a couple of extra steps required because of this, but they’re not onerous and still better than setting it all up in code.

The license is permissive MIT, usage is in the README, and there’s an example demo to show how it works. I hope it’s useful to someone else too.

One term which was bandied around a lot in this environment was ‘software engineering‘. The implication of this term, and the expectation of many people using it, is that designing and creating software is very much like physical engineering disciplines, such as erecting a bridge or building a block of flats. When a software project starts to go off the rails, and fingers are starting to be pointed, a common question is why large physical engineering projects can come in on time an budget, when most software projects beyond a certain size don’t? Surely if the people who create software claim to be ‘engineers’, they should be able to adhere to the same standards of other engineering professions?

At face value it sounds like a fair argument, and I’ll be the first one to admit that software engineers are very often not as rigorous as others bearing the title. But there’s a good reason – the belief that software projects are akin to building bridges is completely misplaced, and it is a belief which too often leads people to think that software projects should be run using techniques such as fixed prices, up-front design, and waterfall life-cycles. This is despite decades of case studies indicating that such techniques rarely work, and are more often a collective delusion adopted because the reality – that you’re never going to be able to predict a large software project accurately up-front – is too terrifying to be contemplated. The term ‘software engineering’, while indicating some of the responsibilities of such a person, is an incomplete definition of what building software actually entails, and just reinforces these misconceptions.

So, why is making software so different to building a bridge?

1. Software is intangible.
   You can see and touch a bridge, it has a physical presence you can measure and its purpose is absolutely obvious to any observer, as are its success and failure conditions (getting people across a gap without falling down). Even though there are parts of the bridge the user will never see, their purpose can be easily unambiguously defined – carrying utility cables/pipes, providing maintenance access, etc. Software is intangible, and even the part that is seen by those defining its purpose is often hard to evaluate until it can be seen and used directly, never mind the internal working processes. Evaluating and defining software ahead of time is like trying to describe a dream seen through a keyhole – incomplete and everyone has a slightly different impression, and regardless of how much you try to write it down, you can’t capture or communicate its essence completely to others, or guarantee that they interpreted it the same way.
   People are just naturally very bad at defining and evaluating intangible things. There’s no point pretending they can with 300-page requirements documents, you’re just wasting everyone’s time – accept that people won’t know what they like until they can play with it – iterate!
2. Interaction complexity
   There’s only a small number of ways to use a bridge, and they’re each quite straight forward. Yes, there’s much complexity to the structure of the bridge itself, but that really doesn’t matter to a person driving or walking across it – that doesn’t need input or feedback from people except for whether they like the look of it.
   Software is basically defined by complex interaction, which is often context- and data-sensitive. The number of variations mean that even if every one is bug free (yeah, right), there’s the question of whether it’s solving the correct problem, which is a function of people and their interpretation / opinion. While building projects can be complex, those complexities are most often a function of the engineering challenge, whilst most complexity in a software project is a function of the involvement of people, which are far more difficult to pin down.
3. Change is a constant factor
   Change happens everywhere of course – maybe the bridge builder discovers that the ground isn’t as firm as they thought, or suddenly someone wants to make an extra deck available for trains. Big disruption, and an effect on time and budget – all understandable. The problem when it comes to software is that the perception of change is very different. If suddenly you have to sink massive extra foundations or double the amount of steel you need to use, people understand the magnitude of that intuitively and accept the effect on the schedule. Changes in a software project tend to be perceived as ‘just a little tweak’ by those requesting it, which tends to mean tolerance for schedule impact is lower, and indeed the potential for interaction between changes in unexpected ways is often overlooked. Now, I’m not for a second advocating that change should not be allowed, but often the mechanisms that have been established for managing a project – up-front estimation, fixed feature sets and so on – prevent the efficient integration of change, or at least obscure its impact to a point where things become critical. It’s important to appreciate that change is more common and expected in software projects, by nature of the issues raised in the previous points, and therefore setting your expectations based on a discipline where change is less common is not a smart move.
4. Lack of hard limits
   Building  a bridge involves respecting some hard, unchallengeable limits. As a wise man once said “You canna change the laws of physics, Cap’n!”. When you’re building software, however, there are very rarely any unbreakable limits, and even the soft limits that there are tend to be invalidated very regularly as new technology comes on stream. No-one can realistically stand up and say ‘this is impossible’ when faced with a request, because almost nothing is impossible. Hard limits in physical projects make all stakeholders ‘get real’ – you can’t use more land than you have, you can’t build a skyscraper out of paper, there are non-negotiable rules for safe load-bearing and so on. Barring some really crazy and ground-breaking structures (which BTW, rarely come in on time & budget), these limits ground everyone involved in the project to realistic expectations. In a software project, reining in those feature requests, or those ideas that the implementors have for a new tech they could use, is much more abstract affair, and everything is up for debate.

All these things put together mean that if you think you can use the same kinds of techniques to run a software project as you would use for a building project, you’re kidding yourself. They’re so very different in fundamental ways, it’s like trying to catch a shark with a shrimping net (because it’s just a fish, right?).

So please, stop with these delusions:

1. that estimating the cost of any non-trivial software project (that isn’t just a carbon copy of something else) is any more sophisticated than mildly informed guesswork.
2. that it’s reasonable to think that a fixed-price can be realistic for any software project longer than a couple of weeks
3. that ‘change control’ is the about exceptions, rather than the norm

Of course, agile approaches attack these particular delusions rather well. But try to get those adopted in very large organisations where the ‘software is like a bridge’ mentality still thrives

The SourceTree 1.2 launch sale is now over, and I thought I’d post some indicative results. I went for a fairly large discount of 40% over a full week, and some people I know commented to me along the lines of ‘what about all that money you’ll be losing on each sale?’.

I decided on a large discount because SourceTree 1.2 was a major update that I was actually quite proud of, so I wanted to get it in front of as many people as I could. I was also aware that there might be people who tried SourceTree before, but who decided it wasn’t for them, and I wanted to encourage these people to try it again, since I’d made pretty big strides in this version on the overall appearance of the app and the smoothness of the workflow, in addition to all the normal new features. The way to do this of course is to make it worth their while to do so, by offering a discount that really grabs their attention. A 20% discount probably wasn’t going to do that effectively, but 40%? That’s almost half price! It’s this sort of gut reaction I was looking to promote.

The other thing I was acutely aware of is that you have to be careful not to have too many sales. If you go on sale too often, people are going to start assuming that there’s a sale coming almost any time of year, so will avoid buying unless there’s a sale on. In my opinion, sales need to be infrequent, but big and attention-grabbing when they do happen.

So actually my goal for the sale wasn’t necessarily to make more money than usual, but to get more eyeballs on the new version, and more active users, which I hoped would then translate to more awareness and more sales further down the line, because satisfied customers are the best marketing resources you can ever have. Solid reasoning, but as it turned out, things went much better than I could have hoped, so in the end I actually achieved both at once.

So for those people who were wondering whether having a sale is worth it, my results are on the right, in fashionable infographic form

As I said above, what I was really looking for was to reach more people, and I certainly did that – with a 793% increase in units sold in the sale week, that’s about 2 months’ worth of new users in one week. And as you can see, in value terms it also ended up a considerable net positive even with the 40% discount – now of course I’m expecting sales to be more sluggish immediately following since the sale will have caused people to bring forward their purchase, but I’m pretty confident it’ll remain positive even with that compensating effect.

So why am I writing about this? Am I doing it to strut around flashing my ‘wad’ at people? No, and if I’d included the actual $ values you wouldn’t think that anyway – they’re fantastic news to me but they’re in the ‘I can keep doing this sort of thing for a living!’ range rather than the ‘I can buy a Ferrari tomorrow!’ range I’m writing it to hopefully provide a data point to other developers who, like me, are still learning about selling their wares online, and are wondering about what kind of affect a sale might have. I don’t know whether it will be exactly the same for you, and there are no doubt a number of variables involved, but this was my experience, and I’ve been very happy with it. Maybe it will help someone else pondering a similar decision…

Since I’m trying to spread this news as far and wide as I can, I might as well say it here too

Since the approval light just went green on the Mac App Store, I’m happy to announce the launch of SourceTree 1.2! In celebration, I’m having a crazy-bonkers 40% off sale just for one week, so get it while it’s hot!

There’s loads of things that are new or improved in this release, but here are the headlines:

• Support for GitHub, Bitbucket and Kiln APIs, so you can see your hosted projects inside SourceTree, clone from them, link them as remotes, and even create new projects if you want.
• Streamlined and polished user interface – I specifically dedicated a lot of extra time in this release on making SourceTree easier on the eyes, and to streamline the layout and workflows better.
• Performance - I thought SourceTree was already pretty fast, but I managed to find quite a few more places to trim the fat, and also parallelised more activities to make things feel more responsive. Everything feels snappier, and complex repositories benefit especially.
• New Sidebar - I had previously resisted the need to emulate iTunes here, but once I had implemented it, I had to admit that I was wrong, and in fact this worked great. Provides lots of shortcuts to navigating and operating on branches, tags and remotes.
• Stashing and Shelving - oft requested, now delivered
• Customise Git and Mercurial – you can now use your system Git / Mercurial instead of SourceTree’s standard versions (which have been updated), and enable additional Mercurial extensions (at your own risk).
• French and Japanese translations – local versions for our friends in far away (and not so far away) places, likely to be more to come in future. Big thanks to tuan_kuranes and mzch for their help with these two!
• And the rest – just lots of little refinements too numerous to list. Examples: copying text from the diff panel, ‘git commit –amend’ support, close branches in Mercurial, switch tracking branches in Git

It’s quite a big update – one user remarked to me that they’d normally expect developers to charge an upgrade fee for something like this, but like all other SourceTree updates this is free to existing customers. I have no plans for any paid upgrades for some time yet, I just want to keep making SourceTree better, and hope that more people come onboard. Maybe it’s my open source background, but I like to keep iterating and continually improving things, based on what I want to do (I’m a daily SourceTree user myself), and on what people tell me they’d like to see. SourceTree 1.2 certainly won’t be the last update by far

When I look back 6 months at SourceTree 1.0, it’s incredible how much better it is as a product now, both visually and functionally. I’ve learned a ton of things while I’ve been developing it, and I continue to learn more all the time, and I can’t think of anything I’d rather be doing right now. Also, my wife Marie re-designed many of the icons for 1.2 (and I think you’ll agree they’re a lot nicer) – that was fun to do as a joint project, even if I am a picky ‘customer’

I hope you enjoy the new release!

If you make Mac apps, you probably use Sparkle to manage your auto-update process, outside the Mac App Store anyway. And so you should, it’s awesome, and makes keeping software up to date much easier. But what about the download link on your website for new users? Wouldn’t it be nice not to have to manually update that every time?

For SourceTree, I use a PHP script which just parses my Sparkle appcast and reads the latest release from there, generating a download link automatically. So whenever I update the Sparkle appcast (and I have scripts to do this from XCode, which I may share in a subsequent post if there’s interest), the download link for new users is always up to date immediately.

The full code is after the jump if you want it. As usual, feel free to use this for whatever you want, but there are no warranties for anything whatsoever; don’t blame me if it doesn’t work, or dissolves your website into a pool of steaming alien slime.

<?php

// We're looking for the latest link link this:
// 			<pubDate>Thu, 14 Oct 2010 10:34:03 +0100</pubDate>
//			<enclosure url="http://downloads.whatever.com/MyDownload.dmg" sparkle:version="1.0.0.5"

class AppCastXMLParser
{
   var $tag_name;
   var $tag_data;
   var $tag_prev_name;
   var $tag_parent_name;
   var $latest_date;
   var $use_next_url;
   var $download_url;
   function AppCastXMLParser ()
   {
	   $tag_name = NULL;
	   $tag_data = array ();
	   $tag_prev_name = NULL;
	   $tag_parent_name = NULL;

	   $latest_date = NULL;
	   $use_next_url = true;
	   $download_url = NULL;
   }
   function startElement ($parser, $name, $attrs)
   {
	  if ($this->tag_name != NULL)
	  {
		 $this->tag_parent_name = $this->tag_name;
	  }
	  $this->tag_name = $name;

	  if ($name == "enclosure" && $this->use_next_url)
	  {
	  	$this->download_url = $attrs['url'];
	  	$this->use_next_url = false;
	  }

   }
   function endElement ($parser, $name)
   {
	  if ($this->tag_name == NULL)
	  {
		 $this->tag_parent_name = NULL;
	  }
	  $this->tag_name = NULL;
	  $this->tag_prev_name = NULL;
   }
   function characterData ($parser, $data)
   {
	  if ($this->tag_name == $this->tag_prev_name)
	  {
		 $data = $this->tag_data[$this->tag_name] . $data;
	  }
	  $this->tag_data[$this->tag_name] = $data;
	  if ($this->tag_parent_name != NULL)
	  {
		 $this->tag_data[$this->tag_parent_name . "." . $this->tag_name] = $data;
	  }
	  $this->tag_prev_name = $this->tag_name;

	  if ($this->tag_name == "pubDate")
	  {
		if ($thisdate = strtotime($this->tag_data[$this->tag_name]))
		{
			if ($this->latest_date == NULL || $this->latest_date < $thisdate)
			{
				$this->use_next_url = true;
				$this->latest_date = $thisdate;
			}
		}
	  }

   }
   function parse ($data)
   {
	  $xml_parser = xml_parser_create ();
	  xml_set_object ($xml_parser, $this);
	  xml_parser_set_option ($xml_parser, XML_OPTION_CASE_FOLDING, false);
	  xml_set_element_handler ($xml_parser, "startElement", "endElement");
	  xml_set_character_data_handler ($xml_parser, "characterData");
	  $success = xml_parse ($xml_parser, $data, true);
	  if (!$success)
	  {
		  $this->tag_data['error'] =  sprintf ("XML error: %s at line %d", xml_error_string(xml_get_error_code ($xml_parser)), xml_get_current_line_number ($xml_parser));
	  }
	  xml_parser_free ($xml_parser);
	  return ($success);
   }
   function getElement ($tag)
   {
	  return ($this->tag_data[$tag]);
   }
}

function getLatestDownloadURL()
{

	$appcastparser = new AppCastXMLParser ();

	$appcast = $contents=file_get_contents("http://www.myapp.com/path/to/SparkleAppcast.xml");

	if ($appcastparser->parse ($appcast))
	{
		return $appcastparser->download_url;
	}
	else
	{
		return NULL;
	}
}

$url = getLatestDownloadURL();

if ($url)
{
	echo "<p>Thank you for downloading MyRandomApp, your download should start automatically.</p>";
	echo "<p>If your download doesn't start within 5 seconds, you can use this <a href=\"$url\">direct link</a>.</p>\n";

	echo <<<EXCERPT
	<script type="text/javascript">
	<!--
	function godownload()
	{
		window.location = "$url"
	}
	setTimeout("godownload()", 2000)
	//-->
	</script>
EXCERPT;

}

?>

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?

What isn’t covered very well in the docs though is how you might automate all this so that it’s efficient, incremental, and idiot-proof. And by idiot, I mean me after more than 7 days since reading the docs.

There are tools out there that purport to make this easier, such as AppleGlot and iLocalize, but to be honest I found they just made things more complicated. All I really wanted was an efficient way to batch export and import localised strings, to know what changed between versions, and to keep my previously localised strings automatically without overwriting them. Translators should need nothing more than a Unicode-capable text editor – no complex tools, no training, just their natural ability to turn English into a different language and type it into a text file.

I ended up with two Python scripts to handle this – one to handle the genstrings/NSLocalizedString route, which I wrote a while back and covered in a previous blog post. The second I wrote today to handle nibs, and also to build the individual language folders. I needed it to do this:

1. Export strings from nibs for each language, merge with strings already translated, or
2. Import strings for each language and create localised nibs based on the master English versions

Here’s my Python script to do this: localise_nibs.py

Usage:
  localize_nibs.py --basedir=<base> --stringsdir=<strdir>
    [--langdir=<langdir>] export|import

  export: Reads all the xib files in <base> and generates .strings files
        for every 2-char country code directory under <strdir>
        New strings will be added to existing files.
  import: Reads all the xib files in <base> and looks for .strings files
        in <strdir>/<lang> with the same name. Replaces strings in xib and
        writes the output to <langdir>/<lang>.lproj

So basically, you start with a base folder full of nib files (in English in my case), and point –stringsdir at a folder which contains (empty to begin with) subfolders corresponding to languages (like ‘fr’, ‘de’, ‘ja’ etc). When using the ‘export’ option, it will go through all your .xib files and generate strings from them using ibtool, once for each language. It will also turn these files into UTF-8 rather than UTF-16 (as ibtool exports them), so that you can put the files in hg/git without losing text diff support. You can give all these files to your translators.

The nice thing is that if you add a new control to your user interface, and you’ve already got translations in the –stringsdir folder, the script will merge the output from ibtool and the existing translation, only adding the new strings. You can then simply give the files to your translator with a ‘diff’ report (this is why you want UTF-8) to show them what they need to look at. The Apple localisation docs talk about ‘incremental’ localisation, but they totally miss this part – by ‘incremental’ they just mean taking a localised nib that you’ve manually changed and merging geometry settings, not generating a new strings file which doesn’t lose the previous translation.

The ‘import’ option does the reverse, it takes the translated strings and the base nibs, and creates localised nibs in the –langdir folder. Mostly the script just automates everything so it finds the files on its own, processes all languages, and highlights when there’s a missing translation (and uses the base version temporarily so the app still works). Note that I assume that you only manually author one nib (the base version) – personally I don’t have the resources to tweak geometry in every language so if you do, you’ll need to alter the script to cope with the ‘incremental’ localisation as Apple presents it in the docs.

Anyway, I just thought I’d post this in case it helps someone else – I experimented with a few different options and I found this one to be the best – it’s simple, uses tools you already have, and plays nice with source control. Result?

Yes, I really didn’t use any source control back in 1994, barring backing up to 3.5″ floppies. ‘Custom’ refers to a system I wrote myself in 1995 to do version control on a mainframe system I was working on at the time; really it wasn’t a proper VCS system as you would think of it now, but it did the very basics to make sure we knew what was being developed and deployed at any point in time. You could think of it as a VCS system that only had history at the tags

As you can also see, Visual SourceSafe was the first packaged system I used – you can pity me now – as more of my work started to involve PCs instead of ‘big iron’. At that stage, the concept of ‘checking out’ and ‘checking in’ was normal. Oh, how naïve we were.

I discovered CVS at the turn of the millennium, at the same time I started Ogre. The ability to work without checking anything out was a revelation! I went on to use that on all my projects for quite a few years, at least until I considered Subversion stable enough to base production work on. Even then, I only moved new projects to Subversion mostly (Ogre eventually moved in 2008 – was it really that recent?), and kept CVS for many existing projects.

I first encountered Distributed Version Control at a Git presentation at the Summer of Code mentor summit at Google HQ in late 2007. I have to admit, I didn’t really ‘get it’ at first – it just seemed to make things more complicated and most of those promoting it were mostly die-hard Linux fans and wide-eyed early adopters that didn’t make you want to put your production code on it yet. There was also no GitHub at this time so the benefits weren’t really very visible. It took me until 2009 to really start evaluating DVCS in earnest, and decided that I liked Mercurial best, due to its equal treatment of all platforms, good diagnostic reporting, easy extensibility and intuitive interface that gave power without over-complexity. Today, all my own projects are in Mercurial, but I use Git a lot too, not least because I support it in SourceTree, and get involved in other projects which use Git.

There are a couple of randoms thrown in there – I used Alienbrain for a few months on a client project and totally hated it (think Visual SourceSafe with a few bells – it may be useful for artists but for coders it was horrid), and I did play with Bazaar for a bit but didn’t really warm to it, even though it had some quite nice ideas.

So there you are – my VCS experience over ~17 years in professional development. It kinda makes me want to do a language / platform graph now

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