Notes from Mac programming class guest lecture

The idea behind the lecture was to talk about what makes a great Mac app. I took that as an excuse to talk about everything from work habits to UI to marketing. In other words, I threw in just about everything I know — which, it turns out, only takes about an hour to deliver. :)

It goes chronologically — getting to 1.0, releasing 1.0 and the follow-through, on to working on 2.0.

I don’t actually have time right now to write it up properly. But, at least, here are my notes:

Road to 1.0

More money to make in Mac software than in iPhone software

Mission statement
Photoshop example

Work habits

stay in the chair
will have to give up things - games
exercise is very good for brain and morale

motivation - gumption
think of thing you want, rationalize that this is how you get it
fear is good too

nearby small notebook works as short-term memory and to-do lists
break tasks down real small

Design

keep 1.0 feature list very, very small
polish the hell out of those features
you don’t really know what users will ask for

Pretend you’re a toy-maker - Kris Kringle
Delight your users
Peacock feathers
Do lots with one click
The extra step to make things easy
Feedback - animations - never “what just happened?”
Performance is UI
Stability is job #1
Look at lots of other apps, esp. by those you admire, but also look at apps that don’t work as well
Coherency of UI
Going beyond the merely utilitarian means you understand the human spirit - and your app is more usable and thus more useful

Sketch out UI
Use Acorn or whatever to do actual mockups
Cabel Sasser working on Coda

Shoot for ADAs and Eddys - by that I mean: don’t pander, just aim high
wwad
wwpd

Code

unit tests
version control
bug tracker

Support latest OS, not OS minus one, on major releases
use latest technologies
Multi-threading only if you have to
AppleScript support might make sense

don’t fight frameworks
learn the Cocoa way
Don’t subclass very much, at least not beyond one level
Don’t waste time on wrappers
Don’t over-use categories
Pretend someone else who knows Cocoa will use your code

architecture is important
write it down

Error checking – with recovery when possible
Especially important if works with cloud

Use Sparkle
Use Growl

Beta testing

Hallway UI testing – wife, husband, kid, cat

don’t do public betas
get beta testers
remember they’re geeky

Have crash logs sent back to you

Use Shark and Instruments

Random testing

Charge enough money for your app: $19.95 usually a minimum

File bugs with Apple

1.0 Release and marketing

listening to users
remember that people who actually submit request may, on average, be slightly geekier than the entire population
Good stories are important
never panic and add a feature
Use Twitter - for you and for product
Have forums or mailing list or something
Have weblog - point to other cool stuff, not just yours
Be human
There will always be complaints. Pretend to yourself that you have a thick skin.
Don’t make promises before shipping
Keyword searches for your app

Give back to dev community if possible
Other developers also have influence
Go to WWDC etc.
Read developers weblogs

Let world know what you’re working on in general - don’t need details

Take the long view

2.0 and up

it’s okay to have users wanting more
it’s okay to bring your users along - make simple things a little more complex later on

Some great-seeming architectures are hard to remember and understand
Don’t be afraid to re-architect

remove features

Keep learning

I will make mistakes, sometimes a series of them. You will make mistakes. And some of what I’ve said is wrong, or wrong for you or your app.