The next app is close

I'm getting really close to submitting my next iPhone app to the App Store. How close? Well, let's just say I'm now working on documentation and a website more than the app itself. I did a quick look through the store, and only found two apps doing something close to what I'm doing. One is $.99 and does very little compared to mine, and the other is quite expensive and does about what mine does, but with a prettier interface. I figure marketing at a reasonable price should make mine sell quite well.
So, given it's so close to going out, I figure now is the time to really go over some lessons learned in this app, some technical, others more project management.
First, technical lessons learned.
It's Really Bad to Return alloc'd Objects
This sounds like a no brainer, but, if you need to return an object, make sure you didn't alloc the memory for it yourself. These objects are easy to leak, and if you try to clean them up yourself, you can end up releasing objects not retained anywhere, resulting in a crash.
Instead, if you return objects (Like a list for example) instead of using "alloc" to create it, use other options. Instead of:

NSArray *array = [[NSArray alloc] init...]; //bad idea

use this:

NSArray *array = [[NSArray array] init...]; //bad idea

The resulting object is safe to pass from method to method, and you don't have to worry about cleaning them up.

The Analyze tool is your friend
The build menu has a "build and analyze" option. At first, I thought this was nice, although not very handy. I was wrong. This is probably the most useful tool in XCode's build menu. Using this, before fixing my methods, I saw 30 or 40 potential issues. I ignored them, because upon looking at them, I was releasing the objects later in the code (again, BAD idea). Using this feature, I fixed all those pesky memory leaks in one swoop, in about 30 minutes, instead of hours it would have taken to run leaks to find the leaks in the first place.

Instance variables need to be referenced with "self"
This is another one of those "duh" moments. In Java, you have the "this" keyword, which references an instance variable. It's not required in Java, but can make your code easier to read, especially in areas where you're assigning an instance variable from a local variable, or visa versa, like in this method:

String str; //instance variable
public void setStr(String str){
str = str; // which "str" are you setting?
}

It's far clearer to use this instead:

String str; //instance variable
public void setStr(String str){
this.str = str;
}
So, why the quick Java lesson? Well, in Objective-C, not using "self" will not update retain counts. So, if you have, a list for example, and you try to assing it like this:

@synthesize array;
array = [[NSArray alloc]... //retain count not incremented.


and later try to use that array like:

[array objectAtIndex:...];

you'll crash, or at least I did.
instead, both those examples should use the self keyword, like...

@synthesize array;
self.array = [[NSArray alloc]...];
...
[self.array objectAtIndex:...];

or

@synthesize array;
[self setArray:[[NSArray alloc]...]];
...
[[self array] objectAtIndex:...];
You get the idea ;)
Now, the Project Management lessons learned:
Watch Out for Creep
No, I don't mean that crazy guy down the street who...
I mean scope creep. We all know what scope creep is, but in small projects, in a platform so easy to code in, it's really easy to expand beyond what you were thinking. My original thought was a small app, perhaps two or three views, and within a couple of days, that had exploded to five or six screens and a lot more functionality. Today, as I get ready to release, it's over 15 views, and does a lot more than I wanted originally. Will it make it sell better? Probably. Was it worth the extra time? Don't know, but I'd guess probably not. The only way to know that for sure, would be to go back and build my original idea, and put it out at the same time. But, given that my original time frame was three weeks to get it onto the store, and it's been about six weeks already, with probably another two before going live, I overspent on my time. Had I thought about what I wanted to do a little more, this might have not happened. I may have planned to make this much larger from the start, and I could have budgeted more time (since this is a side project, money is only opportunity lost rather than real dollars).
Find Help if You Need it
As I just stated, this app turned out to be much larger than expected. A little planning on my part, and I might have found some friends to help me bang out some code early on, making this happen quicker. The downside to that, is I would have had to either pay them, or share my profits. Of course, if the first app is any indication, there probably won't be a lot of profit in this one, but my luck, I'd give someone 1/2 my profits on a real winner of an app.

This was really just some of my findings and lessons learned in this project. I'll post about this app again once I get it into the approval process in a couple of days, and again when it goes live. I'll say what it is at that point (I don't want to give anyone a chance at catching up to me ;) )