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.
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.
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: 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.
These days I’m a free agent, and I’m lucky enough to be able to choose what projects I work on, but in a past life, I was what I suppose is properly referred to as an ‘enterprise software developer’. Yes, I once functioned in an environment where terms like ‘mission-critical’, ‘project life-cycle’, ‘stakeholders’ and ‘change management’ came up quite a lot. I’m grateful for the experience I gained over 12 years of doing that, but I’m also very glad to be free of it now.
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.
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:
This is just a quick post to help someone out on Twitter, and the blog seemed the best place to post it.
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.
As many of you probably know, almost a year ago now I decided to take the plunge and move my primary development activities to the Mac. I taught myself Objective-C, got properly to grips with Cocoa at last, and started a new Mac OS X-specific project which would eventually become SourceTree, learning a ton along the way (a process which is by no means complete!). Happily, things have turned out very well - SourceTree continues to sell, reassuring me that there’s enough interest out there for me to keep expanding and improving it (I’m looking forward to getting the next major release in people’s hands soon), and I’ve also been getting some Mac/Ogre-based contract work which I’ve enjoyed a great deal.
Cocoa is already quite good at handling localisation - you have a folder per language where all your resources are loaded from, and you get tools for exporting your strings from your code (genstrings which exports NSLocalizedString macros) and from your user interface components (ibtool which can process nib files to export & import strings). 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.
I was thinking the other day about how many version control systems I’ve made my way through over the years of being a professional developer, and I figured it would be fun to put it in graph form. Of course, this is entirely from memory and gives the illusion of being more empirical than it actually is, but hey, everyone loves graphs, right? Yes, I really didn’t use any source control back in 1994, barring backing up to 3.