Category Archives: Development

Development Tech Windows

Friends don’t let friends use ClickOnce

I’ve had a fair amount of experience with Windows-based installers in the past, including non-Microsoft Installer based systems like NSIS and the open source WiX, but most of the time I’d been working with one-off installers for native code projects, like the Ogre3D SDKs. I pride myself in not pre-judging the best toolset to use for any given problem – which is why I switch languages a lot – so when I came to write SourceTree for Windows, which is based on .Net, I checked out the landscape again.

I discovered that ClickOnce was Microsoft’s recommended approach to .Net application deployment , and had the advantage of including both the installer tech and an auto-update system, together with Visual Studio integration, a simple deployment model and so on. I’d seen it used on a couple of other products, and during testing both internally and with our batch of beta testers all seemed to be well, so that’s what we went with for the release.

Hindsight is a wonderful thing, and it turns out that ClickOnce has a number of problems which only really show up when you use it at scale, by which time it’s a bit too late and you can find yourself with a lot of support requests. Here are some of the issues:

  1. No support for proxy servers
    It turns out that ClickOnce just doesn’t work at all with secure proxy servers which can’t authenticate automatically. It also turns out that a lot of people have this kind of setup. There’s a (nasty) workaround for the auto-update system, but this can’t work for the first install. Microsoft have known about this problem for some years, but have decided not to bother fixing it.
  2. Packaging format is just a folder of many files
    ClickOnce puts all of its files in a folder per version and just tacks ‘.deploy’ onto the end of each. Simple, but it has many problems:

    • Some corporate firewalls will detect that some of those files are executable binaries, and will flag them as dangerous. Some will totally block the file making the install/update fail with a download error, some will ‘sanitise’ the file and send that on, making the install fail later with an ambiguous hash mismatch error.
    • If you use a CDN to distribute your installers, distribution of many files is very difficult to make atomic, potentially leading to temporarily incomplete results being visible
    • Having the download (first install and update) as a multi-file affair makes failures due to interrupted connections etc much more problematic, vs just resuming the download of a single package.
  3. You can’t separate the update metadata from the update itself
    That is to say, ClickOnce forces you to use a single URL for both the metadata where it finds that there is an update, and where it gets the actual update from (the installation files are in a subfolder). This might seem sensible, but in practice it’s very limiting. If they’re separate, you can point the metadata URL at a location which you can update in-place and which will never change, and you can put the update files themselves wherever you like (a CDN usually). ClickOnce forces you to put both in the same URL, which is limiting when it comes to reorganisation, and also it can mean you have to put the metadata on the CDN too, and CDNs don’t often like files that update in-place. It’s just an awkward and inflexible system.
  4. Random weird sh*t in a small percentage of cases
    We’ve found over the last couple of months that occasionally a user’s machine refuses to install or update despite the ClickOnce installer being fine for everyone else, and in circumstances that were not explainable by the other issues listed above. It’s not that common, but even if it’s only 0.5% of cases the numbers were starting to add up. We often managed to work around the problems manually, but it’s just not something you want to spend your or your customer’s time on.
  5. Other niggling limitations customers don’t like
    None of these are deal-breakers in their own right, but combined with everything else they’re worth mentioning:

    • You can’t choose where to install the product – ClickOnce chooses an esoteric location for you
    • ClickOnce’s reliance on the logged in user means you can’t install once for everyone on a PC, or distribute a bulk install as admin
    • No offline installer – while you can zip up the deployment it didn’t work for everyone

So, all these things have been building up , tempered with workarounds but nevertheless a constant thorn in our side. In the end, we had to make the call that ClickOnce just wasn’t salvageable as a deployment tech to use at scale. Instead we’ve moved to a standard Microsoft Installer based tech stack, using Advanced Installer to build the installer and the update system. I really liked Advanced Installer because not only does it address all the issues above, it saved me a ton of time over building something myself with WiX (and having to solve the prerequisites bootstrapper and auto-update system), and was also just complex enough to do what I needed; it’s a pro tool but doesn’t require 3 months training to master it, you can pick it all up in a few days.

I wrote this blog post because it’s what I wish I’d been able to read before I decided to use ClickOnce. It’s one of those technologies that looks fine on the surface and in limited testing but then reveals a bunch of horrid edge cases and random unreliability issues  in the wild, just when you don’t need it.

