M Cubed Blog

Xcode 3.2: teh awesome edition

2009-08-30T11:43:57Z

Xcode is the primary development tool for any Mac or iPhone developer and is where we spend much of our time. As such new versions that bring new goodies are like Christmas for many developers. The fact that the version number has gone from 3.1 to 3.2 is deceptive to the huge amount of improvements that have been added.

Clang LLVM 1.0

For a lot of developers, a compiler isn't really much to get excited over. It takes your code, checks it, optimises it and converts it to something the computer can read. Usually any updates to the compiler just improve compile times a bit, optimise your code a bit more, fix some bugs or add a few more options.

However, LLVM has got a lot of people excited. It debuted in 10.5 with the LLVM GCC 4.2 compiler. This used LLVM for the optimising and converting to machine code (the back end) and GCC for the checking the code (the front end). New in Snow Leopard is the Clang front end.

But just being new isn't cause for celebration unless it does something worthwhile to use it over the older, more mature compiler. Thankfully it does, and it does it in huge strides rather than small increments. Clang LLVM 1.0 is possibly the biggest improvement to any tool in a Mac or iPhone developer's toolset since OS X was first created.

First off, it is FAST. Take your current GCC compile times and reduce the time by about 40-50%. This is a crazy speed improvement for something that is doing essentially the same job.

Secondly, it makes your code faster. It adds a new optimisation level that performs link-time optimisation. This allows it to do many more cross file optimisations. Anything that can make your app run faster without having to change any code is very welcome.

And lastly, it produces sane and actually useful error messages. For a long time we have had to put up with GCCs rather cryptic error messages. It would tell us there is an invalid binary operation with a + sign on a certain line, but if there are multiple + signs on that line then it is fairly useless. Clang tells you exactly which + sign is at fault.

If you passed in the wrong type into a function or method then GCC would tell you that there is a type mismatch. Clang tells you which argument, what type you're passing in and what the type should be.

And finally, the single best improvement in error handling is that you miss a semicolon from the end of a line, Clang will tell you the exact line it is missing from, unlike GCC which will put the error on any line except the line the error actually is on.

But Clang's introduction as a new front end isn't just good for speed and error messages. It is licensed under the BSD open source licence, meaning that Apple can integrate it tightly into Xcode. This means they can use the exact same language parser for compiling as they do for code completion, refactoring etc. This could lead to a huge number of great new features in Xcode to bring it truly up to par with the likes of Visual Studio and Eclipse in terms of its knowledge of your code.

Static Analysis

One of the new features that Clang makes possible is the new Static Analyser. You may have heard about and used the Clang Static Analyser from the command line in Leopard, well now Xcode includes it and provides a nice GUI for it.

So what is static analysis? Well it is the analysis of your code to search for common bugs. It doesn't actually launch your code and run it to test (hence the static). It can find all sorts of errors such as code that will never be called, possible memory leaks or crashes. Because it can search multiple paths through your code very quickly it can find bugs that you would never be able to find on your own and also point out assumptions you have about your code that aren't explicitly written in your code.

New Build Window

While Xcode has got quite a few new goodies, most of the stuff to get excited over are improvements to old features. Perhaps the single biggest improvement over Xcode 3.1 is the build results window. To start with, it just looks great. I can only hope the rest of Xcode gets the same cosmetic treatment at some point in the future.

But this isn't just looks. You no longer lose older warnings when you re-compile. The new filter bar at the top allows you to view all warnings and errors in your project since you last did a clean and build. And best of all, it persists across launches! You can also choose how you want the view to be grouped, either by the build step or by the type of issue that is showing up.

