aamir virani

How Apple’s Approval Process Actually Helps Users

Paul Graham wrote an article on how Apple alienates its iPhone developers. He has a good discussion about developers iterating and needing to get a new product in the hands of their users. In fact, he mentions a developer who says the approved app feels crappy next to the daily builds and betas he hands out.

It’s time for these folks to try my G1. Not because it’s better but because Android will annoy the crap out of you. Every day, I get a notification telling me “N number of apps updated.” And every day, I roll my eyes and clear the notification. Users don’t want to go through this process; it’s annoying when it happens on a desktop every few weeks, so it’s even worse on a daily basis on a phone trying to download over a 3G EDGE connection.

Deciding what constitutes a critical bug is difficult – if you’re a lone developer you think everything is important. Should Apple trust you to self-regulate and update only on critical fixes or major new releases?

Apple has an iron fist when it comes to the iPhone and its ecosystem because its advantage is a tightly knit experience. Getting a daily notification while you sync asking you to update or an in-app pop-up with details lessens the polish.

Ultimately, I think this App Store stuff is a way of throttling developers to ensure the experience is not too painful. More updates make users think, and you want to minimize that.

A Super Quick Guide to Using Git

While thinking about how to organize projects on my home machines, I decided to look into Git, a version control system like CVS and Subversion (SVN). Unlike those two, however, Git is distributed, which means you can have multiple repositories for the same project, and/or only a local one to handle your stuff.

You can use Git a lot like Subversion with one major benefit: you can do local check-ins without having to branch, synchronize, and create remote copies of your own sandbox.

Of course, this means you have to learn yet another set of syntax. A really good primer is a crash course on Git for SVN users, but here are the key things I learned and found to get rolling fast.

So let’s just assume you’re creating a project in directory local_dir. You already have a bunch of files and you want to sync up. You also have a remote server my_server. Here’s what you do.

First, go into the local_dir directory and:

• git init – sets up the git files for tracking locally
• create and edit a text file called .gitignore – on each line place files you want to ignore, like DS_Store and *.tmp files, etc.
• git add . – tells git you want all files (recursively) as part of the next commit
• git commit -m “initial checkin blah blah” – tells git to commit with the given message

At this point you’re locally ready to go. If you don’t want to work on multiple machines or synchronize to the cloud, have fun!

Otherwise, you should now go to your server and set up a place for your files to live in remote_dir:

• mkdir remote_dir
• cd remote_dir
• git –bare init – sets up git in this directory with no initial working copy

Now you go back to your local machine and tell it about your remote server:

• git remote add origin account_name@server.com:remote_dir – tells git how to ssh to your remote repository
• git push origin master – tells git to send your local copy to the server – magic!

You may want to edit .git/config so that you can quickly push and pull files by adding the following lines to this file:


[branch "master"]
  remote = origin
  merge = refs/heads/master


This will mean you can use the following commands to synchronize to and from the remote server:

• git push – send local copy to the server
• git pull – get server updates into local copy

Finally, if you want to work on other machines (or have someone else join you in your work), all they have to do is:

• git clone account_name@server.com:remote_dir – copies the remote repository to your local machine

Voila – you’re ready to go!

How do you know if your code is fast enough?

One of the big pains I’ve seen while at PR and X is dealing with customers, managers, and critics who go off on performance.

• When you click here, it takes too long!
• When you start up, it takes forever!
• When this page loads, I can go get a cup of coffee and it’s still loading!

All are valid concerns, but it gets a little ridiculous when you hear someone say “it needs to be 0.2 seconds faster” or “we have to be at least as fast as before even though we’re doing 10 times more processing”.

Perception, a qualitiative measure, is more important than quantitative measurement.

Given that Internet connection speeds vary, that client computers can be a few years old, and that humans can be sedated or caffeinated, it’s even more important to move beyond simple clock-watching.

David Weiss discusses performance on his blog and mentions a classification scheme for timing perception:

• Instantaneous (0.1 to 0.2 seconds)
• Immediate (0.5 to 1.0 seconds)
• Continuous (2 to 5 seconds)
• Captive (7 to 10 seconds)

So instead of simply whining about how things have gotten slower by 0.1 seconds, determine where your feature (broken down into actions or features or events, but that’s another topic) falls. Now, are you within range?

The other difficulty is deciding which category the feature should be in. This is where user studies matter. Your boss is not the ultimate arbiter. You are not the ultimate arbiter. Make sure your typical set of users would be happy with your choice by faking time delays in a mockup.