Deciding What Kind of App to Write

A bunch of people have asked me what sort of Mac app they should write. The most fundamental decision you have to make is whether you're in it to make money, in it for the fun of it, or in it to help people. You can address two or three at once, but there's usually one key element.

If you write an app aimed at a very specific need, you might be able to serve an area that no one else is serving. The advantage of this is that you don't have to play catch up. You make up the game as you go. You can also earn some very loyal customers with this approach and possibly some very good money.

If you're in it for the money or maximum exposure, though, your best bet is to go for something with wide appeal. Ideally, the value of your app should be evident within the first two minutes. If it takes somebody fifteen minutes to figure out what the thing does, you've probably lost them as a sale.

Success Stories

Photo Booth is probably one of the best Mac apps ever made. It's fun and the value is immediately obvious. There are no instructions you have to read and there's no fanfare when the app stars. It just is.

I like Front Row for a lot of the same reasons. I don't need instructions to figure out how to use the thing. The whole feel is satisfying, and the value of it is immediately obvious. No setup wizards, no fanfare, but stunning results.

Those are both Apple apps, though. Delicious Library is a very successful third party app. It does a good job of organization, and everyone understands the value of organizing things, but they went a step further and made something that is gorgeous. The feel of it is great.

This isn't just for consumer apps. Aperture doesn't use standard Aqua controls. Like the other pro apps, it uses the ProKit user interface. The feel of the application is one of the things that separates true Mac apps from everything else. People will spend money on something that feels right.
Design Element
Deciding What Kind of App to Write
Posted Sep 8, 2006 — 7 comments below


Ganesan Subramaniam — Sep 08, 06 1776

There are a differentiating factor when you write an app for "jingles" and when you write an app for the "jiggles". In the former where money is concerned, time to deliver is of utmost importance. So you may have to cut some corners in terms of features; You might have to take the easiest route, one that works even if it might not be the best solution. However if you are writing an app for fun of it, then learning and doing it the right way should the main focus.

Corey Ehmke — Sep 10, 06 1780

In the "app aimed at a very specific need" camp, I've often found that inspiration for an application can come from needing, as a user, to find an application to solve a particular problem, only to discover that the applications that already exist only meet (at best) 80% of my needs.

I loosely apply the principle of the categorical imperative and assume that if the remaining 20% of functionality is important to me, it's probably important for a number of other people as well.

In a given field of applications, the baseline functionality that all of the applications deliver can be thought of as "basic needs". Whatever terms describe this baseline functionality are the same terms that people will use to find your application, whether through a web search or browsing through the Apple Products Guide. Your application needs to address the same basic needs as competing apps, but preferably in a more elegant or user-friendly way. The problem with innovating in the area of basic needs is that potential users of your application may not ever get the chance to weigh your more elegant approach to basic needs against a better-known competitor, so you shouldn't focus too much of your effort on the "better mousetrap" problem.

Basic needs cover 80-90% of the functionality; unspoken needs (also called "delighters") make up the balance. Here's your chance, as a developer, to really shine; by innovating around a need that no one is addressing (my missing 20% above), you can distinguish your application in an immediately obvious way and, potentially, address the needs of a large enough user base to get some traction.

The trick is that over time, "delighters" transform into basic needs. What once made an application stand out in a field of competitors is now addressed in more or less the same way across that field. So your application is never finished, and you must either continue to innovate, or abandon the cause altogether.

Shawn — Sep 11, 06 1782

I'm writing an app that is probably only useful for me, as the need is so specific, but since I've been trying to learn the art of programming on the Mac, programming the app is its own reward, as I'm learning all the basics plus things like Sync Services.

PGM — Sep 11, 06 1783

Actually, one of the reasons I think that Apple apps are so great is that they actually apply the 80% rule differently than the poster above. They also mention it in their programming guide somewhere. The trick is to restrict yourself as a programmer and only include functionality that >80% of the users will use. This helps to keep the app from becoming bloated with functionality that hardly anybody uses.

Jacob Rus — Dec 14, 06 2699

This response is a bit late, so people (other than scott) probably won't see it, butů

Corey: I think that's a really insightful take on the best-of-class apps, and it clarifies my thinking on the subject.

PGM: No, Corey is exactly right, and this applies to Apple's apps as well. In fact, I think your 80% rule and Corey's 20% are completely consistent with each-other. The idea isn't to pile on features that 1% will use, but to find those features that everyone needs, but no app is currently providing. 2 examples:

1. Aperture: Apple looked around at the digital photo manager/editor market, and noticed a gaping hole. While Photoshop had, and has, the market for retouching, special effects, etc. all tied up, no shipping application had seriously looked at the workflows of digital photographers. Applications like iView, Cumulus, and Adobe Bridge are basically glorified file managers, and they approach the problem as one of files with thumbnails and folders. The Aperture team looked around at the newly available fast hardware, and at the RAW images coming out of modern digital cameras, and then sat down with the disgruntled photographers forced to use these other apps, and together mapped out a new product that would be based around images, using physical metaphors like light tables, but extending their power with computers. This is a feature set and indeed, a whole outlook that other developers had completely missed, and the result is a true delight.

2. Textmate: Allan Odgaard looked around 2 years ago, and was unhappy with Xcode's pretty basic text editor (basically halfway between TextEdit and Mike Ferris's TextExtras input manager. He also didn't like the command-line unix editors (vim, emacs, etc.), wanting to keep to the GUI and the Mac philosophy on his shiny G4, and felt constricted by the philosophy of BBEdit. So he went out, looked around, and found text editing patterns which he felt should be automated by the computer, but weren't by any existing app, and set out to fix that. The result, TextMate, has the most easy-to-understand yet powerful, orthogonal, abstractions of any editor I've ever used.

When it comes to pure feature checklists, there is no way for a new product to ever line up as many boxes as existing dominant applications. Also, they wouldn't want to, because in general, lots of those features are crufty and obscure. Instead, the goal should be to provide powerful new abstractions that every target user needs, without even knowing it.

Chad — May 21, 07 4134

The title alone makes me scratch my head in wonder. It's like me deciding that I want to become a carpenter, but I have no idea what to build. Then again, I tend to have too many ideas that I work on, which can create its own set of problems by dragging my attention in too many different directions at once.

For the smaller developers, they should focus on something that interests them and which they personally find useful. Otherwise, if you are just looking to make money, there are plenty of companies out there that will pay you to program some boring internal application for them.

Kevin Foley — Dec 25, 07 5288

I decide what application to write by deciding if I know a subject well enough to be useful. The standard advice to young authors is to write what you know most about. The problem with this is that since most programmer's know code development, we find ourselves surrounded with editors, scripting languages, compilers, operating systems, and IDEs.

Elegant solutions to problems previously solved gives a boost to the ego. Jacob obviously appreciates and gives kudos to Allan Odgaard for his work on Textmate, but it is still yet another ...

God often blesses us with hobbies so that we are able to earn a living. Many, such as myself, a mechanical engineer, came into program development from other disciplines. This makes us the best suited to write applications for those disciplines. Crossing the boundary from all most any (a)vocation to program development allows the author to know of the possibilities of the computer platform and the needs and wants of the non-programmer.


Comments Temporarily Disabled

I had to temporarily disable comments due to spam. I'll re-enable them soon.

Copyright © Scott Stevenson 2004-2015