It also improves unit testing by no end. As you can see in the above screenshot, it now gives you details about how many tests passed out of how many ran and how long it took. It also allows you to see the full text of the error without having to go and search through the full text build log (which as far as I can see, actually isn't accessible any more, but pretty much everything you care about is accessible through the details buttons for each warning or error). This essentially fixes all my issues with running unit tests in Xcode.

New Inline Errors

I previously mentioned that error messages had been improved if you use Clang as your compiler. Well that isn't the only improvement to errors. The inline error bubbles introduced in Xcode 3.0 have been massively improved. They were always a great concept, but they caused all sorts of problems, the key one being that they reflowed your code. Well not any more.

As you can see they are put at the right of the code view, with the full line highlighted. You may also notice a small red arrow under the "e". This is thanks to compiling with Clang, which tells you precisely where the error is. This fixes pretty much every issue with the error bubbles from previous versions.

Improved Documentation

Every developer needs to read documentation, but the documentation viewer in Xcode has long been one of those things Apple has struggled to get right. The incarnation in Xcode 3.0-3.1 was reasonably useful but somewhat awkward at times and used up a lot of valuable vertical screen space for displaying search results.

The new documentation viewer is a huge improvement, though it may take some time to get used to. The whole documentation set download system has been moved from the documentation window and into the preference window. ~~It also allows for custom doc set feeds to be added, which I don't believe was available previously.~~ [UPDATE] Apparently this was new in Xcode 3.0

With the left side of the window freed up, search results can now be displayed there. Results are now grouped by how they were found, either by API, title or full text. It also only shows the most likely matches and hides less likely matches until you want to look at them. Coupled with this is the fact that the full doc set has been updated to the new style that was introduced with the iPhone SDK, which is a much nicer layout.

One thing that Xcode doesn't do any more is install a huge collection of developer samples. Instead you can search for samples via the documentation viewer and download them. It is nice that you have a bit more disk space, but I think this is outweighed by the fact that you have to re-download all the sample code you used. It would be nice if they had included some of the more venerable samples by default.

Xcode 3.2 also does away with the research assistant, which I always found a useless piece of carp. It replaces this with a new pop up doc panel, which is reasonably useful. This is accessed by the option double click that usually performed a search in the documentation viewer (the shortcut for this is now command-option double click).

Other Bits & Bobs

There are lots of other little improvements all over the place. For one, the code completion has improved dramatically and is far more accurate than before. No longer will you get isEqualToSet: appearing as a completion for a variable that is an NSString.

The new project and new files panels have also been improved a huge amount, with small variations on a certain project or file type being moved to an options bar. You can add options for your own templates quite easily, they are only managed by a plist file. Unfortunately I can't find any official documentation on it, so for now it is a case of seeing what Apple has done and copying it.

In the world of multi-touch trackpads, Xcode isn't being left behind and now has a few gestures of its own. Much like with other browsers, 3 finger swiping left or right will move back or forwards in the history. However, 3 finger swiping up or down now moves between the header and documentation windows, which is a great new feature and one I wish I could have on my iMac.

Speaking of file history, the history now stores location within a file as well as the actual files you accessed, giving you a much more fine grain control of going back to where you were.

The old find panel has been replaced by a Safari style find bar, which removes yet another piece of needless clutter. It still supports all the stuff you expect such as regular expression search. It also has a rather nice bezel that comes up when your search loops back to the top of a file which is a nice touch.

This reminds me of another thing that has been improved. I wouldn't class myself as a designer, but I am anal about pixels in a user interface. Xcode 3.1 and lower didn't use a standard search field, but instead had a fake field. The magnifying glass was too big and the edges weren't properly anti aliased. This drove me mad, as when I notice things like that I will forever notice them (such as when iTunes had one corner not being antialiased on its window). Anyway, this is now a standard search field now, so the pixel anal side of me can now rest easy at night.

There is one last thing that has changed, which is kind of significant. For decades the standard monospace font for coding on a Mac has been Monaco. In Snow Leopard apple introduced Menlo, a new font based of DejaVu Sans Mono. It is meant be designed with Objective-C in mind, and in deed some characters do seem to be improved a lot over regular DejaVu, such as the square brackets which are much crisper.

The big problem is the * character. Call me a traditionalist but it should be a superscript character, and in Menlo it isn't. It isn't like it is a rarely used character when coding, you use it everywhere and it really grates me. I tried Menlo for a few hours and then had to switch back to using regular DejaVu. It may be nice for some, and it does indeed have some nice improvements that even I, as someone who isn't really a font geek, can notice.

Overall

In a nutshell Xcode 3.2 is easily the best update to Xcode to date. Given the scale of the improvements and the fact that it needs a new OS, it is puzzlingly that they haven't called it Xcode 4.0. I can only assume that if this is what Apple thinks warrants a .1 increase in the version number, then Xcode 4.0 will be a huge improvement.

Like with the rest of Snow Leopard, Xcode 3.2 is a release that is built around polishing what is already there and introducing new technologies upon which the next decade worth of software can be built. I believe what we have seen thanks to the release of Clang is only the tip of the iceberg compared to what could be possible. We may now be up to version 3.2 of Xcode, but we are only just beginning to see what Xcode could become.

Snow and Support

2009-08-28T18:06:12Z

In case you hadn't quite noticed yet, Mac OS X 10.6 was released today. All M Cubed apps have been tested and work fine on Snow Leopard in their current versions so you'll be able to feel safe upgrading.

However, if you do find bugs you will be able to tell us about them in our brand new support centre. You can still email us if you wish, but we also offer discussion forums that allow you to start public or private discussions that will allow you to get help from both us and other users of our software.

On top of this our new system has an integrated knowledge base. We currently have only migrated the CCP and LHK manuals over, but we will put up all sorts of useful tips and tricks in due course, so head over to support.mcubedsw.com to check it out.

The Great Dot Syntax War of 200x

2009-08-09T15:12:55Z

One of the perennial topics in the Mac developer community is that on whether dot syntax is a good idea. Reading through blog posts and twitter feeds an unfamiliar observer would deduce there that this is a Marmite issue: you either love it or hate it.

The problem is a lot of people familiar with the topic also see it as that, but the truth is quite different and there are some subtleties in the argument, particularly the dislike camp of which I am a member, that are often over looked. I'm hoping this blog post will give a better idea of why people, or at least I, dislike dot syntax.

History/Programming Lesson

For those unfamiliar with it (or those who don't program) I'll give a brief history and overview of the technology that causes the problem. Feel free to skip this section if you are already familiar with this tale.

In object oriented programming (OOP) you store variables (containers for data) within classes (containers for variables and methods, or actions upon that data). One of the key concepts is encapsulation, which means that these classes are black boxes and you cannot directly access the variable, but instead have to call a method to get to the data. Think of this as a bit like a cash machine, where you don't directly get the money, but instead use an interface to ask for the money and then receive it. These sorts of methods go under many names: accessors, getters and setters, properties etc.

In versions of Mac OS X prior to 10.5 writing these methods required writing a lot of code that is almost identical for each variable. For example, the code for accessing the variable foo would be:

//Header
- (id)foo;
- (void)setFoo:(id)newFoo;

//Implementation
- (id)foo {
    return foo;
}

- (void)setFoo:(id)newFoo {
    if (foo != newFoo) {
        [foo release];
        foo = [newFoo retain];
    }
}

There are many variations on these methods but they all do the same thing, either return the contents of a variable, or replace the contents with a new piece of data.

You can probably tell that writing that over and over can get tedious, when there are only minor differences you can make, usually in memory management or thread safety. So in Mac OS X 10.5, Apple introduced Objective-C 2.0 which featured, amongst other things, properties. This allowed the simplification of the above code to:

//Header
@property (retain) id foo;

//Implementation
@synthesize foo;

Much simpler. It also adds extra information that wasn't previously there, such as the type of memory management used and whether it is thread safe or not.

Now while this brought almost universal praise, Apple also introduced a new syntax for accessing these properties: dot syntax. This allowed programmers to use properties in a different way:

//Standard way
variable = [object foo];
[object setFoo:variable];

//Dot syntax way
variable = object.foo
object.foo = variable

Implementation vs Idea

For the purpose of explaining why people feel a certain way about dot syntax in Objective-C it is important to distinguish between implementation and idea. In this case, dot syntax is the implementation. The idea is a simpler way to use properties. A lot of the complaints are not with the idea, but with the implementation.

Another example of this in Objective-C 2.0 is garbage collection (automatic memory management). There are a lot of people who are wary of using garbage collection. Some are wary because they are used to the idea that garbage collectors are much slower and less efficient than manual memory management (in most cases the opposite is true with the Objective-C garbage collector), but this stigma of the idea of garbage collection remains.

Then there are people who are wary of the implementation. They feel that it is a major commitment to something that is relatively untested. I had a discussion a few days ago where a programmer started writing a garbage collected app and then found a bug with no work around other than "wait until Apple fixes it", so he had to go back through his code and switch to manual memory management.

In this case this is a complex piece of technology that is quite new and can seriously harm your project's shipping date if you encounter a bug with no work around. Now before people get the idea that I'm anti-garbage collection, I'm not. I'm using it in Minim 2.0, but this is only because it has been around for 2 years now, and many bugs have been fixed in updates to OS X 10.5. The garbage collector in Objective-C is great, it is just a 1.0 release.

Anyway, enough with the small detour into garbage collection, that isn't the main topic of this post. However, it has offered us a good example of why someone may dislike an implementation, one that is different to why most developers dislike dot syntax. Developers are wary of garbage collection because it is new. Developers dislike dot syntax because they believe it is flawed.

Why Dot Syntax?

There are many reasons one can suggest for why Apple chose dot syntax. The most obvious is that it is somewhat similar to how other languages work. Whereas Objective-C uses [object method] to run a piece of code, lots of other languages use object.method(), and some even allow identical object.property = newvalue syntax for variable access.

It is this familiarity that may help programmers move from other languages. Unfortunately this isn't necessarily the case. Dot syntax is inconsistent, working for methods that aren't properties. It also can cause confusion between objects and C structs (more on this later). I have seen several new programmers get confused by this, as they can use dot syntax for certain methods, but not for others. There are even pro-dot syntax developers who agree that it shouldn't necessarily be taught to new Objective-C programmers until they have got a good grasp of the language.

Now there is an argument against those of us who are anti-dot syntax, that we are simply Objective-C old hands who are opposed to change. This isn't the case. There are many people who have been using Objective-C since before Apple had anything to do with it who are using dot syntax and there are those who only started with it a few years before dot syntax arrived that dislike it. I only started programming in Objective-C 5 years ago, not exactly an old hand when you consider Objective-C is over 20 years old.

The other reason why this isn't true is that these programmers embrace all the other changes. They use properties and fast enumeration and garbage collection. They use new APIs and new tools. A lot of these "luddites" who are supposedly opposed to change are actually the ones at the forefront of change. The difference is that change can be for the worse or for the better, and while they believe most of Objective-C 2.0 is change for the better, dot syntax is change for the worse.

State vs Action

Now one argument for the idea of a separate syntax for property access is that it helps separate state and action. This is quite useful in places as you can tell when state will change, which is useful for many things, but importantly thread safety. For the most part I agree with this, but I believe there are issues.

The biggest is simply an issue of how you conceptually view your program working. Those who are fully behind the state vs action system see [object doSomething] and object.property as different things. One is performing an action, one is accessing state. I see things at a more abstract level, where both those are simply sending a message to an object, so they are identical in what they do. This is somewhat anal, but it is how quite a few developers feel.

Structs

I made a tweet that proved to be quite controversial, saying that I thought developers who think dot syntax is a good idea don't do much UI coding. The reason behind this idea is that UI coding requires the usage of C structs. A struct is a simple container for several pieces of data, and in some ways is a sort of lightweight class. It is because it is lightweight that it is used all over the UI side of Cocoa for defining rectangles, sizes and points.

So what is the issue? Well this is how you access a struct:

variable = struct.field;
struct.field = variable;

Looks familiar, doesn't it? This is the biggest issue, the fact that struct and property access is identical. If you look at the following, would you be able to tell me which is the struct and which is the property?

a.b = foo;
c.d = bar;

Of course that example is a bit contrived so let us look at something that you may actually find in Cocoa:

rect = controller.view.frame;
rect.size.x = 10;
controller.view.frame = rect;

Now an experienced Cocoa developer could tell you that controller and view are objects and rect and size are structs, but someone new to Cocoa couldn't tell the difference.

Of course we could just get rid of structs and use objects for everything, couldn't we? Unfortunately no. Structs are relatively lightweight when compared to objects, so are ideal for tasks such as defining a rectangle when you only need to collect 4 values into 1. You don't need all the unnecessary cruft of creating an object, so it makes your code faster and your memory usage smaller (granted these aren't as big an issue with modern computers, but there is no point slowing things down).

The other issue is that Objective-C is also C. Anything valid in C is valid in Objective-C, and structs are part of C. There is no getting rid of them. You could get rid of them from Cocoa, but you would still be mixing object.property with struct.field.

Of course this confusion can potentially be dangerous. struct.field is simple memory access/assignment, you cannot make it do more. However, object.property isn't necessarily just memory access/assignment (technically it almost never is). There could be file access, network access etc. happening under the hood, but you see the same thing. This confusion can be potentially damaging.

[UPDATE] Note, that while I mention object.property, I don't imply that accessor methods will be doing resource intensive tasks, but the fact that dot syntax isn't limited just to properties means that object.method could be used and would be computationally intensive.

Conclusion

So what is the solution. Well as I said earlier, most developers don't have an issue with the idea of a different syntax for property access, the issue is with the implementation. The solution would have been to not overload the . character. There are many other ways that property access could have been done and most of the arguments above vanish if a different character is used. Why not foo~bar, foo•bar or foo@bar. None of those characters are used in binary operations in C or Objective-C.

The important point is, those who are against dot syntax aren't simply the old school who don't like change. They like change, they embrace change, but they just feel this is a change for the worse. You may feel differently about the syntax, but there are many significant cons to the current implementation, which is why there will always be those who dislike it. And all of those cons revolve around one character.

Making Xcode’s Source List Work For You

2009-08-03T17:28:58Z

One of the first things you'll see when you open a new project in Xcode is this:

This is the default Xcode source list and to be frank, it is one of the biggest pile of donkey droppings Apple has created. One table is used to manage files, built targets for each bundle, access executables for changing sessions and also get access to compiler errors, searches, project bookmarks, version control, breakpoints etc. Needless to say it is a frustrating and annoying experience.

The problem is, this has been solved in the condensed layout mode, with the items split up into 3 different tabs. File management is done in the Files tab, target related stuff in the Targets tab and all the other guff is thrown into the Other tab. Apple obviously acknowledges that these need to be separate, but only provides an obvious way to do it in one of Xcode's 3 layout modes. For any project with a lot of files you need to do a lot of scrolling to get to other sections.

The key word there is "obvious". I discovered yesterday that there is a way to make the Xcode source list suck a hell of a lot less. I've known for a while that you can split the source list vertically, but what I didn't realise is that each split view can have different items in it. This opens up the source list to be a much more flexible tool.

With this new discovery I have been able to add all the bits I care about to different split views and delete all the other stuff I don't care about. I've never really used anything other than the project, targets and executables sections. The others generally can be accessed from elsewhere in the UI, but in an All-in-one layout the breakpoints group can be useful as it prevents the breakpoints UI from popping up in a separate window.

So now my source list looks like the one below (though less condensed as I'm not trying to take screenshots of it most of the time). The top files section takes up most of the space as that is where I spend most of the time. I've moved the NIBs smart group into a section of its own so I can always have access to my NIB files no matter what the state of my file tree is, and I've got the 3 other important sections at the bottom, which I can move up as and when I need to access them:

But how do you show and hide these various sections? Well the quickest and easiest way is to just select an item and hit backspace to delete it. The other way is to right click on an item, select the preferences menu item and select the item from the list to remove. Unfortunately this is a little buggy so do not combine the two methods. The menus don't want to link up to the correct split view which can cause a lot of frustration after deleting by hitting backspace. As always, I've filed a bug which you can read on Open Radar.

It would help to get Apple to fix this (hopefully for Xcode 3.2) if others were to file bugs referencing this and show it is affecting a lot of people. The fact that the menus are so buggy with this shows that this probably isn't a well known tip, I've used Xcode for nearly 5 years and only just found this, but hopefully it helps you with making Xcode's source list much more useful.

Where To Use Unit Tests

2009-07-22T16:33:38Z

So I’ve started to do a lot more unit tests than I usually do while working on Minim 2.0. I’m not doing test driven development, I made my thoughts on that clear in an earlier post. However, I feel a lot of the issues people have with unit tests and their use are misplaced. So I thought I’d outline where and why I’m writing unit tests. There are a few rules I have about whether a method should or should not have unit tests.

Trivial methods don’t need tests

If you are unit testing properties you are insane. If you are unit testing methods with one or two lines you are insane. There is no need to test these methods. You can understand how they work quickly and easily and if you don’t because these few lines are very complicated then you need to break your code up into a few more lines.

Methods with complex logic need multiple tests

Any methods that have complex logic should have multiple unit tests. The reason is that complex logic is not as easy to understand at a glance, even if you wrote it. As such it is much easier to break. There are very mixed opinions about using automated tests to help develop an app, but almost everyone can agree that automated tests are great if they stop you breaking good code.

Depending on the complexity of the method you should have multiple tests. Obviously you can’t test everything but try to cover the most common case and any edge cases you think could cause problems. For example, if your method should do something differently depending on whether a flag is YES or NO then test both the YES and NO cases.

Methods used by multiple parts of the app need tests

These are possibly the most important methods to test. These are the ones that are accessed by multiple parts of your app so you will likely be changing quite often. The problem is that while you change it for one part of your application, you may forget to test all the other parts of your application that use it so it is good to make sure that these other parts get what they expect from the method.

If you fix a bug in a method then write a test for it

What is the point in fixing a buggy method if you’re just going to break it again later? Write tests when you fix a bug to make sure it stays working. This method also means your test suite can grow organically.

These 4 rules are what I use to decide whether I should write a test or not. Often I’ll work on a feature and get it working and then go through my methods and decide what would be worthwhile writing tests for. This way I can focus on development and then spend a few hours afterwards concentrating on the testing. The added benefit is that I can think again about how my code works, which may lead me to find issues that a unit tests can’t fix.

Designed by M Cubed

2009-07-06T23:41:12Z

Today is the start of a new era for M Cubed. There are 3 exciting things happening and the first is the most obvious: a new website design. We’ve gone through the whole site and redesigned everything from the bottom up.

The biggest change to the site is the new store, which allows you to buy multiple applications at the same time, as well as our new 5 user licences which offer a discount over the cost of single user licences if you need to buy in bulk

M Cubed times 2

For a long time M Cubed has been a single person operation, with me handling everything from programming to application design to the website to support. Well I’m pleased to announced that I am no longer working alone. May I introduce my new partner in crime: Fabio Basile.

Fabio is joining M Cubed to work on design and also some programming. This will help us get updates out faster, while making them look much better.

Design & Conquer

But Fabio isn’t only going to be designing and coding stuff for M Cubed. If you look at the navigation links at the top of the page you’ll notice there is now a “Design” link. Click on this and you’ll be taken to a wonderful world where you can get your design done by M Cubed.

Yes, no longer content with just producing amazing software, we are also going to offer amazing design services. We will be offering icon design, website design, user interface design and also Django server-side programming. If you’re interested then head over to our Design section to find out more!

M Cubed has gone through quite a few significant changes recently, but they will all help us produce much better software for you much more quickly than before. Watch this space as there are exciting things coming soon.

The Named Argument

2009-05-31T09:29:51Z

Thanks to the iPhone and the growth of the Mac there are a lot of people now interested in Objective-C and Cocoa. Many of these developers come from other backgrounds such as Python, Ruby, C#, C++, Java etc, but Objective-C is quite a different beast to those languages.

Of course there are quite a few similarities. It shares the C heritage of C++, it is highly dynamic like Python and Ruby. However, the biggest difference between Objective-C and most other languages is how method names and arguments interact.

At first glance a lot of developers coming from other languages think that they are simply named arguments which is wrong, VERY wrong. This is one of my pet peeves about new Objective-C developers, and every time I see someone talking about named arguments in Objective-C I always feel a need to correct them. But if they aren't named arguments then what are they?

Interspersed Arguments

The arguments aren't named, but interspersed with the method name. For example, a method in another language may be obj.foo(namedArg1=bar, namedArg2=possum), so its method name is foo. In Objective-C a similar method may be [obj foo:bar with:possum]. In this case the method name is foo:with:. So the arguments aren't named, they are mixed in with the method name.

There are some key differences between named arguments and interspersed arguments:

1) Named arguments' names are not part of the method name
2) Named arguments can be re-arranged
3) Named arguments are often optional

None of these hold true for interspersed arguments. This is why I've seen quite a few people complain about Objective-C's "named arguments" not being very flexible. When you realise they aren't named then things get much easier to understand. As with everything in Cocoa and Objective-C, if it is different to what you are used to, then there is likely a very good reason for it being that way.

Examples

So it would make sense to show some examples comparing named and interspersed arguments. So lets take a common Objective-C method:

[@"A string" compare:@"B string" options:NSCaseInsensitiveSearch range:someRange];

And now lets convert it to a language like Python which has named argument, treating the arguments as named arguments:

"A string".compare("B string", options=NSCaseInsensitiveSearch, range=someRange);

Not a big difference at first, but lets try some variations:

"A string".compare("B string", range=someRange, options=NSCaseInsensitiveSearch);

"A string".compare("B string", options=NSCaseInsensitiveSearch);

In Python those are both the same method as the first one. However, in Objective-C, re-arranging the arguments or removing them would result in an entirely different method being called. While in the Python examples the method is called compare() in the Objective-C example it is called -compare:options:range: which is a big difference. If we correctly treat the arguments as interspersed then the Python example becomes:

"A string".compare_options_range("B string", NSCaseInsensitiveSearch, someRange);

Of course Python doesn't support interspersed arguments so they are all attached at the end, but basic rules are the same. Hopefully this has helped quite a few Objective-C newbies to understand one of the many differences between it and other languages they are used to, but if you have any questions then leave them in the comments.

Going Full Time

2009-05-28T17:42:06Z

So I've done it. I said in November that I wanted to be able to go full time with M Cubed in about 7 months. 7 months later I'm going full time. It's been a long time coming but I have finally finished my full time education and can now concentrate fully on M Cubed.

M Cubed has been a part time venture ever since it was founded back in 2005. It always came second to exams and assignments and homework. Because of this releases have been far and few between and often come in spurts when I've had a lot of free time. In the past 3 and a half years I have released just 10 major updates to apps. I'm wanting to seriously improve on that by getting major updates to all my current apps out by the end of the year, and possibly a new app or two.

With all the extra time I will have now, you can expect to see a lot more open source efforts from M Cubed as well as more blog posts discussing various technical things. It will be nice to be able to dedicate time to give back to the community that has helped me get to this point.

And finally, there is some incredibly huge news still to come, all will be revealed on the 1st of July, so watch this space.

Success != Being Rich

2009-04-23T14:15:16Z

I don't usually write anything on here that may be related to politics (that's usually left to my twitter account) but there is something I heard today that irked me enough to write a blog post on it. It relates a lot to running a business but also to life in general so hopefully it will be of interest to those who are reading it.

For those who don't know, I'm based in the UK. Yesterday the UK government announced the budget for the next year. As well as hearing about how we're all basically doomed the government announced that there will be a new 50% tax band for those earning over £150,000 a year. This means for every pound you earn over £150,000 a year, half of it will go to the government to pay for various public services.

Of course there has been outrage from many of the 1.5% of the population who earn over £150,000 a year and this is partially understandable. Nobody likes paying taxes, but they're a necessary evil and help to pay for things such as health care, roads, schools, parks, refuse collection, police, fire services, defence and many other crucial services. Unfortunately some of the rich feel they're being punished for being successful.

Perceptions of Success

The BBC News had a businessman on their channel to talk about the implications of the tax rise. He felt it was unfair that the successful were being punished for their success. Of course what he really meant was "rich". There is a common perception that in order to be successful you have to be rich. To me this is incredibly flawed. A CEO of a failing company can be incredibly rich but the owner of a small, but successful business may not be rich (thought they probably aren't poor). Yet for some reason the CEO is seen as more successful in life.

Its this perception that leads to many people's desire to be rich. They want to be seen as a success. The problem is it is wrong. Taxing people 50% on their earnings over £150,000 isn't taxing the successful. It isn't really taxing the rich either. It is taxing the greedy.

Massive wages = greed

OK, so that is a little unfair. Some people need bigger wages. Perhaps they're in a career where they can't work until they're 65. No-one would have any qualms with police officers, fire officers, sports stars, soldiers, physical labourers etc earning higher than average per year. Their wages may go down after they are required to change career or forced to retire because they are too old, or have picked up an injury caused by their work, so earning more while they're in their prime makes sense.

I'm also not advocating everyone should be paid the same wage. Those who are highly skilled should be paid more then average. Those who put themselves in danger and/or save lives should be paid a hell of a lot more then average (and also a lot of respect). A varying pay scale is perfectly fine. It is also a case where you may need to earn more depending on the number of people dependant on you (eg children) or where you live (eg London is a much more expensive place to live than Blackburn).

The problem is with those who earn a lot of money each year, more than £150,000, and then spend it on themselves. These are often the people complaining the most about higher taxes for the rich. Of course not everyone who earns that much money is greedy. Some people earn a lot of money but give a huge amount of it away to charity. Nobody could call those people greedy (indeed I believe all money given to charity should be fully tax deductible to encourage more to give to charity).

But those who have a lot of money left over after they have given to charity and paid for the essentials that everyone needs are just being greedy. They'll likely buy themselves a much bigger house they need, or an extremely pricey sports car etc. Things they don't need with a huge amount of disposable income. Things to signify "success".

The Right Thing To Do

So if you are earning that much money, you really have no right to complain. If you are running a successful business and taking £150,000 a year in wages or more then you're being greedy. You could give yourself £50,000 a year and still be incredibly well off. You could have a large house, 2 very nice cars, go on holiday abroad once a year etc.

But what about the other £100,000? Well that could be given to charity. Think about how much good you could do with £100,000. Or how about hiring some more staff. You could hire three people for £33,000 a year. That's a pretty decent wage and you've just helped lower the unemployment figures by 3 people.

The reason that those who earn a lot of money are taxed at a higher rate is that the money they have being taxed at that rate is disposable income. They don't need it, they simply want it. That money can be used for a lot of good and improve the lives of a lot of other people.

Success really needs to be redefined, or rather it's actual definition needs to be reclaimed. Success should be based on how well you perform, not on how much you earn.

Businesses vs Individuals

Businesses are slightly different to individuals. If a business earns a large profit then it's not necessarily a bad thing. In fact that is success. Of course how they use that profit is key. They may give all their employees a share of it, or invest it in research and development. They may save it in order to protect themselves against times when they make a loss or for future plans such as expansion which will create jobs.

Of course, that doesn't mean businesses should be entirely immune to criticism either. If they do make a huge profit they should also not complain about it being taxed. The money that gets taken away as tax goes towards many things that help them as a business prosper, and also in improving the lives of their individuals.

Tax money that goes into improving schools helps provide more skilled workers for the business. Tax money that goes into transport helps the business move their goods and workers around. Tax money that goes into communications infrastructure helps the business expand while being able to keep track of everything. The taxes being taken from a business's profits aren't really a loss of money, but an investment in the business.

Success = Doing Well

As I said earlier, taxes are a necessary evil. But higher tax rates on higher earners is not taxing the successful. There are plenty of people earning under £150,000 who are successful, to say otherwise would be saying 98.5% of the population are failures.

Success as a word needs to be reclaimed to mean doing well, setting out goals and meeting or surpassing them. If we can do that then maybe we can see society becoming more equal and those who do earn a lot of money choosing to help others with it, rather than themselves.

The Obligatory NSConference Post

2009-04-21T13:38:07Z

So NSConference has been and gone. This was my first Mac conference so I've not really got anything to compare it to, but it was the most interesting and enjoyable few days I've had all year. Mac developers are often quite isolated and don't get to meet up very often, at least not in large groups. This was the first time I've met so many Mac users in one place and it was a great experience.

The Conference

The talks were great and I picked up some great tips and learned about some cool technologies that I'll be looking into more in the future. It is often the little things you pick up from in talks that really stick with you and can help you the most. This was helped by the last session where the speakers had to give a few quick tips over 3 minutes after being pulled away from an application design competition they were working on.

I was lucky enough to be given a short lunchtime slot to talk about accessibility. I made the talk, not to discuss technical issues, but to emphasise why accessibility is important and should be top of our agenda as developers. It seemed to really resonate with those in the room, with many saying they were going to make the pledge to make their apps fully accessible by the end of the year. Those who didn't were also very committed to accessibility but many didn't want to make the pledge as they were unsure they would be able to fulfil it before the end of the year. At the very least, it brought a very important topic front an centre to a large chunk of the Mac developer community.

The conference was held at the University of Hertfordshire in Hatfield on the relatively new de Havilland campus. The facilities there were great, with the restaurant (which served excellent food for breakfast and lunch), bar and lecture theatre where the talks were held all within a short walk of the accommodation.

Of course, being a university campus the accommodation was decidedly student oriented, though still being a student it wasn't a problem, plus besides the few moments spent sleeping there wasn't much time spare to be spent in your room.

Now all this wouldn't have been possible without the time and effort put into organising and running the conference by the staff. Scotty and Tim did a great job and managed to put on an amazing event which everyone who went is thankful for. And we can't forget Dave, who dealt with many of the technical aspects of the conference and Ben, who sat patiently outside at the registration desk for hours on end. These guys worked incredibly hard with very little, if any, money in payment for their time and effort and a lot of people now owe them a great debt of gratitude. Here's hoping for an NSConference 2010. If there is one you can bet I'll be there.

One important thing that was mentioned at the conference but not linked to, was my unofficial attendees list. If you went to NSConference make sure you add yourself so others can know you were there!

The Badge

Now, as all the praise is out of the way, lets get onto what went wrong. (Actually, one more bit of praise. The badges we received were incredibly well designed and clear and it was obvious a lot of thought had gone into them. Anyway, back to the failing).

It turned out I was the very first person to register for the conference (I feel like I should have had a golden badge with "#1" written on it, but oh well) and so my badge ended up being the test badge. Scotty and Tim printed out loads of badges with my details on until they got it right. Once they'd perfected mine they printed out everyone else's.

Then it comes to the conference and they pull out all the badges to put into their holders. Out of over 100 badges the only one they couldn't find was mine, the one which they had done the most copies of over the past few weeks. So of course starts a frantic search for the badge, which is eventually found at the bottom of a waste paper bin all crumpled up.

So here is my badge, all crumpled up, next to all the pristine flat badges of the other attendees. So what is the solution to this? Well they pull out an iron (who knows why they had an iron) and start to ponder whether they should iron the badge flat. Thankfully this whole thing was caught on camera by Alasdair Allan (see his flickr set for the conference here) for all the world to see, so I shall leave you with 3 orange men, an iron, a hair dryer and my badge:

Scotty, Tim and Ben wondering how to flatten my badge. Photo Credit Alasdair Allan

Lazing by the NSAutoreleasePool

2009-04-04T16:21:25Z

In a reference counted environment there are times you need to release an object after it has passed out of the reach of the method or object that created it. To solve this Cocoa has the concept of an autorelease pool. A developer can set an object to be auto released, which means it is added to one of these pools which is periodically drained.

If you are creating an AppKit application, then you have an autorelease pool set up for you so you don't need to worry about it most of the time. If you set up a Foundation tool then you'll find that the Xcode template puts code to initialise and release an autorelease pool at the beginning and end of your main function.

However, a problem arises when you're creating a lot of objects at once. The obvious solution is to initialise and release objects by hand in this case, but sometimes it isn't possible. A lot of objects returned by Cocoa methods are autoreleased (by convention any object returned by a class method (other than +new or +alloc) should be autoreleased).

I had one of these situations in Code Collector Pro. Some users were having problems when pasting in the jQuery code, so I decided to investigate. I found that CCP's memory usage was jumping up by about 800MB when performing the regexes to find what code to colour. Obviously that's bad.

The problem is, there were a huge number of autoreleased objects being created, but the autorelease pool only releases all the objects it contains at the end of each cycle of the run loop. All these objects are being created on once cycle.

The solution? Make another pool just for these objects. Autorelease pools are stored in a stack (one per thread). If you initialise a new one all objects autoreleased until you release the pool will go into it. The code that was creating objects was running in a loop so it made sense to release the objects after every iteration of the loop. So I changed my code from:

for (id item in array) {
    //Perform regexes and colour
}

to:

for (id item in array) {
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
    //Perform regexes and colour
    [pool drain];
}

This reduced my max memory usage from the 841.07MB show above to 22.33MB. You can also see below how there are many peaks and troughs in the memory taken up by objects now. These represent each iteration of the loop, where a lot of objects are created and then released.

Good use of NSAutoreleasePools in areas where you are creating lots of objects can reduce your memory footprint a huge amount, especially in loops.

On Bundles and Heists

2009-03-25T19:30:21Z

Another year, another Mac Heist, another round of developers and users talking about how this is bad for developers and users alike. For the first year of Mac Heist I was in this group, which was much larger than it is today. I thought it devalued the software and let those running it run away with a hell of a lot of money while the developers got left with the support burden.

For the first year this did seem to be the reality, with developers getting fixed 4 or low 5 digit sums for their participation (apparently the amount each dev got was doubled after they saw how successful it was. This is what caused most of the outcry as it seemed those who were doing the marketing were exploiting those who did the "real work".

The second Mac Heist didn't receive quite as much controversy. People felt that developers knew what they were getting themselves in for this time. The deal was also a revenue share one rather than a fixed amount. The third and current Mac Heist is operating the same way and is receiving even less controversy.

The change is that developers are finding out more about how the bundles are run and maybe have participated in one of the other smaller bundles. The users are seeing better and better bundles each year with huge sums going to charity. And most of all we're finding out that it isn't a case of the developers doing the "real work" and the Mac Heist team just setting up a website. The amount of polish that goes into the website and the challenges rivals even the best Mac apps. Every year it becomes more apparent that Mac Heist isn't an easy thing to organise.

But...

But none of that will make some of the issues go away. Does this devalue Mac software? Does it hurt developers? The first question I can't answer beyond saying that only time will tell, but I think it won't. The second one I can answer with a resounding no.

For those who don't know, I participated in a smaller bundle earlier this month called the Mac Bundle Box. It worked on a similar concept with 14 apps selling for $49 with 5% going to charity and each developer getting a percentage amount of the profits. It didn't sell anywhere near as many copies as MacHeist does, but it was still a hell of a lot of sales. How many sales? Well I made about twice as much as I currently do a month from regular sales, yet my support load has hardly increased.

Another important impact is the publicity. Your sales outside the bundle can increase as people find out more about your applications. Of course this is more likely to happen if your app costs less than the bundle price, but it is an important thing to considered. It also builds up your user base meaning many more people spreading word of mouth reviews.

Money, money, money

As an example of how much developers are making let's look at the figures Mac Heist provides on their site. At the time of writing there has been $123,000 raised for charity, meaning $492,000 in revenue. There are 12 apps, plus a bonus app, plus the Mac Heist team all getting money from this. Let's assume a straight 14 way split, that would be 7% (actually a bit more but let's round down to take into account expenses somewhat). That would mean each party has so far got $25,830, enough to live off for a year if you keep your costs low.

And this is only so far on the first day. There are another 13 days to go on top of the rest of today. Sales will slow down but they'll still be making a 5 digit sum each day. Let's conservatively assume that they average $10,000 a day, that would be $140,000 each for 2 weeks.

Obviously the maths isn't perfect, the expenses may be more, the parties won't get equal amounts (I'd wager that the cheaper apps get a smaller percentage than the bigger apps), but we're still talking a LOT of money. One Mac Heist could set a developer up for several years or let them invest in support staff or other developers. Basically it is more than a good deal for developers, so don't worry about them unless the ones participating start complaining.

The Accessible Mac

2009-03-05T12:33:52Z

A recent few posts about accessibility in the Cappuccino web framework got me thinking, how well do my applications fare in terms of accessibility? The answer: OK.

Of course OK isn't good enough. The Mac is a platform the prides itself on user interface, yet it seems it isn't quite as good as we might think. I'd spent no time thinking about accessibility in my applications, and while they were more accessible than I was expecting, there is still a lot of work that needs doing. So I thought I'd check how some other popular applications work with accessibility and what can be done to improve accessibility on the Mac as a whole.

Using VoiceOver and Keyboard Navigation

The first thing to do is explain how to use VoiceOver and navigate your application with the keyboard. Let's use iTunes to try with. With standard keyboard navigation you can easily enough move between the search field, song list and source list and can click on the various buttons with the mouse. But obviously this isn't going to be enough for someone who is visually impaired or who has a motor disability to make full use of iTunes.

To turn on VoiceOver you can go to System Preferences > Accessibility, or just hit Command-F5. Now you will see a black border around one of the UI elements. This is the currently selected item. You can navigate the UI using control-option and one of the arrow keys. Just move around and see how you can how access the full UI, especially take note of what VoiceOver is saying on the various buttons.

Quick Tip: To navigate HTML content, hit control-option-A when the HTML view is selected. This will start reading the full site. You can now use control-option and the arrow keys to navigate the HTML

Below is a table containing some useful shortcuts for navigating the UI from your keyboard, even without VoiceOver selected:

Shortcut	Description
Spacebar	Press the selected button
Control-F1	Turn on Full Keyboard Access (needed for the other shortcuts)
Control-F2	Switches the keyboard focus to the menu bar so you can navigate menus
Control-F3	Switches the keyboard focus to the dock so you can navigate the dock
Control-F4	Switch between windows
Control-F5	Select the active window's toolbar
Control-F6	Highlight a palette
Control-F7	Switch tab behaviour between "All controls" and "Just lists and text fields"

Now try your own app and see how it fares; odds are it won't do too well. But you aren't alone. Here are a how well a few popular Mac apps work with accessibility.

Coda

For the most part Coda isn't too bad, but one pretty serious bug. It seems to cause VoiceOver to be unable to move around the UI if you switch between Local and Remote views in the source list, stating that it is "busy".

Coda also highlights the most common accessibility flaw: Image Buttons.

As you can see, the descriptions of these buttons aren't very, well... descriptive. These are the most common problem, yet also the easiest to fix and can make a world of difference.

OmniOutliner Pro

OmniOutliner Pro has a huge failing. There's no way to navigate to the inspector using just the keyboard. The standard Control-F6 command doesn't work. This means that you have to use the mouse in order to move to an inspector. And when you have moved to an inspector, there is no way to move between those inspectors without again using the mouse. This is a shame as the rest of the application works pretty well with VoiceOver.

MarsEdit

As with most applications MarsEdit is fairly good, but far from perfect. In the post window there is no way to navigate to the Categories table. You can just about get it to highlight with VoiceOver, but it won't let you navigate it. Besides this though the post window is pretty good. The same goes for the main MarsEdit window, besides the image buttons with no descripdtion it has no major flaws.

Delicious Library 2

Again, Delicious Library 2 suffers from image buttons with no descriptions. But by far the biggest problem is the main display view. They keyboard navigation is great, I can move all around my books and CDs and DVDs using my keyboard. But I'm getting no feedback about what the currently selected item is. As I switch items it would make sense for it to read out the names of those items so I know where I am.

The Challenge

So I did come at those from the perspective of someone who hasn't got a disability (well I need glasses and have mild RSI but I can use my computer without needing any real help). What I consider "pretty good" may still not be too good for a disabled user. But what is obvious is that there is a lot of work that needs to be done. We all take so much care and pride in our visual UIs that we don't think enough, or really realise that there are other UIs that people need. Most of us wouldn't ship a shoddy, half baked UI but the fact is that we are all doing that.

So I thought I would challenge my fellow Mac developers to do something that I am pledging to do here and now:

"By the end of 2009, all the apps I produce will be fully accessible"

What do I mean by "fully accessible"? Well, I take it to mean the following points:

The UI available to VoiceOver users should be as user friendly as the visual UI
All UI elements should have titles and/or descriptions
All custom controls should provide full keyboard access
There should be a clear and logical order to navigating UI fields with the keyboard
Every part of my application should be reachable without the mouse

Of course there are some caveats. Some applications cannot be easily made accessible. Photoshop for example would be nearly impossible to make fully accessible to visually impaired. But it is conceivable that someone who is unable to use the mouse could draw. OS X does provide methods for controlling the mouse cursor with the keyboard, but with some inventive thinking certain classes of drawing application could be made much more accessible.

Accessibility For All

Making your application Accessible can also offer great advantages in other areas. Tools such Instruments and Automator use the accessibility APIs for recording UI actions to perform back. This can help you as a developer with debugging and your users with automating your application. And if you or your users want more flexibility, making your application accessible opens up the possibility of creating UI scripts in one of the various supported scripting languages.

There are also other potential applications of accessibility. Those of you from pre-OS X days will remember the old Mac Help system that could guide you through performing an action by highlighting the relevant parts of the UI and even performing the actions for you. There's no reason why that shouldn't be possible in an OS X app. Imagine how much documentation writing and support time you could save by being able to have your application show users how to use it!

But...

Of course there will be some questioning the value of doing this. They realise it's a nice gesture, but they don't see the return on investment:

"But I don't know anyone with a visual disability" - I don't know any starving african children or anyone dying from cancer, doesn't mean I shouldn't care. Because you don't personally know someone with a problem, doesn't mean nobody has that problem.

"I've never received any support requests asking me to improve accessibility" - That doesn't mean there aren't those out there wanting better accessibility. Consider that someone might use your app, find it's not accessible and just give up on it. They're not going to waste time sending you an email when they can't see if your app is even worth their time and money.

"Sounds like a lot of work, I'm not sure if it'd be worth the time" - Making your applications completely accessible may take a lot of work, but you can do a huge amount in just a few hours just using Interface Builder. Going through and making sure you controls all have accessibility titles and descriptions, linking your UI elements together properly, making sure the accessibility hierarchy is usable. All these are small tasks that don't take too long and can improve your accessibility a huge amount. You don't even have to do all the accessibility stuff in one version, split it over several versions.

"But I can't make my application accessible for blind people" - Don't think that accessibility is just for blind people. Being visually impaired doesn't mean you can't see, just that you have trouble seeing. There are also other forms of disability that need accessibility such as hearing disabilities and motor disabilities. And on top of this, keyboard navigation can appeal a lot to power users who have no disabilities at all

In Conclusion

Unless we experience something or are affected by something personally, we usually don't care about it as much as we know we should. Try closing your eyes and doing something. Odds are you'll end up opening your eyes for a peek at some point. You're lucky to be able to do that, some people can't.

I've not got a disability that limits my ability to use the computer and don't personally know anyone with one, but I do have a strong sense that we should all be treated equal and have equal opportunities. When we can do something to help someone else and it is very cheap or very easy to do, then we should do it. Making accessible applications can be very easy and not take too much time, but can make a world of difference to some people.

Over the coming months I'll be posting my experiences in making my applications fully accessible so you can learn from what I've found out. We've already made the Mac the platform with the best visual UIs, let's make it the platform with the most accessible UIs.

Apple's Accessibility Developer Page

MacBundleBox

2009-03-02T11:56:45Z

For the next 10 days Code Collector Pro and 12 other applications are taking part in the MacBundleBox. This is your standard bundle deal: get lots of cool apps for very little money, in this case just $49. There are some really cool apps in the bundle, such as DrawIt (a vector drawing package) and DEVONnote (an advanced note taking application).

The great thing about bundles like this is that you can find out about lots of other cool applications you've never seen before, such as Espionage, QuickScale, Magnet and Involver. A lot of people tend to criticise bundles that don't offer "the big names", but I personally find them much more useful for finding new apps if you've never seen them before.

This bundle is also donating 5% of each sale to Charity: Water, a charity that aims to give clean drinking water to the 1.1 billion people without it, so not only will you be getting a lot of great apps for a low price but you'll be helping others get what we all take for granted.

M Cubed Developer Centre

2009-02-22T17:04:02Z

I've been wanting to announce this for quite a while but unfortunately I've never had the time to complete it. Today I finally finished the M Cubed Developer Centre, a unified place for all my developer related articles and open source.

The two main items on the page are M3Extensions (my set of extensions to Cocoa that I use in all my apps) and OCRunner (my GUI for the OCUnit testing framework). OCRunner's page isn't quite finished yet so it just links to the Launchpad site. I'm going to be spending a few days polishing up OCRunner so expect to see its own page soon.

I'm also listening all my blog posts that might be of interest to developers, so you don't need to sift through all the other stuff on the blog. And last but not least there is a collection of smaller projects I've open sourced. These deal with installing from disk images, handling betas, token clouds and more.

I'll be adding more to this site as I find other parts of my apps that would be good to open source, so it will hopefully grow quite large. In the mean time, enjoy what I've put up today and let me know what you think!