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.

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!

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?

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

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.

Code Example on BitBucket

Note: The project is written with garbage collection required, that’s because my original project uses that approach (I’m happy to require ObjC 2.0 / Leopard and don’t have a need for low-level memory control in this project) and I didn’t have time to retrofit old-style retain/release patterns to it. If you still use manual memory management in Mac OS X you’ll need to alter the code.

The answer to this problem involved several pieces:

1. We need a tree model to hold our data. I’ve included a pretty standard node implementation in the example (ModelTreeNodeBase), and then subclassed it for the specific example (MyTreeNode)
2. Since we can’t design NSCell in Interface Builder, we need to design an NSView instead – in this case I designed one for the group level, and one for the detail level, but you could do more or less if you wanted. For convenience, I put both in one nib (CustomCells.xib).
3. We need to attach our NSViews as subviews of the outline view, in the appropriate place, at the right time, in order to display them. I do that in our custom NSCell subclass, CustomCell
4. Since there is only one instance of NSCell for all data rows of an outline view, we can’t use that to hold row-specific information, such as binding values to fields. So, I use a controller called CustomCellController which provides the linkage between the cell view and the model node (appropriate MVC practice). I use Cocoa Bindings to pull in data from this controller’s node per row, see the CustomCells.xib setup.
5. Again because there’s only one NSCell instance, we need to associate the specific controller instance for the correct row with the NSCell just before drawing. I do this in the NSOutlineView delegate method outlineView:willDisplayCell: , which you’ll find in the CustomOutlineViewAppDelegate in this case.
6. The association between the model node and the controller is kept in a simple NSDictionary, just to keep the coupling loose. Note that I use the model node itself as a key (which is why we’ve implemented the hash and isEqual methods in the model), in my app this is useful anyway because to identify a node uniquely regardless of content values is required.
7. Because we’re manually attaching our subviews on display, we also need to remove them at the right time. I do this on outlineViewItemDidCollapse: (and in the real app, I also do it when deleting rows and on drag/drop)
8. Outline views allow you to click or press enter to edit the main title text, and I support this here too. I have to do a bit of work though, firstly to make the edit box appear in the right place (see CustomCell’s editWithFrame: and selectWithFrame: methods) based on where we’ve placed the text in our custom view, and also to place the ‘hit box’ in the right place – in my case I’ve allowed the hit box to extend over the entire cell, barring the other controls which take precedence if the mouse hits them. See CustomCell hitTestForEvent: for that code.
9. I also do a little bit of presentation nicety by changing the colour of the text when the row is selected. You get this for free with NSOutlineView normally, but since we’re using custom views, you don’t automatically get inverse video on text, so we have to do that ourselves.
10. To make the cells resize correctly, you use Interface Builder’s sizing options as per usual. However, it’s very important that the size values in the NSOutlineView’s table column, the size of the scroll view containing it, and the initial size of the custom NSViews for the cells are set to the same values in the various nibs. If you get this wrong, resizing won’t work correctly. As you can see from the example, if you set it up right you can get all the usual content resizing options for free while designing your cells in Interface Builder.

Basically, that’s it – hopefully you can see the details from the code with those pointers. You’ll notice that although I used Cocoa Bindings to link the cell values to the model, I used the NSOutlineViewDataSource protocol for the main outline view structure, instead of binding it via a tree controller. The only reason for that was that the example from my project does it this way, because you need to use a custom datasource to handle drag/drop and the pasteboard, so it was simpler this way. There’s no reason why this wouldn’t work with a tree controller providing the data too, since all the key moving parts are in the delegate, custom cell and controllers.

Forgive me for any errors or bad practice here, I’m still relatively new to ObjC / Cocoa. But still, I hadn’t seen this done anywhere before so I wanted to share the technique I used, because when I was trying to do it I really wished someone had posted an example like this before. This code works well for me, but suggestions, patches & forks on BitBucket are of course welcome if you see something I’ve done wrong or sub-optimally.

I hope this is useful to someone!

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.

There are a couple of practical issues though. Firstly, genstrings always overwrites its output file, which means that using it incrementally to add new strings when you’ve already populated the previous set – which is bound to be the normal case for most developers – isn’t possible out of the box. Luckily I found a nice little Python script which solves this problem for you by merging the results in to your existing files. I’ve added a custom target with a Run Script step to my XCode project which uses a modified version of this script (see below) to update my strings files whenever I need to.

The second problem is that genstrings creates UTF-16 encoded files, and there’s no way to alter this. The problem with UTF-16 is that both Mercurial and Git don’t like them very much; both system’s text/binary detection will classify them as binary, meaning you lose the ability to diff and merge these files in any useful way. It’s not a deal-breaker, but it’s inconvenient. Couple that with the fact that OS X will quite happily use UTF-8 encoded .strings files directly at run-time (although iPhone will not), and it seemed something that I should resolve. For the convenience of development, I modified the Python script (as shown below) to convert the result of genstrings to UTF-8 via iconv, meaning they always get picked up as text in source control. If you’re deploying on iPhone, it’s trivial to write a small build script calling iconv again to convert back to UTF-16 for deployment.