Business Development Productivity

What open source taught me about management

I was a manager of developers in an organisation for a few years, and during that period I learned a lot. But if I’m honest, I learned far more about being a manager from leading a large open source project for 10 years, because that taught me a lot about what makes developers tick. Of course, I’ve always been a developer myself too, but you often don’t think that clearly about your own motivations.

Open source developers are usually volunteers. They choose to spend their own time contributing to your project – maybe they do it as part of paid work or their own projects too, but even then it takes extra effort to contribute back in a meaningful way, since the quickest and hackiest option usually isn’t the one that will be accepted upstream. These guys are going out of their way to help, even though no-one is cutting them a check in return. Crazy? And not only that, they usually defer to project leaders or core team members, changing their contributions or beefing them up based on their suggestions even though they don’t have to. Curious?

‘Meritocracy’ is a word that’s bandied around a lot, but in open source it’s an accurate description; people only listen to your opinion, or accept your direction, because they want to, and trust you enough to respect your decisions. This is a two-way street; the leader essentially builds this trust not only through leading by example, but also by accepting feedback from others, even when it’s conflicting with their own current stance, with good grace and consideration.

Because there’s no strict ‘hiring’ process as such (it’s more of an ‘onion skin’ sort of approach where developers are given increasingly more power as they soak into the community and contribute more), and geographical locations are irrelevant, you often end up with quite rag-tag band of people in an open source project, each with their own strengths and opinions, arguably a more diverse bunch than you’d find inside a single company. This mixture of experiences, ages, cultures and languages can be a challenge sometimes, but it also brings things to the table that could really only occur when you throw this sort of melting pot together. I learned a vast amount about dealing with people just by being exposed to that variety over the years.

But most of all, I learned that motivating smart, creative people can be done entirely for free – you just have to have the right attitude.

A lot of managers seem to believe that carrot and stick techniques coupled with metrics and monitoring are the best way to ensure employee productivity. You can encourage people with salary and benefits, make sure they work hard by applying metrics on time and task completion, have disciplinary proceedings when those goals aren’t met, and so on. You have none of those in open source, and yet great work gets done anyway – by some metrics, projects can be equivalent of millions of dollars of investment. Why does this work?

Well, as it happens, what pushes the buttons of creative people like developers most of all is the work itself, and the experience of doing it. Sure, we all need money; we need to live somewhere, eat, buy expensive shiny gadgets and so on, but actually, the good developers would be (and indeed are) writing software regardless of whether someone paid them to do it. For most good developers, what really matters once they’re comfortable with their financial situation is:

  1. To work on projects they care about
  2. To learn new and interesting things
  3. To have creative control/influence over their work
  4. To be treated like adults and not micromanaged
  5. To be recognised for their work

Open source projects put a big tick in all of these boxes, and that’s why they can be so successful despite there often being no money involved. As a manager, if you concentrate on these 5 things, you’ll increase your chances of attracting good developers – the salary and benefits have to be reasonable too of course, but those 5 will tip the balance.

Of course, rather than ramble on like this I could have just pointed to Maslow’s Hierarchy of Needs; all managers are familiar with that and use it to guide their management style, right? Right?

Development Random

Software industry archetypes : nautical edition

For no particular reason except that a few of these occurred to me while relaxing this week on our ample coastline…

The free diver
Plumbs dangerous depths with little or no assistance or safety gear, far from the glow of natural light.
Examples: Kernel programmers, graphics programmers

The jet skier
Skims along the surface covering a lot of ground: agile but also capricious, never staying too long. Try not to get caught in their wake.
Examples: hipster coders, social startups, people who think Node.js is old-skool

The angler
Happy to sit comfortably in the good local fishing spots, with traditional bait, content in the knowledge that plenty of fish will be passing and enough will bite.
Examples: business application specialists

The whaler
Travel the high seas looking for the largest prey, bringing it down with expensive specialist equipment.
High-end consulting firms tendering for massive projects, government/military

The Eco-warriors
Fighting the good fight for the betterment of the world (as they see it).
Examples: die-hard GPL advocates

Got any others? :)

Books C++ Development OGRE Open Source Windows

Review: OGRE 3D 1.7 Application Development Cookbook

