Estimating iPhone App Store Sales From Rankings

Estimated average daily sales versus popularity ranking for paid apps between the Top 10% and the Top 50% in App store popularity (out of 265k paid apps).

Everybody talks about the top apps in the iOS app store. But there's still a story to be told about the other 90%+ of apps. The story is that Apple is likely paying 100's of millions of dollars per year to these developers, but with that revenue spread incredibly thinly though a very long tail.

Ajnaware’s Weblog posted an interesting hypothesis about App store unit sales. The hypothesis is that sales, plotted against popularity rankings, follows a power law curve. This curve can then be integrated to get total app sales. Phenomena with long tails often seem to follow power law curves. So, given the long tail of around a quarter million paid apps in the iOS app store, a power law seems to be a quite reasonable starting hypothesis.

I used a tiny number of data points for paid apps, ones I've randomly heard about, spread across the entire App store, instead of just the top, and tried to fit my own power law curve to those points. I ended up with a vaguely reasonable fit using this equation:

unitSales = totalPaidApps * ((1 + rank) ^ -1.0) - 1.5

with a steeper exponent of -1.0 instead of Ajnaware’s estimate of -0.75. (The carat symbol is old fashioned Basic syntax for the infix exponentiation operator.) I also ignore negative sales due to the small bias subtracted from the curve. The curve fits thousands of sales per day for a top 100 app, 100's of sales per day for a top 1000 app, but less than 10$ per day for apps below the top 15%, and less than 1 sale per day for the median or 50th-percentile popularity app. Given 265,000 total paid apps, this curve integrates to almost 3 million paid app sales per day, or over $140M in app sales per month if the average app price is $1.65. So my guess is that this equation is at least correct within an order of magnitude.

Power law curves are very different from bell curves. There is no central tendency average. So asking other developers about the average number of sales to expect is fairly useless, because the mean is so far from the median. There seem to be no average apps, only a few winners and a huge number of losers, maybe with odds and payoffs more similar to a game of roulette than a predictable business opportunity for developing new apps.

(Graph and some commentary added on 2011-July-24)

Added 2012-July-26:
Here are some results from an iOS game developers survey, which show a similar revenue distribution curve: http://www.streamingcolour.com/blog/2011/09/28/results-ios-game-revenue-survey/ 

iPhone programming - How to play a tone at a given frequency

Many novice developers expect some sort of way to play a simple tone of a chosen frequency, maybe using an API similar to playTone(someFrequency, someDuration). However, nothing like this is available in the stock iOS SDK frameworks.

It's easy to generate sine waves if one understands sampled sound. The most common sample format is 44100 samples per second, with each sample being a signed integer between -32767 and 32767. If one could push samples to the iOS audio system, it would look like this:

len = secondsDuration / sampleRate;
for (int i=0; i<len; i++) {
  sample = volume * sinf(2.0*M_PI * i * myFrequency/sampleRate);
  sendToAudio(sample);
}

However, iOS and Cocoa Touch use the event driven design pattern. An app can't push samples to the audio system. Instead, the audio systems asks you for some number of samples when it is good and ready. Your app just sets up the audio and waits to get called. Here is an example RemoteIO audio buffer callback:

float f  = myDesiredFrequency;
float v  = myVolume;  // in the range 0.0 to 32767.0
float sr = sampleRate;
float a, da;
int   b, n;
short int *p;

a = ...
da = 2.0 * M_PI * f / sr;  // delta phase per sample

for (b = 0; b < ioData->mNumberBuffers; b++) {
  // number of 16 bit packets in each buffer
  n = ioData->mBuffers[b].mDataByteSize / 2; 
  // pointer to sample buffer
  p = (short int *)ioData->mBuffers[b].mData; 
  
  for (int i = 0; i < n; i++) {
    p[i] = v * sinf(a);   // single precision
    a = a + da;    // update phase
    if (a > 2.0 * M_PI) { 
      a -= 2.0 * M_PI;   // and range reduce
    }
  }
}

Note that the above code snippet doesn't show where variable a, the phase, is initialized. The phase angle a should be saved between callbacks so that there is no discontinuity in the sinewave phase between each audio buffer. I'll leave that here as an exercise for the student.

I used to question including the call to the transcendental function sin() inside a audio inner loop as something far too slow for an audio callback. But a little benchmarking on an actual iPhone showed that calling the single precision sinf() for every audio sample actually uses less than 1% of the CPU time, and really isn't that much slower than something like an interpolated wave table lookup.

If you don't know how to set up the RemoteIO Audio Unit to call your app, here's a blog article on Using the RemoteIO Audio Unit (by Michael Tyson at Tasty Pixel), and here is Apple's Documentation on the RemoteIO Audio Unit. Don't forget to set up a suitable audio session for your app as well, using the iOS Audio Session APIs.

HotPaw Productions Announces Music Spectrograph for iOS

Santa Clara, CA - HotPaw Productions announces Music Spectrograph 1.0, now available from Apple's iTunes App store. The Music Spectrograph piano-roll-style music visualization will help anyone learn more about the music they hear, using their sense of vision as well. This iOS app uses real-time signal processing on audio from the microphone input to display a scrolling 12th-octave spectrogram, with each band centered on a musical note. Visualize speech and singing. See musical notes (plus all their overtones) graphed like a piano roll to assist with music transcription.

The app can be used for speech therapy, music education, vocal training, learning to sing on pitch and in key, finding which notes are hidden inside chords, or just watching the rise and fall and the pitch and overtones within the sounds around you.

Mrs. Nicholson says: "Wow, that's a really cool looking app. What's it do?". The developer's cats just looked at the app and went back to napping (as it obviously wasn't a mouse or a bird).

Ron Nicholson founded HotPaw Productions in 1999, first developing mobile apps for PalmOS devices, and has been developing iOS apps since the App store first opened. There are over 20 iPhone and iPad apps developed by HotPaw Productions the iOS App store, including the inTuna Strobe Guitar Tuner, Sing-inTuna, and HotPaw Basic. Copyright (C) 2011 HotPaw Productions. All Rights Reserved. Apple, iTunes, iPhone and iPad are registered trademarks of Apple Inc. in the U.S. and/or other countries.

###

Ron Nicholson
Developer
rhn@hotpaw.com

HotPaw Website Major Update

The HotPaw website has been completely updated, with new css, and a new 3-column look. Many thanks to lizdesign for the web site design and many of the icons, including: