Five Things Apple Could Help Developers With

by Fraser Speirs

Cocoa gives a developer tons of things for free. From great support for international scripts throughout the text system to a consistent toolbar component, from a full data persistence layer to sharp graphics capabilities, there's lots to play with.

That said, there are a few things that developers commonly do, or are increasingly going to be doing, where Apple could provide us with a little more help.

Preference Windows

There seems to be a consensus forming in Mac OS X application design. The design of an application's preferences are commonly laid out by using an NSToolbar as a kind of quasi-tab-view where selecting one toolbar item switches the view displayed in the body of the window. Many examples cme come to mind: iTunes, Safari, NetNewsWire, Mail, OmniOutliner, VoodooPad and many others all adopt this approach.

Problem is, every developer has to re-implement the technique by themselves or use some third-party code. Whilst there's nothing wrong with reusing third-party code, it would be nice to have the platform developer adopt support for such a commonly re-implemented piece of UI.

Apple already has an architecture for plug-in preference panes inside the System Preferences application. It may not be directly reusable, but a similar approach should be quite feasible.

Predicate Editors

What's a predicate? It's the logical statement you construct in Mail's rules when you say "if Sender contains '', move to folder 'BossMail'". In the past, this kind of task was only encountered by developers of sophisticated applications which had a need to do filtering or matching on their data. Mail clients have been the canonical example for years.

However, with the advent of Spotlight in Tiger, more and more developers will be writing "smart" versions of the structures inside their applications: Smart Folders, Smart Mailboxes, Smart Albums, Smart Playlists and so on. If Apple were able to step up and provide a customisable set of components for constructing these predicate editors it would firstly save developers a lot of effort but, perhaps more importantly, would lead to greater commonality across the platform.

A Font Preference Selector Widget

Lots of applications need to store a user's preferred font. Practically every application in which a user edits text or views it requires at least one place in their preferences where the user can set a font. I'm not referring to the Font Palette itself here - that already exists and is usable - but rather to the combination of label, noneditable text field and "Set Font" button that you see in many applications. Examples abound in Safari's "Appearance" preferences, Mail's "Viewing" preferences, and many others.

Again, it's not a huge or difficult thing to implement but it's a very common thing to implement and providing common things is what having a platform is all about.

iLife Media Browser

Moving away from raw UI components now, I'd like to see Apple break the iLife media browser out of the iWork suite and make it a public framework for all developers to use. Dan wood beat me to mentioning this, but I'll certainly second his call.

In a broader view, "everything they introduce, when they introduce it"

It frustrates me in general to see many independent developers running hard to follow Apple's latest UI conventions. From Tiger's "glossy" look to the little widgets here and there that appear in the latest applications, it just feels like a grand waste of global effort. If Apple would integrate and support these things in the OS when they release them, developers could just use them and not have to reimplement them. Think of all the time that could be spent on making the apps themselves better instead of developers spending time keeping up with Apple's latest look.

Thoughts on things Apple could help developers with?


2005-11-04 06:22:40
RE: Preferences Pane
Well said. Bindings made this a lot easier in the controller layer -- but it would be great to see a creative follow up on the view layer. Granted, it'd probably be a somewhat rigid layout, but that would still save a great deal of time.

What might be interesting is if there were a macro you could tag certain NS controls with and have XCode automatically recognize them as preferences, and therefore customize the preferences pane accordingly. i.e you could tag radio buttons vs checkboxes with certain characteristics and have XCode take care of the rest (or at least 80% of the work and then you could narrow in on the details.)