It’s always gratifying, and a little weird, when I see books being written about OGRE – it just serves to illustrate (if any more evidence was needed) how far the project has come since I created that first ‘vertex coloured triangle’ rendering test on my home computer 12 years ago. I’ve been retired from the project for a while now, but I still get asked my opinion about things sometimes, and Packt were nice enough to send me a copy of this new book by Ilya Grinblat and Alex Peterson, OGRE 3D 1.7 Application Development Cookbook, to see what I thought.

Firstly, don’t worry about the version number in the title, it’s really just a minimum version. All the information in this book is equally relevant to the recently released OGRE 1.8.

This book focusses very much on practical exercises, which I really like as a learning style. I often end up learning new languages and APIs, and I always prefer to bootstrap using books that teach by example in the first instance, and this one does that very well. The steps are well laid out with regular full-colour screenshots (at least, in the electronic version I have).

Also, the book tackles a number of areas that haven’t been covered before in other books. While it still deals with all the basics too, it covers new areas like creating GUI tools with OGRE viewports and how you’d deal with selection, orbit cameras, and linking visual properties to controls. It also covers creating plugins, procedural mesh content, custom resources, and more advanced elements of animation that I haven’t really seen discussed elsewhere. So the book covers a lot of ground – there’s a limit to how much detail they can cover in each area, but it’s easily enough to expose you to the core techniques so you can expand from that on your own (indeed the “There’s more” sections throughout the book hint at where you might want to explore next).

So on the whole I thought this was a very useful book. There’s one important caveat that I’d add:  it’s very, very Windows-focussed. If you’re developing with OGRE for any other platform (Mac, Linux, iOS, Android etc) then the step-by-step nature of the instructions won’t be as useful to you, and several parts of the book won’t be any use at all without heavy conversion on the part of the reader. The first few chapters aren’t relevant at all to non-Windows users, and there’s a few others where the practical example is dependent on a Windows-specific technology such as the Microsoft Speech SDK or the AVI toolkit. All the GUI-related parts of the book use MFC, which again is entirely Windows-specific; and personally, I’ve had a strong dislike for MFC pretty much since I first encountered it 20 years ago. I think Qt or wxWidgets would have been far better choices for these sections.

So, if you’re a Windows developer and are happy with using MFC (even if just to learn), I can recommend this book wholeheartedly as both a practical, hands-on OGRE tutorial and an exploration of some interesting lesser-visited areas. If you’re on another platform or like me don’t like MFC, I still think there’s plenty of useful information here, but you’ll have to be prepared to put some extra work in to convert some of it, and/or be content to skip some of the chapters that won’t apply to you, so bear that in mind when making your decision.

Thanks to Packt for giving me a copy of this book to review, and congrats to the authors on the release.

Development Health Personal Tech

104 keys: who needs them anyway?

I fired up my desktop Windows PC for the first time in a while recently, and the first thing I realised is that I absolutely hated the keyboard. This was nothing to do with the slight differences between the PC and Mac keyboard layouts, the latter of which I’ve become more accustomed over the last couple of years, nor was it about whether the keys were mechanical or scissor switched, or any such nuance.

No, it was solely this: the damn thing sticks out way too far on the right hand side if you’re a right-handed mouse user.

Like most heavy computer users, I’ve had various bouts of RSI over the years. The most basic case was resolved by learning to touch-type rather than the spider-typing that actually most programming languages encourage you to self-teach if you don’t know any better, given that all the useful symbols are around the edge of the keyboard. Later on, I found that low-profile keyboards with low travel distances & pressure resistance reduced general fatigue-related issues I started to get with age. But there was one issue which never went away – aches caused by mouse use. The main issue for me was not the mouse itself, but that because of the asymmetrical nature of the standard PC keyboard, with the cursor / navigation block and numpad sticking out to the right, your mouse has to be placed quite far out to the right, meaning that when using the mouse your body is skewed out of symmetry, meaning you’re straining one side of your body more than the other. This gives me shoulder & back ache, and also the angle means the unnatural wrist rotation of most mice is even more exaggerated, causing issues there too. I try to use keyboard shortcuts as much as possible, but you can’t avoid reaching for the mouse sometimes.

