If you're a web developer, you're probably used to thinking about no more than two or three different versions of your webapp. There's the version that's live in production use, and there's the version you're developing right now. If you're working in a company with some discipline, you probably also have a third version of the webapp deployed on staging or test servers.
iPhone apps are different. With the iPhone, you need to be thinking roughly eight releases ahead. That's the same level as chess grand masters.
To guarantee your users get the best experience and prospective users are most likely to find your app in the store, you need to keep all of these app versions in your head:
- The version Apple is "reviewing" right now.
Your app might be in the approval process for 3 days or it might take 7 weeks. If you forget about this version in week 5 then you'll be screwed when it hits the store and starts hammering your servers or support email address.
- The version you've got primed and ready to submit to Apple.
This is your latest stable build. You've tested it and you need it to be ready for submission to make sure Apple are constantly reviewing your stuff.
- The version you're coding right now.
As soon as build 1 is approved, you'll push build 2 into the approval process which means you need to start prepping a brand new version of the app to fill slot 2.
- The version you're designing right now.
If you're more than a one-man band, you'll want to collaborate with others on your app, particularly the aesthetic. It's a wasted opportunity if your app is blocked waiting for graphics when it could be waiting in the approval process.
- The version you're planning right now.
Unless your app is a simple game, you're not going to be able to build everything into version 1.0. As well as the features your working on right now you need to keep your ideas fresh and relevant, taking into account user feedback and reviews.
- The version with the extra features people tell you they want when you show off build 1.
When you show people your app, if they like it they'll start thinking about how they could integrate it into their own lives, which means they'll have feature requests for you. If you're not already working on these features, you need to visualize where in your development plan they'll fit, if anywhere.
- The version you think about in the shower.
This is the version you'd already be working on if every feature took less than an hour to code. Good features need hours and hours of love and attention, so "pie in the sky" ideas need an outlet. The shower works. So does the pub.
- The version you'd build if you could throw it all away and start again.
Feedback from real users often means your app's development can turn in a direction you didn't originally anticipate, making development harder. At some point you'll start to visualize what the app's internals would look like if you rewrote it all from scratch. Keep thinking about it, and refactor your code. Whatever you do, never rewrite from scratch.
Are you mentally tracking all of these versions? Did I forget some essential versions that are constantly on your mind? Let us know in the comments below.
Think like a Grand Master, or your iPhone app will fail
If you're a web developer, you're probably used to thinking about 2 or at most 3 different versions of your application. There's the version that's live in production use, and there's the version you're developing right now. If you're working in a company
8 moves (versions) ahead of your app:
1. The version Apple is "reviewing" right now. Your app might be in the approval process for 3 days or it might take 7 weeks. If you forget about this version by week 5 then you'll be screwed when it hits the store and starts hammering your servers or support email address.
2. The version you've got primed and ready to submit to Apple.
This is your latest stable build. You've tested it and you need it so that Apple are constantly reviewing your stuff. LINK: Jof's talk.
3. The version you're coding right now.
As soon as build 1 is approved, you want to push build 2 into the approval process, so you want to have the next build ready to go ASAP.
4. The version you're designing right now.
If you're more than a one-man band, you'll want to collaborate with others on your app's features. Maybe you need a few gorgeous new
5. The version you're planning right now.
6. The version people tell you they want when you demo build 1.
7. The version you think about in the shower.
If every feature took less than an hour to code you'd already be working on this version. Good features need hours of love, so "pie in the sky" ideas need an outlet. The shower works. So does the pub.
8