XK72 | Java and Adobe Flash Software

Half a year on from the launch of the iTunes App Store, one of the biggest difficulties for developers is getting noticed amongst the 10,000+ apps. We’ve talked about traditional marketing; we’re trying new forms of marketing (twitter, social networking), but mostly agree that promotion within the App Store itself is the golden ticket. I’ve had this idea rolling around for some time; today I’m appeasing my Things todo list by blogging about it.

Promotion within the App Store is available in two areas; the masses purchase apps creating the Top 10 / 25 / 50 / 100 lists, and Apple chooses apps to feature in the New and What’s Hot lists (and some others). Promotion within the App Store is at the whim of Apple and the masses.

The problems with the Top lists has been the topic of much discussion; most recently its penchant for passing wind has been fouling the air. The Top lists create a feedback loop where sales drive sales; it’s great when an app is in the loop, but increasingly developers are finding development unsustainable if it’s not.

My assumption is that there are many apps of quality and utility that deserve to hit the big time, and that without promotion their growth is stunted. Apple can’t promote every app at once, but maybe the promotion can work better.

I am thinking of a system where potentially successful apps are identified in a way that is independent of sales volume and recommendations. Apps are then randomly promoted with a weighting towards those that are more potentially successful. A feedback loop analyses the effect of promotion on sales and increases or decreases promotion to maximise revenue. In this case “success” is defined as sales, that is making money for Apple and for the developers.

How to identify potentially successful apps? If Apple tracks which apps people view and and which apps they buy, then an app with a strong view-buy ratio likely matches consumer needs and has reasonable quality (bonus points for including data on how long the app stays installed; if the user removes it immediately with a 1 star review that counts against). Identifying apps in this way is independent of popularity; in fact popularity will worsen the view-buy ratio as it attracts more views, so this (and a minimum number of views on the other end of the scale) may need to be taken into account. The potential to tailor featured apps to individual users is obvious, but I think one-step-at-a-time is more likely!

Potentially successful apps are then randomly featured on the App Store with a weighting towards apps with a high view-buy ratio. Being featured will increase the number of views, so if an app is successful it should also increase the sales. The feedback loop continually measures the view-buy ratio and adjusts the promotion weighting. Variance in the weighting algorithm would enhance the approach by stepping back slightly from maximising revenue (ie. for Apple) and sharing it amongst a larger group of apps (ie. developers), and allowing new entrants; like mutation in a genetic algorithm.

I think this approach may solve the problem of apps which should have more sales but don’t have the promotion required. It should mean that promoted apps are the apps that are more likely to sell, which means that overall App Store revenue should increase. Good for Apple, good for developers. Remember that this doesn’t replace the existing Top list mechanism, it sits alongside it. I’m not sure what other problems and exploits it creates! It isn’t a complete picture. I hope it’s an interesting one.

We just tracked down an issue where H.264 video would play on the iPhone over WiFi but not over 3G. The problem turned out to be that the server emitted a Vary: User-Agent header as part of its mod_deflate handling. That header alone was causing the video to fail to play over 3G. I suspect that it may have been a problem on the 3G network itself rather than the iPhone. If you have similar head-scratching issues maybe this is the cause.

As of OS 2.2 there was a problem with UITextAlignmentCenter and UITableViewCells where the text would always show left aligned. The easiest solution was to compile your application for OS 2.0, if you weren’t using any new API features, in which case the original behaviour continued to work. However as of OS 2.2.1 it appears that this no longer works! There were some proposed solutions but they also don’t appear to work anymore.

I’d like to continue building my application for OS 2.0 compatibility so I don’t unnecessarily inconvenience users who haven’t upgraded yet, so I built the following solution that you may find useful – a UITableViewCell subclass that centres the text itself and works when your application is compiled for OS 2.0 or 2.2.1 (and probably others in between).

@interface MyButtonTableViewCell : UITableViewCell
{

}
- (id)initWithFrame:(CGRect)frame reuseIdentifier:(NSString*)reuseIdentifier;
@end

@implementation MyButtonTableViewCell

- (id)initWithFrame:(CGRect)frame reuseIdentifier:(NSString*)reuseIdentifier
{
	if ((self = [super initWithFrame:frame reuseIdentifier:reuseIdentifier]) != nil) {
		self.textAlignment = UITextAlignmentCenter;
	}
	return self;
}

- (void)dealloc
{
	[super dealloc];
}

- (void)adjustLabelSize
{
	/* Center the label view. This works around a bug in OS 2.2 which now effects even code compiled for OS 2.0.
	 * When compiled for OS 2.2.1 this code is unnecessary but still works.
	 */
	NSArray *subviews = self.contentView.subviews;
	if ([subviews count] > 0) {
		unsigned int i, c = [subviews count];
		for (i = 0; i < c; i++) {
			UIView *subview = [subviews objectAtIndex:i];

			if ([subview isKindOfClass:[UILabel class]]) {
				CGRect frame = subview.frame;
				frame.origin.x = floorf(self.contentView.frame.size.width / 2 - frame.size.width / 2);
				subview.frame = frame;
			}
		}
	}
}

- (void)layoutSubviews
{
	[super layoutSubviews];
	[self adjustLabelSize];
}

@end