Now, I’ve been using a MacBook Pro pretty much exclusively for the past 2 and a bit years, and all those aches have gone away, because the trackpad is right there in the centre and everything remains aligned. I love the Mac laptop trackpads – they’re large, expressive, multi-touch, ergonomic and just a joy to use, to the extent that I can’t use any other trackpad without being struck by how awful they feel. I’ve tried a few on Windows laptops over the last few years and my response is always really negative. And this is a desktop in any case, they’re quite hard to find outside laptops even if I wanted one. So in practice, a PC-based trackpad wasn’t going to cut it, the mouse really had to stay.

Secondly, since I’ve been using a laptop keyboard for so long, I don’t feel I even need all those separate blocks of keys any more. Sure, I used to use them all the time;  I’d used 102/104 keyboards since 1991 and my muscle memory had got me used to jumping over to the cursor keys, Home/End, and occasionally the number pad. But in the last 2 years, that tendency has been completely eradicated from me – I now reach for the arrow keys in the bottom-right of the keyboard, and use combos like Fn-Left-Arrow rather than needing a dedicated Home key without even thinking about it.

So here I was, with a keyboard that was throwing off my ergonomic balance due to a couple of blocks of keys I didn’t need anymore anyway. I could have just sawn the keyboard in half I suppose, but I looked online and ended up grabbing a surprisingly cheap ‘compact’ keyboard that just gets rid of all that. You can see the difference in the image below:

To me, this feels a lot more natural; the angle of my right arm is far less acute, and that puts less pressure on my shoulder and wrist as well as not requiring me to reach as far when I move back and forth from the keyboard to the mouse.

The keyboard in question is not great quality, (I would have bought this one instead if it wasn’t for the fact that it only came in American layout with the horrible single-row Return key) so I’m going to have to see how that pans out. The range of choices for keyboards like this seems very limited, with a few options like this one at the budget end (probably designed for server rooms methinks), and a few crazy expensive options at the ‘specialist ergonomic’ end, which I wasn’t ready to pay for (I don’t expect to be using this machine all the time). If you know of any others for future reference, please let me know in the comments.

A final thought: over the years I’ve become more aware of how we seem ready to accept working in configurations that are actually quite bad for us physically, due to convention and familiarity. Almost 10 years ago a colleague of mine bought a Fingerworks TouchStream LP, a weird multi-touch surface that acted as both a keyboard and a mouse at once, with gesture support, and which at the time I thought was total insanity (and I found it impossible to use his PC!). In hindsight, I recognise the genius in that product, and can see why Apple bought the company – who of course ended up being at least partly responsible for how good Apple’s touch-based tech feels today.

Cocoa Development Objective C OS X Personal Travel

See you at WWDC!

Apple kept everyone on tenterhooks this year by announcing WWDC 2012 very late – the second latest announcement ever in fact.

Like many other people (11,000 of them I hear, which is alarming given that there are only 5,000 tickets to the event) I signed up to WWDC Alerts,  which sent me an SMS message while I was having lunch, only a few minutes after the tickets went on sale. That I was lucky enough to bag myself a ticket has a lot to do with that – about 90 minutes later, they were all gone – so big thanks to fellow Brits Anthony Herron and Aaron Wardle for running that, completely free of charge too. Legends.

Apple picked a surprising time to announce the tickets, being as it was about 2am Pacific Time. Perfect for people like me in Europe – I’d expected to get the call late at night – but I imagine there are a lot of people on the west coast who are seething about this choice of timing.

I’ve never been to WWDC before, but this year was a perfect time to go, with the continued growth of SourceTree and the fact that I’m attending Atlassian Summit, which is held a couple of weeks before in San Francisco. So I’ll be heading over for Summit, hanging out in the Atlassian SF Office for a week, then heading down to WWDC. A pretty efficient trip :)

So, if you’re going to WWDC, Summit or are in the SF area generally around that time and want to say hi, look me up!

I’m also thinking about getting a short-term pre-paid SIM (preferably with data) for the 3 weeks I’m out there, if you have any suggestions on that front I’d love to hear them.

 

Development Personal

Why I’m a software developer

