Cocoa has changed a lot over the years. I started programming on 10.3, when Xcode was a version 1.0 and Bindings, KVO and KVC were the new hotness. Over subsequent releases we gained Core Data, Objective-C 2.0, NSViewController, Garbage Collection and much more. I strongly believe that any modern Cocoa app should be using Core Data, Objective-C 2.0, Garbage Collection and NSViewController. Bindings should also be used where appropriate (I'll define where I think this is later).

Justin's post included a project he'd worked on, implementing core data tutorial application from CocoaDevCentral using several window and view controllers rather than one monolithic class and nib. The way he built his version was quite interesting, as it was differently to how I would have approached the task. As it was a relatively simple project, I thought it would be of benefit to some to provide an alternate way of building the same app. I don't think there has been two Cocoa developers giving two different ways of implementing an entire app before.

You can download the source for my version here. I also recommend downloading Justin's version. I'll first outline how Justin's implementation works and then go into how my implementation works and how it differs from Justin's.

The Application

But first it would make sense to outline the application. It is a simple blogging app. It consists of a main window containing a splitview. On the left is a list of posts, with an add button below. On the right are the details of the current post: the title, author, category and body. The author and category are chosen from a list which can be edited by clicking the edit button next to the field. This brings up a panel allowing editing of the author and category lists.

The data model is as shown below:

Justin's Implementation

Justin has structured the application as 3 window controllers, 2 view controllers and the app delegate:

• MDVCAppDelegate contains all the code to initialise the Core Data store and the main window controller. It also inserts the initial authors and categories if the database is empty.
  
  
• MDVCMainWindowController is the window controller for the main window. When the window is loaded it initialises the view controllers and adds their views to the splitview, and sets up the frame and autoresizing mask.
  
  Perhaps the most interesting part of the whole implementation is that it uses a single NSArrayController in the main window's NIB, which is then passed to the view controllers when they are initialised. This array controller is in entity mode and bound to the managedObjectContext on the application's delegate. The add button's action is connected to the array controller.
  
  
• MDVCPostsListViewController is a very light weight class. It just handles initialisation and pushes all the handling into the NIB. The table column is bound to the array controller that was passed in at initialisation
  
  
• MDVCPostDetailViewController is almost identical to the posts list view controller, except that it includes methods to show the authors and categories lists. It uses the selection on the passed in array controller to fill in the details. The NIB also contains array controllers for the authors and categories lists, which are bound to the app delegates managed object context.
  
  
• MDVCCategoriesWindowController is just a singleton that sets up the main window. Again, most of the logic is pushed to the NIB with an NSArrayController handling everything.
  
  
• MDVCAuthorsWindowController is identical to the categories window controllers, except that it handles authors
  
  

And that is all there is to Justin's implementation. It is very simple and most of the processing is pushed off to Core Data and NSArrayController.

My Implementation

I built my implementation with the same structure as my 3 existing apps. Rather than relying on core data and bindings completely, I use KVO manually and have a model controller that wraps around core data. I have a similar set up in terms of controllers: 3 window controllers, 2 view controllers and the app delegate. But I also have 9 extra classes, my model controller, 2 classes to simplify core data and 6 model classes generated by MOGenerator.

• M3MasterDetailVC_AppDelegate handles all the window controllers. In this case, all the window controllers are application global. As such I prefer to put the code handling them into the app delegate. You may be wondering how the editAuthors: and editCategories: methods are called, and all will be explained later in the post.
  
  
• M3MainWindowController holds and mangages the view controllers. It initialises the view controllers in its init method and adds them to the split view in awakeFromNib. The two subviews of the splitview are connected to IBOutlets. The code for creating a new post is also in here, as I'm no longer relying on bindings for adding and removing objects.
  
  There is also the first bit of KVO usage. The window controller observes the selectedPost property on the posts list controller. When this changes it sets the post of the details controller to the newly selected post.
  
  
• M3PostsListViewController provides 5 important methods. The first returns an array of posts from the model controller. This is used by the array controller in the NIB as its contentArray. The array controller is this time used in class mode, rather than entity mode, with the contained class set to M3Post. The reload data method tells KVO that the posts array has changed, which causes the array controller to refresh.
  
  The selected post method returns the post object that is currently selected in the array controller, if there is one. Conversely selectPost sets the selected post on the array controller. And finally there is the tableViewSelectionDidChange: delegate method, which informs KVO that the selectedPost changed whenever the table selection changes.
  
  
• M3PostDetailViewController only contains code for observing and returning the list of authors and categories. Most of the logic is in the nib, where an NSObjectController represents the selected post. Other than this the NIB is almost identical to Justin's version
  
  
• M3AuthorsWindowController contains code for listing, adding and deleting authors. The authors are displayed in the UI via an NSArrayController whose content array is set to the authors array. The add and delete actions are connected to the class which calls the model controller and invokes the appropriate KVO methods.
  
  
• M3CategoriesWindowController is identical to the authors window controller, except that it deals with categories
  
  
• M3ModelController is the main difference in the two implementations. It provides a single focus point through which all data creation, deletion and retrieval flows. While this may seem like overkill for this application, where bindings are pervasive, it is a very useful thing to have when you do a lot of work with data that doesn't involve bindings.
  
  The init methods sets up a core data manger and a simple core data instance. It also checks if the database is empty (there are no authors) and if so inserts the initial content. The rest of the methods just deal with returning, creating or deleting objects.
  
  

The following two classes I group together as M3CoreData. They are classes I've built that make CoreData cleaner and simpler to access.

• M3CoreDataManager is where all the CoreData initialisation code that often resides in app delegates is pushed off to. It doesn't do anything special, it just makes life cleaner by pushing all the code you don't care about off into a class and putting the bits you do care about into an initialisation method.
  
  
• M3SimpleCoreData is where I encapsulate the code required to add and retrieve objects with core data. This code is very samey and very tedious and there's no good reason to write it every time.
  
  

And finally there are the 6 classes generated by MOGenerator. I've learned to swear by MOGenerator for my core data applications, it is removes all the hassle that you would otherwise have if you used Xcode's built in tool for generating model classes for core data entities. The only change from the generated code is an awakeFromInsert method in M3Post that sets the creation date.

Responder Chain Hacking

One thing I like to do is abuse the responder chain (please don't call the police!). In larger applications I make sure every view and window controller on screen is in the responder chain. This has the advantage of being able to put methods where they belong, rather than where you can access them. For example, the newPost: method is in the window controller. In some of my apps I have it in the side bar controller, because that is all that cares about adding a post.

You can then connect you actions to the first responder proxy in the NIB. It will traverse the responder chain and find the appropriate class and then invoke the method. You can then control whether the method can be invoked by overriding respondsToSelector, which will give you menu validation control.

This is how the editAuthors: and editCategories: methods in the app delegate are called. The buttons in the details view are connected to these methods via the first responder proxy. As the app delegate is in the responder chain it will be the one receiving the methods (as nothing else futher up the chain implements them).

Where To Use Bindings

Bindings are a contentious issue. Some people love them, some people hate them. The fact is that they are incredibly useful and can save a LOT of code. To give one example, the new inline inspector in CCP 1.4 was initially all handled in code. Unfortunately this required a lot of logic for handling no selection, multiple selections etc. In the end I just replaced the code with bindings to an NSArrayController and managed to delete around 100-150 lines of code.

But bindings aren't useful in all cases. Over the years I've kept changing how I use bindings. I used to use them everywhere, then went through a phase where I didn't use them at all, but have now settled on a good middle ground, where I use them where they work best. So where is that?

• Preferences - bindings are ideal for handling your preferences. Most preferences are just booleans, strings or integers, handled by checkboxes, text fields and popup lists/radio buttons. These can be bound directly to the shared user defaults controller and remove the vast majority of code from your preferences controller.
• Forms - this is sort of a superset of the preferences use case. Anywhere that you have a form for displaying and/or editing data on an object (or especially in cases of multiple selections), you should use bindings. It saves on a huge amount of code and it handles all the issues of editing multiple items at once, populating pop up lists etc
• Simple Tables - I have found that any sort of simple table should be implemented using bindings. By simple I mean ones that don't require any complicated logic in the data source. If you just have an array of objects and you want to display their properties in a table, use bindings, it is much simpler. However, do NOT use bindings for outline views. NSTreeController is evil and should be avoided like the plague. Consider this a public service warning, just avoid it and save yourself a lot of pain.

Use New Tech, It's There For A Reason

There are a lot of people who avoid some of the new technology in Cocoa. Some don't like Core Data because it seems like voodoo (if you learn a little bit more you'll actually find that it is quite simple, yet incredibly powerful) and some dislike Garbage Collection because of experiences with other garbage collectors (in reality the GC in Obj-C not only saves you the pain of memory management but also of threading, while also potentially being faster than a retain/release system).

You should always be looking at the new technology that comes in each release of Cocoa, most of it can save you 100s, if not 1000s of lines of code if you can adopt it. It can also make the code you do have much easier to manage. It seems odd that most people would agree it is insane to write and use an alternative to something like NSTextView, yet will write and use an alternative to some more modern technology in Cocoa.

Just accidentally blew away 16 files' & days' worth of work with hg. Looked up, TIme Machine had just finished. Lost < 1 min. of work.

- @incanus77

That tweet prompted Wolf Rentzsch to write this post about how Time Machine is your version control "safety net". To me both of these are shocking. It seems that the tweeted mishap may have been user error, but it made me look into how the various user interfaces help protect the user.

Your VCS should protect you

For a long while I was opposed to VCSs, mostly due to faffing around with subversion and getting nowhere. With DVCSs I've become an addict. The issue is that DVCSs also try to be clever. Their primary goal is to protect you from yourself, to make sure your code and its history are safe. Essentially your commit history should be like a stack. 99% of the time you push onto the stack, rarely you need to pop off a stack. You can read the contents of the stack as you want. But you shouldn't be able to modify the internals of the stack.

This is why I consider the many rebase plugins/commands in DVCSs to be harmful. I feel that rebase should be viewed as a mixture of goto, premature optimisation and Jeremy Kyle all rolled into one ie don't touch it unless you know what you're doing and are wearing many layers of protection, and even then it probably isn't such a good idea. Some people swear by rebase, but I feel that you shouldn't be messing with what should be treated as sacred.

Your repository is not a toy, so stop playing with it.

Protecting against destructive actions

This is where we get onto UI. I've never really given much thought to command line UIs, but comparing git, Mercurial and Bazaar I've found subtle differences in the UI that make it harder or easier for a user to perform a destructive action. These really fall into 3 categories: confirmations, making it hard to destroy and separating destructive actions.

In the case of the tweet at the start, I looked into the command that was performed: hg update -C . It offers no confirmation dialogue, it just cleans out the items that have changed. It doesn't make it hard to destroy changes and it is a one character option which means it is easy to do. I'm not sure about git but the equivalent in Bazaar would be bzr revert --no-backup. Of course there's no real reason to run --no-backup, it helps save your arse just in case and cleaning it up is just a case of bzr clean-tree --detritus (which lists the files to be deleted and asks for a confirmation).

One of the other examples is from the blog post. git branch -d abranch will delete the branch called abranch. Now to me this seems incredibly dangerous as there isn't any confirmation given. Occasionally I've seen warnings to use the uppercase -D option if changes aren't merged into the parent, but sometimes even those may not appear. If you're doing something like deleting a branch then it should be made harder to do. Really it should be git branch --delete-branch abranch and then ask you to confirm the delete.

Destructive actions should really be moved out into other commands if possible. bzr has 2 such commands: uncommit and clean-tree. Uncommit and clean-tree both list the items that will be removed and ask you to confirm. This makes the user double check what they're doing to confirm what they are doing. Now these commands could be moved into other commands. Uncommit could be made into bzr commit -d, but by separating them out you are making the user think that this is a different thing and making it harder for them.

The hypocrisy of UI design

It does seem very hypocritical, when most of UI design is a push to make life easier for a user, to advocate making it harder. But as odd as it may seem, making something harder may make it more usable. Now by harder I don't mean make a series of convoluted steps that require an animal sacrifice. I mean add an extra step to any potentially dangerous action. Tell the user exactly what the result of the action will be and ask them to confirm it.

Obviously you should provide undo when possible, but sometimes it isn't. Think about where in your UI you place these actions and consider whether you need them there at all. Don't put a 'wipe library' button right next to one of the most commonly used buttons in your UI, and no matter where you put it, if you can't offer an undo then tell the user exactly what you will do and make them confirm. Force them to pay attention to what they are doing. They'll thank you for it, even if it is just by not complaining to you (or worse to the internet) about how your software lost their data without warning.

Delegates are preferable to Notifications which are preferable to KVO

Now this caused a bit of a murmur on Twitter, as it was taken as "KVO is bad". As this is an important topic and not one that can easily fit into 140 characters I thought I would write a post to outline my rules for when to use each technology and why use them where I do.

Rule #1: Always use delegates for 1 to 1 relationships

One of the main reasons delegates were listed as the most preferable is that they provide the least 'magic' way of communicating between objects while keeping them loosely coupled. It sends the message directly to the object and you can see what method is being run. As such it makes your code more self explanatory. So whenever you have a 1 to 1 relationship between two classes, opt for delegation over notification.

Rule #2: Use notifications for communicating events to many objects

Notifications should really be used wherever you would use a delegate, but need to communicate with any number of objects. They should really be thought of as 1 to many delegates. Quite often in Cocoa you will see a case where there is a notification and a delegate method for the same event (eg change of selection in a table view). These are cases where 80% of the time you just need a 1 to 1 relationship, but occasionally do need a 1 to many relationship. You will rarely encounter this in your own code, unless you are building a class for use in multiple apps.

Rule #3: Use KVO for communicating data model changes

This is where I have found KVO to be the most powerful. You need to keep various UI elements in sync with your data model. Changing the value of the model from one view should also update the value in other views. KVO was built for exactly this situation and as such requires much less code than delegation and notifications.

To achieve the same effect with delegation or notifications you would have to add delegate methods or post a notification in each setter method of each model object. This obviously is a lot of code that needs to be written. Code that could have bugs and code that makes your source more cluttered. KVO of a value in an object requires just one line of code and the implementation of one method. And if you use bindings then it is actually no code at all.

Rule #4: Use blocks instead of callback delegates

I'll start with the exception to this: if you have multiple callback options then use delegates (eg NSURLConnection). But the vast majority of asynchronous operations need just a single callback. In these cases, if you are using Mac OS X 10.6, then you should be using blocks instead of delegates. Blocks reduce the layer of indirection in your source by putting the call back information inline with the invocation of the method.

The next two rules aren't quite rules of communication, but are relevant to the discussion at hand.

Rule #5: Comment anything that isn't clear

This should be pretty obvious. If something in your code isn't explicitly clear from the code itself then comment it. If you are sending off a notification say why you are sending it off, so you can get an idea of what it is doing elsewhere in the application.

Rule #6: If something seems like magic, learn how it works

There is no such thing as magic in programming, simply things we don't fully understand. If notifications, delegation, KVO or anything else seems like magic, then read up the documentation on it or ask a developer experienced in that area to explain how it works. When you find out how they work you realise that what seems like magic is fundamentally a very simple process.

Ultimately, what Dave said was right for some scenarios. Each technology has its use case and you should only use it where it is needed. You should always aim for the smallest amount of indirection in your code while still retaining loose coupling of classes. KVO and notifications are necessary in some occasions (unless you want to go crazy with delegation) but they should only be used when they are needed.

Who is the iPad for?

The iPad is for casual computing. It is what many people said the iPhone would be for, before realising that the small screen isn't all that good for casual computing. The iPad really is a remarkable device, showing off the technology combination the iPhone introduced us to in a much better way.

But who is it for? Well it is for everyone. Some people are saying it is for their parents and that it isn't for geeks or professionals. I disagree. Yes it is ideal for those who don't want to learn how to use a computer, but that doesn't mean that it won't also be great for the computer literate. Hell, look at the popularity of the iPhone, that isn't just computer illiterate users. But just because it will work well for everyone, doesn't mean it will work well for every task.

What is its place?

Apple explicitly said that the iPad sits between the iPhone and the Mac. They have specced it out in that range, are marketing it in that range and priced it in that range. It sits in the middle ground, which is exactly the same place that many low end PCs sit. The exact sort of PCs that are bought for workers, schools or just by people who want a computer to get online but don't need anything powerful.

Think of all the people who have to travel around with bulky laptops just to fill out some forms when they see customers. The iPad is a much more portable way of providing that same functionality, for what would be a reasonably similar price.

In education the iPad would be invaluable. With the iBooks system, iTunes U, iWork all on this one lightweight device which costs only a bit more than a low powered laptop, it is the perfect education tool. It becomes the textbook, the educational video and the work machine all in one. With the ability to type but also sketch with your finger it could replace pen and paper for note taking for many people.

And finally think of the casual user. You don't need a bulky computer system any more, you can buy a sleek iPad that you can easily store in a drawer when you don't need it. It is powerful enough for everything a casual user could want, and then some. There is also something else significant I will get to in a bit.

Isn't it just a big iPhone?

From a technical point of view it pretty much is just a big iPhone. Sure it is faster and has different UIs on the apps, but it is running the same fundamental core. But it is very easy to underestimate how important the bigger screen is. There are many applications that work ok on the iPhone but would work so much better on an iPad

In the keynote video the developer of Brushes was brought on stage to show off the app. The extra screen space allows a much bigger canvas with more powerful tools. The iPhone lets you build a toy paint app, the iPad lets you build a real paint app.

The iPhone also doesn't really work for things such as office applications. Pages, Keynote, Numbers. Sure you could do them on the iPhone, but they wouldn't provide a good experience. The iPad offers a screen resolution that allows you to make these sorts of applications possible.

The other key thing is that there are some app concepts that work well on the iPhone but not on the Mac. There are also some that work well on the Mac but not on the iPhone. On the iPad the majority of these concepts from Mac and iPhone work equally well. You can build desktop calibre apps for the iPad, which you couldn't for the small screen of the iPhone.

Surely this means the Mac is dead?

The iPad replacing the Mac is as likely as it replacing the iPhone. The iPad is a 1GHz device with up to 64GB of storage and a 9.5" screen supporting a 1024x768 resolution. For casual computing that is fine. But for high performance tasks? No. For shared media system? No. For doing work that requires very large amounts of screen real estate? No.

For the iPad to replace the iMac for example it would need to have a 27" screen with 2560x1440 resolution, a 2.6GHz quad core processor and 1TB of storage. The fact is that such a machine would be both hugely expensive and incredibly impractical.

In the same way that an average laptop is always less powerful than an average desktop at any period in time, the iPad will always be less powerful than an average laptop. It is basic economics and physics. New high powered processors produce more heat and so need more cooling, over time processors of equivalent power will be made more efficient and smaller. The iPad is 1GHz, Macs reached 1GHz 8 years ago.

The iPad is also a much more personal device. I wouldn't expect to see many groups of people gathering round an iPad to watch a movie. The Mac provides a much better group media system due to the bigger screen size. Throw in the fact that you can add a remote and front row to the Mac and you have a home entertainment system, which the iPad is not.

So why not just chop the keyboard off a MacBook?

Some people wanted a touch screen Mac with no keyboard or mouse. Such a product would fail miserably. This is essentially what a Windows Tablet/Slate/Whatever-they're-calling-them-this-week is. It is a laptop with the keyboard chopped off. And they provide a terrible experience. Not because of the hardware, but because they're running Windows.

Now that isn't to take a jab at Windows. The issue is that Window is a desktop OS. It has been designed for use with keyboard and mouse and doesn't work too well with a touch screen. Like OS X it has some multi touch functionality hacked on, but you are still moving a mouse cursor about and clicking on a 1px point.

A user interface for a touch screen where the primary input method is your finger requires a hugely different user interface. You can't have a 1 pixel line you have to touch and drag as you do with split views. You need to fundamentally change how controls behave as they need larger target areas.

Many parts of a desktop OS are irrelevant as well. Scrollbars aren't needed on a touch screen. They would take up valuable screen space that can otherwise be done by stroking your finger along the screen. Scroll areas are also inverted. Drag a scroll bar down on a desktop and the page moves down, drag your finger down on an iPhone and the page moves up. This is because you no longer have the disconnect between screen and input device.

What about multi tasking?

There have been two large groups of people talking about multi tasking. Those who want it and those who think that casual users won't use it. Both groups are right and wrong. The iPad needs multi tasking, but it doesn't necessarily need to mean multiple apps running at once.

For those who don't think it is needed, I would ask whether you multi task in real life? Yes you do. Off the computer you listen to music while you work. On a computer you flip back and forth between a web page and a word processing document. You do multi task.

What you don't do is use 20+ applications all at once. Sure I have over 20 applications open but I don't use them all. As I'm writing this blog post I'm listening to music while flipping between typing up and researching on the web, with the occasional glance at twitter. Now on the iPad I could just exit to the home screen from Pages and open Safari, find what I want then copy and paste back into Pages. Then if I want to change my music I open up the iPod app and change it there.

The issue is that I am multi tasking whether the iPad allows me or not, but I'm having to go through the awkward process of quitting an app, opening another app, quitting that, opening the previous app. There needs to be a limited ability to switch quickly between a certain set of apps.

One way I have thought of is to use a 4 finger swipe. It would work much like 4 finger swiping on a MacBook Pro trackpad. Swipe horizontally and be presented a list of 'open' apps under your finger which you can choose from. Swipe vertically would bring up the home screen to open a new app. This makes the process much faster.

The best thing about this is that it can still be quitting the applications. I'm just not having to move my finger down to the bottom to press the home button, then back up to where I was on the screen to find the app I want (which may or may not be on a different page of apps). It removes the unnecessary movements of the hand as your switching appears under your finger and also reduces any sort of searching your brain has to do as what you want is in a line of a few choices.

Significance of the 3G networking?

What hasn't been talked about is the significance of the 3G networking deal. This is truly a revolution. No contract, you can sign up and cancel any time you want and it is a low monthly fee. If you only want the one device then this is the easiest way in the world to get on the internet in your own home. No installing filters and routers and modems. No phoning up an ISP to get them to connect you up in the next few weeks.

Sure it isn't the fastest internet, but it is fast enough for most basic uses. This is getting online the Apple way, except unlike the iMac adverts of the late 90s, there really is no step 3.

Final thoughts

The iPad truly is a revolutionary device to those who can see its potential. To those who can't it is just an expensive, large iPhone. At the same time, it won't replace the Mac or the iPhone, it just isn't in the same market as either of them. It does have a few flaws at the moment but these are easily fixed. What is important is that this is a glimpse of one of the future forms of mainstream computing.

Having a day job and then coming home and working nights and weekends leads to a person being worn out very quickly. A lot of our design work was being delayed due to Fabio not having the time or energy to do work and this was also filtering down into design for our products. Minim 2.0 was originally planned for a late november release, but delays in design related stuff meant it kept being pushed back.

The delays meant that the money coming in from design wasn't really worth the effort, and I was unable to help as I'm not exactly icon designer material. This has meant we have had to make the decision to stop offering graphic design services. While we were able to deliver what we hope was high quality products, circumstances meant we weren't able to offer high quality service. It is better to not do a job at all than do a bad job.

While we are stopping our graphic design services, we are introducing two new design services where we can offer a high quality of service as they are areas of design I am able to handle myself: Usability and Accessibility.

There are many services available to Mac and iPhone developers for graphic design. A quick google search will bring up pages of people offering icon or UI design services. But there are very few services that focus purely on usability and none that I have seen that focus on accessibility.

So what will our usability and accessibility design services entail?

Usability

Well in a nutshell, you give us your app and we will pick through the user interface and point out any areas where usability could be improved. We will explain why things are in need of improvement and what items are urgent.

Of course, there are different degrees of usability. You can make any user interface usable, in the sense of doing what the user expects, by following a series of rules. But usability can also be about how a user feels when using your application. Is it just functional or is it enjoyable? Our usability reviews will provide suggestions for areas where your user interface can be re-thought to make it highly enjoyable as well as functional, turning a user who is merely happy with their purchase into one who raves about your app to their friends and co-workers.

Accessibility

Our accessibility reviews will work in much the same way. We will go through your application and highlight areas where accessibility is lacking and give you details on how to fix them. But we are also going to do something a bit crazy. We will also show you how to find and detect the majority of accessibility problems yourself.

"But surely that is what we're paying you for? What is the point of us coming to you if you're just going to tell us how to do this work for free?". Very good questions. The fact is that 90% of all accessibility work is trivial. While I certainly am not opposed to you giving us your money, I believe that it is ultimately a waste of your money and of our time to keep coming to us for help with trivial matters.

What you may need help designing is the non trivial matters. How do you make a custom control accessible and what should the interaction model be for disabled users? What is the flow of my application like for disabled users? In a way, if our usability design is aimed at abled users of your software, our accessibility design is the exact same thing but for disabled users.

Getting an estimate

So how do you procure our services? Send us an email with details of your needs to design@mcubedsw.com and we will get back to you with an estimate of how long we think it will take. We charge an hourly rate so this will give you a good idea of how much you can expect to pay. So get in touch and start getting feedback on the accessibility and usability of your apps today!

When I started work on Code Collector Pro 1.4 over the weekend I was confronted by the issue of whether to go big or small on two key points: the size of updates I release and the size of the classes I write. These are key decisions that affect all the software we write, so it is worth deliberating over them. Now these aren't questions I've only just asked, they are ones I've looked at continuously and am only just starting to set myself on.

Release sizes

There are two extremes to software release size. At the large end of the scale are products like Adobe Creative Suite, Microsoft Office and Apple's iWork and iLife suites. They have a release roughly every 1-3 years and they feature large updates to several applications. At the smaller end of the scale are products like WebKit or Adium, where small releases are made every day in the form of nightly builds.

Most Mac devs go for the middle ground of this, releasing several medium sized updates a year, though what constitutes a "medium sized" update varies widely. I've been striving to reach the smaller end of the scale with little success until now. The combination of full time education limiting coding time, and a lack of discipline when building releases has led to a series of sporadic releases that are quite large.

With Code Collector Pro 1.4 there was a long list of features building up. There hasn't been a release for 14 months and the featured planned involved would take a good 3-4 months to complete. The release eventually included a UI overhaul, new sharing features, syncing and a re-written syntax highlighting engine.

So I opted to break it up into smaller releases. The UI overhaul is a collection of many small changes and some under the hood changes and nicely separates into a different release. Sharing improvements and syncing were the two major features I wanted for 1.4, so these would fit nicely into a second release. And the syntax highlighting improvements would also fit nicely into a small release. As such the large 1.4 now became much smaller versions 1.4, 1.5 and 1.6.

The current plan is to work on 1.5 straight after releasing 1.4. But why not then combine them? Well there are 3 main reasons not to:

• Syncing and sharing will take 1-2 months to implement, but the UI improvements can be done in a few weeks. As they are the low hanging fruit I would most likely do them first. So why have those improvement sitting around on my computer for a few months when I could ship them to users?
• Smaller releases often lead to a better feeling of productivity. You do have more time taken up by prepping for release, but you feel like you are getting somewhere much faster. It's easier to climb up a set of stairs than a cliff face.
• Releases = money. Whenever you make a release people see it on download sites and news sites. This leads to people downloading the app and then ultimately buying it. The more people buying your software the more people spreading word of mouth advertising and the more sales you get. Ultimately each release is an extra boost of energy into a positive cycle.

Class Size

For those of you who aren't programmers a brief explanation. A class is a unit of code. It contains data and actions upon that data. While not always true, generally a class = a separate file of code. As with release sizes you can either have a few large classes or lot of small classes. Cocoa provides ways to help you divide your code up. Code relating to windows goes into Window Controller classes, code relating to any documents goes into your Document class.

Prior to OS X 10.5 there was a missing piece of the puzzle though. While you could easily split up your application into windows, it was harder to split up these windows into individual views. Then in 10.5 Apple introduced NSViewController, which made this task easy. This means you can split your UI up into even small classes, which leads to easier to maintain code and more reusable code.

As an example, these are the window and view controllers that make up a typical screen in Minim:

As you can see, this one screen has 4 main components. The window, which contains a sidebar and an info panel, the latter of which contains the current tab. Each of these is coded in a separate file. This means that if I need to edit something to do with the sidebar I open the sidebar view controller's file. It also makes things more re-usable. There is a file that contains the file manager view controller class. This same class is used for songs, podcasts, albums and shows.

Now Minim is build with Leopard in mind. Code Collector Pro however is very much a Tiger era application in its design. This is what Code Collector Pro's main window looks like from a class point of view:

There is one class that manages the window, the sidebar, the snippets list and the code view. It even controls the inspector panel. At 2420 lines long it is the second biggest class in any M Cubed app, beaten only by the class that talks to Lighthouse in Lighthouse Keeper. That over 3 times the size of the biggest class in Minim.

Now while a large class isn't necessarily a bad thing, a large class that does lots of different things is. If I want to edit something to do with the sidebar in CCP I've got to search through 2400 lines of code to find what lines are relevant, compared to Minim where I open a file where all the lines are relevant.

I'm currently working through the process of breaking up this monolithic class into much smaller, more manageable chunks. I've already managed to split it into 7 classes, I may be able to divide those even further. Ultimately though, this will add nothing new to the application. It will work exactly the same as it did before. What it does do is make it easier to add new stuff in the future.

It's How You Use It

So does size matter? Well as the title of the post suggests, it does. But what is a good size depends on many things. To quote Albert Einstein, "Everything should be made as simple as possible, but not one bit simpler". You should strive to make things as small as you can, but not unnecessarily. While I can break one large class up quite easily, another may not break up. It may be the case that it is already as small as it needs to be.

The same goes for releases. I can split up what was going to be CCP 1.4 into 3 different versions quite easily, they logically split up. However, Minim 2.0 couldn't have been split up. It was a large project, but it couldn't have been made any smaller. Everything has its size, the job of anyone creating something, be it a piece of code, a product or a business, is to find the right size.

It now requires Mac OS X 10.5.8 or higher to run (previously it only required 10.4 or higher) and now costs €25 (around $36). You can find out more about it at minimapp.com

From 1.0 to 2.0

Minim 1.0 was released over 3 years ago in November 2006. Since then it received just 2 updates, version 1.1 and 1.2. It suffered right from the start from my inexperience, not only at coding, but at creating a product that can sell. Since then I've released 2 successful products and become a much better developer.

So when it came to working on Minim 2.0, it made sense to treat it as an entirely new product. I used the experienced I'd gained over the past 3 years and re-designed and re-coded it from the ground up. I added some new features that weren't in 1.x and took several features out that weren't particularly useful. I made sure to justify everything that went into the app, rather than just saying "Well that would be cool" as I did with 1.x.

It is also the first app I've worked on that had designers heavily working on it. This has been an interesting experience, as it involved doing a lot more custom UI elements than any other app. It also meant the release schedule wasn't just in my hands as well.

The result is what is quite easily the best application I have created to date. It is a sign of things to come from future versions of Code Collector Pro and Lighthouse Keeper, as I'll be able to give them the attention of a full time developer.

Accessibility

Last year I made a pledge about accessibility, that I was unfortunately unable to fulfil. Lighthouse Keeper and Code Collector Pro are 90% accessible but not the 100% I was aiming for. But Minim represents an important step in the direction of making all M Cubed's applications fully accessible. It has been extensively tested and features several unique features that mean it provides as good an experience to disabled users as to fully abled users.

The lessons I have learned from making Minim 2.0 fully accessible will be invaluable to making Code Collector Pro and Lighthouse Keeper reach that goal as well. I'm hoping that by the summer I will finally be able to say that all of M Cubed's apps are fully accessible.

Open Source

Over the next week I will be releasing various open source components, as well as improvements to existing ones. All of this code comes straight from Minim. I will also be sharing a lot of the lessons I've learnt while developing Minim, so keep an eye on the blog as I get into the nitty gritty of the redesign, responder chain hacking and a detailed look at the drawing code behind the recording view.

Finishing University

The bulk of the last year was taken up with finishing my degree. This is the primary reason that you haven't seen much activity from M Cubed the past 12 months. Exams, assignments and my dissertation all took up the majority of the free time I had.

Unfortunately both getting a degree and running a software company require a lot of mental input and it's hard to do both at once. Effectively M Cubed was shut down for several months while I focused on my degree.

In mid June I had my last exam, all my assignments and my dissertation were handed in and I was finally free of full time education. In July I went back to pick up my degree at my graduation ceremony and now I the £20,000 piece of paper that says I am a Computer Science BSc. So with all of that out of the way I could finally focus all my energy on M Cubed.

Going full time

Last year I said that I hoped to be working full time from M Cubed. This year I can say that I am now a full time indie developer. Granted this is helped in part by the fact that I've been able to move back home with my parents and that I'm able to keep my expenses down. Many people wouldn't be able to live off what I'm earning, but it is enough for me to dedicate all my energy to it.

The biggest benefit of going full time has actually been having free time. Previously I would fill my free time with M Cubed work, but when combined with school/university work this would lead to me getting burnt out pretty quickly. Being able to focus most of my attention on M Cubed, I can now use my free time for things that are actually relaxing. I'm no longer having to stay up until 2am coding, I can get offline at 10pm and spend the rest of the night relaxing. I can't emphasises enough how much doing this has increased my productivity.

2 > 1

Going full time wasn't the only major thing that happened with M Cubed this year. As was announced in July, M Cubed's employee list doubled. Fabio joined to help with design and coding. The result is the website design you see now, plus many graphic improvements to our applications that you don't see yet. In fact you'll see the first fruits of our labour next week when we release Minim 2.0

Minim 2.0

Minim 2.0 is going to be the first release from M Cubed since I went full time. Minim has long suffered from a lack of focus and development time. The last release was 18 months ago and only fixed 1 small bug. The last major release was over 2 years ago.

Version 2.0 changes all of that. It has been completely re-designed and re-coded from the ground up. It is practically an entirely new application, the name and the core purpose of the software being the only things shared with 1.x. Whereas Minim 1.x was only the second real application I had written, Minim 2.0 builds on 5 years of experience, meaning I can say with confidence that it will be the best application we've ever shipped.

It really is a shining example of what the changes this year hold for the future. Every release I've done in the past has been limited by the amount of time I've had and has had me as the primary designer. Minim 2.0 has had several people working on the design and we've been able to put a lot of time and effort into polishing it. Whereas before the question was, "how can this feature be added in the shorted amount of time?", the question is now, "how can we best implement this feature?"

Accessibility

The other thing that Minim 2.0 will showcase is accessibility. Earlier this year I made a pledge: "By the end of 2009, every application I produce will be fully accessible". Unfortunately I won't be able to fulfil that pledge by the end of 2009. However, the next major version of each application will fulfil the pledge of making every application I produce fully accessible.

Minim 2.0 does fulfil that pledge by being the first M Cubed app to be fully accessible. We've put a lot of effort into achieving this and we hope it will help in providing a first class experience for disabled users.

Code Collector Pro is mostly accessible but needs the most work and this will be fixed in version 1.4 which we hope to have out early next year. Lighthouse Keeper only has some minor accessibility issues but these will be fixed in version 1.2.

To further highlight our emphasis on accessibility, we are setting up a new email address where you can contact us about any accessibility related issues with our software. If you have any questions about our the accessibility of any of our products then send us an email at accessibility@mcubedsw.com

The year ahead

Well the next year will see a lot more activity from us. As I've already pointed out, our next 3 releases will be Minim 2.0, Code Collector 1.4 and Lighthouse Keeper 1.2. We also have plans for a major revamp of codecollector.net, which has been feeling a bit neglected. We'll also be looking into dipping our toes into the pool of iPhone development. And to top all of this off we have a number of open source projects we will be working on. All in all, the next year will probably be the most productive one in M Cubed's history. Hopefully the post a year from now will tell you about all these great projects as M Cubed celebrates a half-decade of existence.

Now in my usual post on this topic I pull the web idealists from their pedestals and inform them the web will never replace the desktop, and smack desktop idealists around the head and tell them they can't expect their apps to live on an island any more. The conclusion is always the same: the real power is in the internet, the web and the desktop are just two different ways of providing an interface to it, each with pros and cons.

However, what made me crack and write this post is another post by one of the aforementioned web idealists. So this post will instead be rebutting his post with a vengeance. The author is Peter-Paul Koch and the post can be found here: http://www.quirksmode.org/blog/archives/2009/11/apple_is_not_ev.html

Stupidity

So any post where the title calls a group of developers 'stupid' obviously is going to be full of bias and errors, so let's go through them.

It also supports JavaScript geolocation, which is (I hope) only the first step towards true device APIs that will give JavaScript developers access to phone functionality such as the camera, text messaging, the address book, and more. I’m assuming Apple is working on all that because it’s the next logical step.

That is a very poor assumption for one very important reason. Most people don't want to have their address book read in and text messages sent (at their expense) to all their contacts asking them to visit a website, after they themself visited that website. There's a very good reason websites don't get access to system APIs and this is it.

Safari’s support of appcache makes it possible to store the Web app’s core files on the iPhone itself, so that it only has to download the data. Thus mobile connection problems can be avoided.

But then you need a cache of the data stored locally and the ability to modify the data locally, meaning your web app needs to be run locally. What we have there is a mobile app built with web technology.

Best of all, if you want to update a Web app, you just put the updates on your Web server. There’s no need to wait for Apple’s broken approval process. iPhone developers are stupid because they’re wilfully ignoring all this.

This may be veering off slightly, but 90% of the issues with the App Store process are due to the length of time. If you got a response within 24 hours of submission and you could get a speedy response when you appeal then most of the issues would go away. So yes a web app fixes that by allowing you to update on your server.

However, you then have to pay for that server. Many web developers forget two key things about desktop/mobile development:

1. Scalability isn't an issue as you gain more processing power with each user, on the web you reduce the processing power each users gets with each new user.
2. You aren't having to also pay for the computer the application will run on, nor the resources it will use.

These two facts lead to one highly important factor for a lot of desktop/mobile developers: your expenses are lower.

Now this isn't saying that you should therefore never make a web app. Web apps are needed in many cases, but they aren't the be all and end all.

More Stupidity

Still, the graphically simple games such as sudoku and chess, the interactive shopping lists, the dictionaries and bible citation apps, the beer appreciation apps, the firmware Yahoo weather app, and most importantly all social network clients could have been written as a Web app without any loss of quality whatsoever. (Most have fairly little quality to lose in any case.)

This I have to strongly disagree with. If the web provided an equal user experience to the desktop then why do desktop clients exist? Why do people buy Lighthouse Keeper when they could use Lighthouse? Why am I writing this in MarsEdit instead of my blog's admin panel? Why are most of the tweets I see proclaiming "the end of the desktop/mobile" posted from desktop/mobile Twitter clients and not the web UI? The fact is that the web is a LONG way off matching the user experience that can be delivered on the desktop/mobile

In addition to avoiding the App Store and its insane policies, such Web apps would (mostly) work in any modern browser, whether desktop or mobile, and users of other phones or even of old-fashioned desktop computers could have used them, too.

Oh dear. The issue with this argument is that you have to build to the lowest common denominator. Sure you can have your site gracefully scale back. This blog you're reading will have a drop shadow around it and rounded corners. Of course in other browsers in may not have these. The issue is that Peter wants to have it both ways, but he can't.

You can't on the one hand laud the advanced features of Webkit in Safari (Webkit in other browsers can vary widely) while on the other hand say that your apps will work in any browser. People talk about the web as being the platform, but really the platform are the rendering engines such as Webkit (Safari, Chrome, WebOS), Gecko (Firefox, Camino) and Trident (IE), and they all just happen to support the same languages for some stuff (which is no different to Windows, OS X and Linux all supporting C).

Developers like their stuff to reach as many people as possible, right? That makes sense from both a business and an ego perspective, right? Then why do iPhone developers jump through burning hoops as nasty as the App Store approval process just to make sure that their stuff can only be used on one single platform instead of many?

That depends. Can I offer the best user experience while supporting these multiple platforms? Building a general web app that will run well in any browser is much like building a desktop app using Java, it often leads to an inferior user experience as you can't provide a consistent feature set and use advanced features of each OS it runs on. Personally I'd rather develop for one platform and build a kick ass application than develop for a wide audience on multiple platforms and build a mediocre application.

The Web

The plan failed. Jobs Himself ordered His developers to create Web applications with Web standards, but a deafening silence ensued. Then He hurriedly thought up the App Store. Too hurriedly, as it now turns out.

It's far-fetched to believe that Apple only thought up the App Store after they saw the reaction to the announcement of making web apps for the iPhone. The amount of time to build the APIs, the developer tools, the infrastructure, work out the marketing and the legal issues probably means they'd been planning this since before the first iPhone was released.

The "build web apps" announcement felt more like a stop gap measure. More a case of "stop hounding us about developing for the iPhone, if you really MUST develop for it right now then we've added a few small things to make it easier to build a web app for it".

I remember the ecstatic reaction to the announcement, because it was the very first time a major industry leader mentioned Web standards in a major presentation.

Oddly, I remember the reaction being more along the lines of "WTF?", but this goes to show the different reaction of the two communities.

Besides, Apple does not reach out to Web developers at all, and Web developers respond by not bothering with Apple beyond making sure their Web sites work in Safari.

So the fact that Webkit is probably the most open part of Apple means nothing?

I believe that Apple is working towards its own heavily CSS-centric Web OS, certainly for mobile, possibly also for the desktop, and that this evolution has been slowed down by the energy devoted to the App Store as well as the complete lack of outreach.

And I believe that they're also working on an iPony and odd as it may seem, I think that the iPony is more likely. The reason is that desktop tech has many advantages over web tech, the primary one being that it is much richer in both APIs and toolsets.

Arrogance

The fundamental problem on the iPhone is not Apple’s App Store approval policies, but the iPhone developers’ arrogant disdain for Web technologies. That’s nothing new. Most X developers (for any non-Web value of X) live in mortal fear of the browser as a development platform.

What we see here is what Peter and many other web idealists believe: that web technology is the best tool for every job. The fact is that it isn't. The only people who live in mortal fear of the browser are those who get caught up in the idea that web technology is somehow the holy grail of software development.

After ten years I am fucking tired of the “Web development is not real programming” bullshit that the arrogant bastards in “real programming” are spouting because they’re too frightened to learn something new. Fuck those condescending, ignorant, self-important, stupid, blind, fearful pricks. Fuck them real hard. Where it hurts.

As someone who has done both web and desktop development, I can see where the "web development is not real programming" idea comes from. The APIs and tools for writing, debugging and testing web technologies are a long way behind the tools for desktops. Those technologies that have the most advanced tools are ones that many web idealists deplore, such as Silverlight and Flash. It is very much real programming, it is just programming with a relatively young set of tools and APIs.

As for the arrogance that Peter talks about, any amount of arrogance on the part of desktop developers over web technologies is matched by the arrogance of web developers over desktop technologies. For every "web dev isn't real programming" quip there is a "the desktop is dead" remark. It's an eternal pissing match over who has the best lego set, completely missing the point that you can usually build something much better using the best pieces of both lego sets.

The myth

The poor, oppressed iPhone developer suffering under Apple’s heavy App Store hand is a myth invented by these developers themselves because they’re too fearful to look beyond their “native” fetish. The Web is patiently waiting in the wings like a spurned bride, quietly promising to solve all of their problems for them if they’d only look at her.

If the web really was some magical beast that would produce money from nowhere, cure cancer and give everyone a blowjob then that might be the case. But the thing is that web brings with it a whole new set of problems and doesn't really fix the most important one, which is how to build the best application possible. The web is a screwdriver to the desktop's hammer. They're both tools and if you're building a great house you'll need both.

The last heading

OK so the rebuttal is done. But it is worth reiterating for both sides of the argument: I don't believe the desktop or the web is the one true platform. The one true platform is the internet. The future isn't web apps or desktop apps or mobile apps, but all 3 that can work together. Web apps are best for when you're away from your normal computer and just need to check up on something. Desktop and mobile apps are best for providing a rich user experience and raw speed.

Everyone agrees that most of the processing needs to take place on the client, this is why most of the new web technology seems to focus on getting web apps "off" the web. This is simply going the other direction to desktop apps, where they are getting connected to the internet.

It is best to use each platform to their advantages. This is why I have Code Collector Pro, which focuses on organisation and using code snippets, as a desktop app but I have codecollector.net, which focuses on sharing, as a website. It wouldn't work anywhere near as well the other way around because they would both be playing the weaknesses, not the strengths of their platforms.

And this is why it is a pointless war. Neither side will win because the major strength of one side is the fundamental weakness of the other. They aren't at odds with one another, they complement one another perfectly. And when the idealists on both sides of the spectrum wake up to this we'll be able to stop the bickering and start making some great apps. And I'll be able to get through a full year without the urge to write another one of these bloody blog posts on the topic!

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.

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 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.

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.

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.

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.