Genome Studio

As you may know the app store hit 85,000 apps recently and 2 Billion downloads. App aproval times keep getting longer and longer due to the influx of people trying to jump onto the gravy train. And who could blame them with success stories about developers making millions off of relatively simple apps. The truth is only a few developers end up profiting due to the way the application lists work.

Visibility

The biggest problem is visibility. Most people find apps directly on the iPhone. Which means they find things by clicking through lists in categories. Each category shows the top paid, top free and recently released. Each of these lists only shows 100 items, with no ability to view subsequent pages. With 85,000 apps, you can imagine that a lot of apps are unfindable using this method. The recently released list shows new apps and app updates - to take advantage of the situation, developers will just update their apps as often as they can (often with meaningless updates) in order to ‘juice’ their sales and rankings a bit. This ends up putting more strain on the approval process and just makes it harder for all developers to get necessary bug fixes and updates to users in a timely manner. Apple will just lengthen the approval process as long as they need to in order to discourage this behavior (it’s unlikely that they will hire more ‘app approvers’.. they would need thousands of them in order to get approvals done in a timely manner). I have an update that’s been awaiting approval for 3 weeks now.

There is search for finding apps, but how do you know what to search for if you are ‘just browsing’?

Basically what ends up happening is you have a limited amount of time when your app is released to get into the top 100. If you can get in there, you have a great chance of staying there, atleast for a bit. If not, your app falls off the charts into oblivion. You can still get a few sales from search or if you can generate some buzz for your application outside of the app store. But since most people find apps in the app store itself, the app store is still your best chance for getting a conversion.

The current system favors giving a few apps the majority of the sales, whether they deserve it or not. It has nothing to do with the quality of the apps. Review scores do not appear to be a factor, only raw sales or downloads (correct me if I’m wrong). My prediction is that developers will start to leave in droves (or atleast complain loudly) once they start realizing that they’ve spent months working on an application only to have it drop out of sight as soon as it’s released.

The app store needs to change to accommodate the volume of apps. Here’s what I think needs to be done.

There needs to be more ways to find apps, other than just a top 100. I suggest:

• Random List - 100 or so random apps in a category. This would go a long way to making things more fair.
• Top Rated or the ability to sort by rating. Bring ratings into the mix. Don’t just go by downloads. A lot of good apps get lost this way.
• More granular categories. If users can only see 100 apps, then we need more sub-categories. Or:
• Ability to browse more than 100 apps. Why not let people view as many as they want?
• Wish-lists or user generated lists of apps, like Amazon has.
• Stop making app updates so important to sales. Only show new releases, not updates.
• Paid advertising spots. Another revenue stream for apple, but could help break the dependence on downloads.
• Recommendations. Users who bought this app, also bought… Once again, Amazon gets this right.

Imagine if Amazon.com only let you view 100 items in each category? They’d be missing out on a lot of sales. The App store’s Top 100 lists might have been fine when there was only a handful of iPhone Apps, but now that the device has become a huge platform, Apple needs to expand the functionality to match the inventory.

Getting more comfortable with the language. Working on coding some custom controls, figuring out CoreGraphics, etc. Also installed the new OS 3.0 stuff.

Questions:

• Why do I see this in some example source:  NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; ….  some code …..  [pool release];
  Why is this necessary?
• Why is it that messing up a method call on an Objective C object results in a crash that provides no useful debugging info? it seems like most crashes on the iphone don’t give you a proper line number.. Am I missing some project setting?

I’m in the final stretch for the 1.0 version of my iphone drum machine / synthesizer app. I’ve settled on the final configuration as far as the synthesis capabilities. Doing 10 voices of 2 osc synths proved to be too much for the iphone’s CPU to handle (BTW, I’ve seen info putting the Iphone 3G’s cpu at 400 mhz, not the 666 mhz I originally thought). So, I settled for 4  2-osc “powerhouse” synths, 3 specialized bassdrum / FM synths, 1 specialized snare drum / clap synth, and 2 specialized hi-hat generators (modelled after oldschool 808 machines). Overall this gives you tons of possibilities and should enable people to make pretty decent electronic songs on their IPhone. There are no samples in this bad boy - everything is synthesized in realtime.

Realtime control is another thing that sets this app apart from other iphone apps. There is a performance page which lets you loop/remix portions of your tune using multitouch. Dual touchpads and mute / solo control is planned for this page. Another thing that would be awesome is an arpeggiator, but I dunno if that will make it into version 1.0. There is also a ‘motion’ page that will allow you to draw automation envelopes  for one parameter for each part.

These features address  what I see as the major shortcomings of the current crop of iphone music apps. Either they are simple ‘instruments’ which people will most likely use once or twice and then stop using. Or, they are mostly sample based which stifles creativity. Or they don’t offer enough options or automation abilities to make an interesting sounding song. Another shortcoming is poor interface choices. Piano roll on a touchscreen = tedious. Iphone apps (or more generally, touch UI’s) need to be based around taps and swipes. For taps, buttons need to be big enough to hit easily (I’ve found the ‘magic size’ to be about 80 pixels x 80 pixels.). Doing a piano roll on a 320 x 480 screen means that you will be trying to tap on stuff that’s 10-20 pixels wide which is highly frustrating and a bane to good workflow.

My goal is to finish all the major pages and functionality this weekend and start implementing the final UI. Hopefully I’ll be able to start posting some audio and video next week.