#!/usr/bin/env python
# -*- coding: utf-8 -*-

# Localize.py - Incremental localization on XCode projects
# João Moreno 2009
# http://joaomoreno.com/

# Modified by Steve Streeting 2010 http://www.stevestreeting.com
# Changes
# - Use .strings files encoded as UTF-8
#   This is useful because Mercurial and Git treat UTF-16 as binary and can't
#   diff/merge them. For use on iPhone you can run an iconv script during build to
#   convert back to UTF-16 (Mac OS X will happily use UTF-8 .strings files).
# - Clean up .old and .new files once we're done

from sys import argv
from codecs import open
from re import compile
from copy import copy
import os

re_translation = compile(r'^"(.+)" = "(.+)";$')
re_comment_single = compile(r'^/\*.*\*/$')
re_comment_start = compile(r'^/\*.*$')
re_comment_end = compile(r'^.*\*/$')

class LocalizedString():
    def __init__(self, comments, translation):
        self.comments, self.translation = comments, translation
        self.key, self.value = re_translation.match(self.translation).groups()

    def __unicode__(self):
        return u'%s%s\n' % (u''.join(self.comments), self.translation)

class LocalizedFile():
    def __init__(self, fname=None, auto_read=False):
        self.fname = fname
        self.strings = []
        self.strings_d = {}

        if auto_read:
            self.read_from_file(fname)

    def read_from_file(self, fname=None):
        fname = self.fname if fname == None else fname
        try:
            f = open(fname, encoding='utf_8', mode='r')
        except:
            print 'File %s does not exist.' % fname
            exit(-1)

        line = f.readline()
        while line:
            comments = [line]

            if not re_comment_single.match(line):
                while line and not re_comment_end.match(line):
                    line = f.readline()
                    comments.append(line)

            line = f.readline()
            if line and re_translation.match(line):
                translation = line
            else:
                raise Exception('invalid file')

            line = f.readline()
            while line and line == u'\n':
                line = f.readline()

            string = LocalizedString(comments, translation)
            self.strings.append(string)
            self.strings_d[string.key] = string

        f.close()

    def save_to_file(self, fname=None):
        fname = self.fname if fname == None else fname
        try:
            f = open(fname, encoding='utf_8', mode='w')
        except:
            print 'Couldn\'t open file %s.' % fname
            exit(-1)

        for string in self.strings:
            f.write(string.__unicode__())

        f.close()

    def merge_with(self, new):
        merged = LocalizedFile()

        for string in new.strings:
            if self.strings_d.has_key(string.key):
                new_string = copy(self.strings_d[string.key])
                new_string.comments = string.comments
                string = new_string

            merged.strings.append(string)
            merged.strings_d[string.key] = string

        return merged

def merge(merged_fname, old_fname, new_fname):
    try:
        old = LocalizedFile(old_fname, auto_read=True)
        new = LocalizedFile(new_fname, auto_read=True)
        merged = old.merge_with(new)
        merged.save_to_file(merged_fname)
    except:
        print 'Error: input files have invalid format.'

STRINGS_FILE = 'Localizable.strings'

def localize(path):
    languages = [name for name in os.listdir(path) if name.endswith('.lproj') and os.path.isdir(name)]

    for language in languages:
        original = merged = language + os.path.sep + STRINGS_FILE
        old = original + '.old'
        new = original + '.new'

        if os.path.isfile(original):
            os.rename(original, old)
            os.system('genstrings -q -o "%s" `find . -name "*.m"`' % language)
            os.system('iconv -f UTF-16 -t UTF-8 "%s" > "%s"' % (original, new))
            merge(merged, old, new)
        else:
            os.system('genstrings -q -o "%s" `find . -name "*.m"`' % language)
            os.rename(original, old)
            os.system('iconv -f UTF-16 -t UTF-8 "%s" > "%s"' % (old, original))

        if os.path.isfile(old):
        	os.remove(old)
        if os.path.isfile(new):
        	os.remove(new)

if __name__ == '__main__':
    localize(os.getcwd())

Hopefully this is useful to someone else! I’m still very much learning on the Mac development side, so if there’s something I haven’t considered, please let me know.

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?

I have Vista installed as a secondary boot on my 2007 MacBook Pro, something I’ve come to regret as it’s regularly far more hassle than XP would have been. In practice, I’ve found that I hardly use it, with weeks passing without me bothering to boot up Vista (which makes it worse, because when I do boot it up its intrusive and wholly unstoppable update process starts kicking in in the background, making me grind my teeth at the CPU / RAM loss). Nevertheless, it’s useful at times.

I’ve dallied with virtualisation occasionally, from Parallels to VMWare to VirtualBox, but have been generally disappointed – my day-to-day work and most of my recreation involves 3D acceleration in one form or another, and virtualisation has historically been pretty bad at supporting it, making it an impractical option. VMWare Fusion 3, however, claims support for Shader Model 3, which is good enough for the vast majority of the work that I do (Dx10+ is still a tiny, tiny niche that is still rarely in demand), so I thought I’d give it a shot.