How often do you stop and think about why it is you do what you do for a living? Maybe it’s a mid-life crisis thing, but of late I’m acutely aware of the finite nature of time, and that there are an infinite number of ways I could spend that time. I’m also aware that ‘software developers’ are a quite diverse bunch of people, despite the persistent stereotype of math geeks huddled around technical toys talking in obscure acronyms (OK, we do that too). So I put some thought into why I choose to spend my time making software.

For me, it’s really simple: I like making things that people enjoy. That’s a pretty broad definition, but creation and connection is absolutely at the core of my motivation. It’s not really about the technical or logical challenges for me; at least, not any more – that might have been more of an issue earlier in my career. There’s something indescribably satisfying about creating something from nothing, sculpting and refining it from an image in your head into a functioning, tangible product. It doesn’t really matter what it is, just that it didn’t exist before, and now it does, purely because of your will. “I made that” is a satisfaction universal to all languages and cultures. That I’m a software developer rather than a sculptor, writer, musician or painter is down to a combination of circumstance and natural tendencies, but I don’t think my motivation is limited to this technical sphere at all. In fact, I think we all have this creative spark, it just gets drummed out of a lot of us after childhood.

I also think that you have to make things that speak to you first and foremost. Obviously you hope they will resonate with others too, and it’s pretty much guaranteed that they will (it’s just the degree that’s variable). I’ve made products entirely for other people before, indeed I spent a large portion of my career doing that, and it’s a bit of a lucky dip whether that turns out to be enjoyable and fulfilling or not. I’m at my happiest when I’m scratching my own itch, eating my own dog food, and building a community of people who feel the same way. It’s where both Ogre and SourceTree came from, which are the pieces of work I’m most proud of, and are also the most successful products I’ve created so far. That can’t be a coincidence, right?

This may sound like woolly, new-age thinking, but what feels right normally is right. I’m convinced that when you spend your time doing things which sync up with who you are as a person, better outcomes are more likely.  Have you thought about why you do what you do lately?

    Cocoa Development Objective C OS X

    Follow-up: OS X privilege escalation without using deprecated methods

    I posted a few months ago about the problems I’d encountered with performing privileged actions from a Mac OS X app – in my case, installing a command line utility in /usr/local/bin – and that all the examples of this that I’d come across used an approach which was now deprecated. You can find my original post here:
    Escalating privileges on Mac OS X securely, and without using deprecated methods.

    I had failed to produce a shrink-wrapped working example to go with the discussion, primarily because extracting it into a standalone example would take a while and I made the post a couple of days before I went on holiday. I also didn’t know whether anyone else actually cared about the subject enough for it to be worth me doing it!

    Well, perhaps I should have known better, because I’ve had quite a few requests for such an example since then :) I finally got around to doing this at the weekend – and actually when I came to do it I understood why people had pestered me for it, because it took me a while to get things configured just right in a fresh project! Mostly, it’s that there are quite a few things that can go wrong outside the code, both in the project settings and the plists because of the code signing requirements.

    So anyway, here’s the project: PrivilegedHelperExample on Bitbucket. Please make sure to check the ReadMe.txt – despite being shrink-wrapped, you will need to add your own code signing identity before you can compile the code, and you will need to reflect the name of your certificate in a few places, which I’ve listed. I’ve also tried to point you at the relevant pain points you may encounter when replicating the result in a different project.

    The majority of this code is just the Apple example code from BetterAuthorizationSample and SMJobBless, grafted together, de-duplicated and tweaked. All the changes I made can be considered public domain.

    Enjoy!

    Cocoa Development Objective C OS X

    Escalating privileges on Mac OS X securely, and without using deprecated methods

    This week I implemented a much-requested feature in SourceTree for the upcoming 1.3 release (beta 1 went out on Monday, this will make it into beta 2) – a command-line tool so you can quickly pull up SourceTree for the repository you’re in from a terminal. Writing the command-line tool was trivial, but when I came to implement the menu item which would install it in /usr/local/bin, which inherently needs privilege escalation, it turned out to be a lot more complicated than I expected.

    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.

    Cocoa Development Objective C Open Source OS X

    SSSelectableToolbar

    A common requirement in any Cocoa application is a preference pane style window where each toolbar item switches to a different view in the main window, resizing as necessary. I’ve used BWToolkit to do this in the past, which provides BWSelectableToolbar. However, there are a few issues with using BWToolkit:

    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.