Although Xcode is all you really need to get started with iOS development, there are a lot of useful tools that can make your life a lot easier.

When you’re writing code, Accessorizer can eliminate a lot of the drudgery. You usually find yourself creating lots of properties, which involves declaring an instance variable, adding a @property declaration, and @synthesize in your implementation file. With Accessorizer, you simply select the instance variables, hit a hotkey, and copy the generated code into your source. For example, if you have the following ivars:

NSString *title;
UIView *aView;
NSInteger count;

Accessorizer will generate the property declarations & implementations, which you can customize. In the simplest case, you’ll get this:

@property (nonatomic, copy) NSString *title;
@property (nonatomic, retain) IBOutlet UIView *aView;
@property (nonatomic, assign) NSInteger count;

@synthesize title;
@synthesize aView;
@synthesize count;


You can also have it generate init & dealloc methods and accessor methods.

For source control, you’ll probably want something more advanced than Xcode’s built in source control, especially if you’re still using Xcode 3.2.x. Even with Xcode 4, it only tracks files included in the project, not related files such as artwork & documentation not included in the project.

For Subversion, I like Versions. After looking at every Git GUI client, the only one I found that I like is Tower. For a file comparison & merge utility more advanced than Apple’s FileMerge, I like Changes. It gives a lot of display options and is also really nice for comparing directories.

If you’re using Cocos2D, you’ll need a few utilities to generate sprite sheets, textures, and particle effects,

One tool that’s absolutely essential is a sprite sheet generator such as TexturePacker. It takes a collection of single images and packs them into a single image file with the most efficient arrangement along with a plist that tells how to access each piece. TexturePacker is available in several free & paid versions.

In many apps, you’ll use some particle effects such as smoke, fire, and explosions. Particle Designer makes creating them fun & relatively easy with a large online collection of shared emitters. The plist file it generates can be used with a single line of code.

If you’re using a tile map, Tiled is a nice, free tile map editor.

If your app uses the accelerometer, you’ll need iSimulate to test it in the simulator. iSimulator consists of two components: an iPhone app and a library you include in your simulator builds. When you run the iSimulate app, all movements & multi-touch events will be sent to your app.

Finally, you’ll need to create a nice demo video for your app. Sound Stage is a great way to record videos from the simulator. It can record either the app content only, the app running inside the iPhone, or a custom background. You can also use iSimulate with it.

I just submitted a minor update to iDjembe that adds Retina display graphics, a new icon, and a new app info screen. For some bizarre reason it’s selling fairly well, so using it to cross-promote Removr and my upcoming game, Sugar Rush, may help the sales of my other apps.

Speaking of Sugar Rush, the first beta went out yesterday. I’m still waiting for some of the final graphics & sounds. The release is scheduled for Apr. 28.

I’m working on a new game that depends on the accelerometer, which makes testing in the simulator difficult. I asked on Twitter about a hack to use the accelerometer in the simulator and was pointed to iSimulate.

iSimulate is a brilliant application that runs on your iPhone, along with a library that needs to be linked into simulator builds of your application. The iSimulate application connects to your computer over your wireless network and lets you send accelerometer, compass, and multi-touch events to the iSimulate-enabled application running in the simulator.

After you finish developing your app, you can then use iSimulate to record video trailers & demos of your app.

In a new app I’m working on, I created a series of lightweight cocos2d sprite subclasses which simply call the superclass init with some parameters. As soon as I called it I ended up crashing with a weird looking stack trace showing lots of nested calls to init methods.

Screen shot 2011-03-06 at 2.18.44 PM.png

My init methods were pretty simple:


@implementation Gummybear

-(id)init {
    return [super initWithName: @"gummybear.png"];
}

@end

My superclass’s init method used CCSprite’s initWithSpriteFrameName: method.


- (id)initWithName: (NSString*)name
{
    self = [super initWithSpriteFrameName:name];
    if (nil != self) {
		// do some more initialization here
    }
    return self;
}

It ultimately ends up calling initWithTexture:, which is where the problem lies. It turns out initWithTexture: is calling [self init]. Guess which init method was getting called?


-(id) initWithTexture:(CCTexture2D*)texture rect:(CGRect)rect
{
	NSAssert(texture!=nil, @"Invalid texture for sprite");
	// IMPORTANT: [self init] and not [super init];
	if( (self = [self init]) )
	{
		[self setTexture:texture];
		[self setTextureRect:rect];
	}
	return self;
}

The fix was to simply change the name of my init method to something else.

When Apple introduced the MacBook Air late last year, they called it The Next Generation of MacBooks. I was really hoping the new MacBook Pro would inherit many of its attributes, such as the thin profile, light weight, and standard SSD. Although the new models are a nice improvement over the old MacBook Pro, with faster processors & improved graphics, they’re still just as big and heavy.

After using the 3 pound 13″ MacBook Air, I will never go back to a big laptop that weighs 5 pounds or more. I would have preferred to see much thinner MacBook Pros with no optical drive and a standard SSD drive. Despite the slower processor, I find my MacBook Air to be almost as fast as my old 15″ MacBook Pro thanks to the much faster SSD. I would still love to see a “super MacBook Air”, with the fastest CPU & graphics from the MacBook Pro and 8GB RAM, but without too much extra size & weight by keeping the SSD and eliminating the optical drive.

My resubmitted 1.3.1 has been approved and is now ready for sale. This version features 100 levels with 4 new hidden achievements in game center. It now adds levels created with our Level Editor to the built-in levels, unlike previous versions which used a single level database that could be edited. Levels are added using file sharing in iTunes.

After a week in review, I finally got an email from Apple today saying that version 1.3.1 was rejected because:

Removr has the UIFileSharingEnabled key set to true in the Info.plist, but this feature is not functional.

When file sharing is enabled, the entire Documents folder is used for file sharing. Files that that are not intended for user access via the file sharing feature should be stored in another part of your application’s bundle. If your application does not require the file sharing feature, the UIFileSharingEnabled key in the Info.plist should not be set to true.

Removr does use file sharing to allow levels to be added using our level editor. I changed the way it works since the last version. Previously, I copied the internal level database to the document folder where it could be edited. I now look for files with the extension leveldb and add them as additional levels. For the benefit of the reviewers, I’ve also provided a sample level file.

I had originally intended 1.3.1 as an intermediate update to add some new levels & achievements while I perfected that feature, so I had it temporarily disabled, since I figure not too many people were using it. After I submitted it, I contined to work on that feature in a way to lay the groundwork for in-app purchasing, as well as creating new levels.

The newly re-submitted Removr 1.3.1 now has 100 levels instead of 96 with fully-functional file sharing. Hopefully this one won’t take too long to approve.