One of the nice things about Fusion 3 is that it lets you boot your existing Boot Camp partitions in a VM, which meant I could test it quickly. Parallels supported this too but I found it didn’t work that well in practice when I tried it. Fusion 3′s support is excellent – just a few minutes of adaptation and the requisite install of VMWare Tools on the Windows partition and it was up and running. The main problem I initially encountered is that the default 1GB memory allocation is, of course, absolutely no use for running the sweating hunk of lard that is Vista. This is the OS that is capable of getting up to 1.2GB on my machine after first boot with only Explorer open, if you’re unlucky enough that it feels it needs to run update processes in the background. I only (only??) have 2GB on my laptop so I had limits, but a quick tweak of the VM to 1.6GB (and also letting it use multiple CPUs) made it run OK and still let me jump back to OS X, albeit a bit slower than usual (but show me a post-millennium Windows OS that can stay usable on 400MB!).

For general non-specialist use, Fusion 3 is as awesome as other virtualisation tools. Either in a window, full screen, or in ‘Unity’ mode, where Windows apps look like first-party OS X windows in your task list (a bizarre feeling to have Explorer and Visual Studio show up in Exposé), it works great. They even fix the track pad issues, it works much better than in Boot Camp natively. I’d definitely want to upgrade the RAM on my machine if I did this regularly, but it’s certainly solid. But, for me, it’s all about the 3D, so let’s get to that.

I ran through a few GPU tests, after having to wait an hour or so for Vista to go through its background update processes so that it stopped sucking CPU and RAM, distorting my performance sampling (grr), and sure enough all the OGRE demos ran ok. They did, however, run pretty slowly; simple fixed-function demos that usually run at 2000fps on this machine ran at about 300fps, and moderately complex SM2 demos usually pegged at 250fps here ran at about 40fps. Highly complex SM3 demos (e.g. OgreSpeedTree) were unfortunately almost unusable. So, you can expect a pretty steep performance penalty of at least a factor of 6 times running virtualised 3D in my experience. Clearly, at this performance degradation, this would be no good for me as a sole Windows option on this machine. But, it still is valuable, since it’s using the Boot Camp partition, I can use this to quickly test things for compile & run-time behaviour, albeit at unrealistic performance levels, and reboot ‘properly’ into Windows for the times where I want to performance test or demo something.

That is, I would be able to if it wasn’t for Windows Activation. As we all know, this is Microsoft’s anti-piracy strategy and involves requiring you to re-activate your copy of Windows within 3 days if a ‘significant’ hardware change is detected. Since a VM basically emulates all of the core system processes, inevitably Windows sees that as a ‘significant’ change and requires you to reactivate. You can do this online, but only 5 times, after which you have to phone someone every time you want to do it. If I used my Boot Camp partition in both modes, as is useful to me, I’d have to reactivate way too often.

There are some threads and articles about this issue on the VMWare site; they claim that provided you follow this article, then the Windows activation monster will be sated and leave you alone when switching between Boot Camp and Fusion 3. No such luck for me, I’ve rebooted many times between Boot Camp and VMWare and have had the VMWare Tools installed since the first boot, and all I continuously get is an activated product when I use Boot Camp, and a ’2 days to activation expiry’ message in VMWare. I’m not the only one: people are reporting this issue in the forums, including with Windows 7.

If they can’t get the activation issue fixed, so that I can choose to use Boot Camp and VMWare interchangeably, this effectively kills the product stone dead for me, as with every other virtualisation product before it. Which is a shame, because apart from this,  it works great. It’s Windows fault of course, rather than VMWare’s, but regardless the effect is the same. This is a perfect example of bad, customer-unfriendly DRM – it’s especially galling to have MS accuse me of stealing when in fact I’ve paid through the nose for many, many copies of Windows before, and am set to do so again with their expensive Windows 7 (Pro+) pricing – where they still seem to stick to this ridiculous principle. Another option would be to free up a spare Windows license from my collection and have separate Boot Camp and VMWare partitions, but I’d really prefer not to burn the time & disk space on maintaining two installs.

Fix the activation issue and I’ll be buying a copy of this plus a 4GB RAM upgrade immediately. Until then, it’s another nice product that’s scuppered by one small, but nevertheless major issue.

Edit: Ok, I’ve resolved this issue. Actually the original KB article on the VMWare site was correct, I just didn’t follow it correctly. In my defence, the key to success is in the small print at the bottom of the article rather than the ordered steps: you have to make sure that you’ve booted once into Boot Camp with the VMWare Tools installed, then afterwards to start the VM under OS X and reactivate Windows. Having done this, both my hosted VM and Boot Camp configuration show up as ‘activated’, which is precisely what I need.

So, now to buy a copy of this puppy and get 2 new sticks of RAM to shove in the laptop.

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.