Journal of a Maker

With the advent of the iPhone 4 Retina Display, iOS application developers have an even larger task when it comes to creating the various sizes of icons they need for their applications. In summary, here are the icon sizes and where they’re applied:

1. 57×57 – iPod touch, iPhone, iPhone 3G, iPhone 3GS main screen
2. 29×29 – iPod touch, iPhone, iPhone 3G, iPhone 3GS app settings and Spotlight, iPad settings
3. 72×72 – iPad main screen
4. 50×50 – iPad Spotlight
5. 72×72 – iPad main screen
6. 114×114 – iPhone 4 main screen
7. 58×58 – iPhone 4 settings and Spotlight
8. 320×320 – iOS documents
9. 64×64 – iOS documents

You may wish to customize your document icons (e.g., by overlaying your icon on a page icon or somesuch). And of course, iTunes requires that you submit a 512×512 image to be used in the App Store and elsewhere. This is often customized but will likely be similar in style to your primary app icon.

If you’re like me, you don’t have a graphic designer operating at the pixel level to produce sharp, snazzy icons at all those sizes. So instead of tooling around in Photoshop every time you tweak your 512×512 master icon (Image -> Image Size… -> 57px -> Save As… -> Undo -> ad infinitum), why not automate the process?

I’ve put together a small (tiny) XCode project that uses AppKit to output all the icon sizes mentioned above. And it’ll be easy to tweak when the iPad with Retina Display (*fingers crossed*) debuts and needs 96px and 144 px versions of your icon. Throw it into your build system and get freshly-resized icons every time you compile. Grab it here:

So, you’re writing an awesome multimedia application for the iPhone. Everything’s going swimmingly, and you even have some nice animation effects for when the iPhone is plugged into an external accessory, just like the iPod app:

- (void)toggleVolumeDisplay: (BOOL)show
{
	BOOL isShowing = (volumeSlider.alpha > 0.0);
	if( isShowing && !show )
	{
		// Animate volume slider down and out, while animating play controls to center of view
	}
	else if( !isShowing && show )
	{
		// Animate volume slider in, while animating play controls up to the top of the view
	}
}

Or something like that. That’s purely to illustrate what you might be doing in response to a run-of-the-mill hardware route change (headphones plugged in, connected to speaker dock, etc.), which of course you’re detecting like this:

	// When the view is loaded
	AudioSessionAddPropertyListener( kAudioSessionProperty_AudioRouteChange, RouteChangeListener, (void *)self);

	// Called later as part of your listener callback
	CFStringRef state = nil;
	UInt32 propertySize = sizeof(CFStringRef);
	OSStatus result = AudioSessionGetProperty( kAudioSessionProperty_AudioRoute, &propertySize, &state);
	if( result == kAudioSessionNoError)
	{
		if( CFStringGetLength(state) > 0)
		{
			if ([(NSString *)state compare:@"LineOut"] == NSOrderedSame) // only special case we care about
				shouldShowVolumeControl = NO;
		}
		else
			; // vibrate switch engaged
	}
	else
	{
		if (result == kAudioSessionUnsupportedPropertyError)
			shouldShowVolumeControl = NO; // probably simulator
		else
			; // error encountered
	}

This has been documented in plenty of places.
Continue reading »