Yesterday, I talked about two complaints of music developers writing applications for the iPhone. These come from developers who are really iPhone fans, who just want to get their software released and (for many music devs) better categorized on Apple’s store. Pajamahouse Studios, maker of the new Sonorasaurus remix application, follow up with a more detailed explanation of their situation.

These are not rejections; at least rejections are generally accompanied with some sort of suggestion of what would need to be changed. They represent the dreaded iPhone developer “limbo,” in which an application is neither rejected nor approved. For Sonorasaurus, that’s been the state of affairs for over two months. As the developers explain, there seems to be nothing unusual about their app:

  • Library access: It doesn’t access the iPhone/iPod music library. (no application is allowed to do that, which incidentally limits a lot of the DJ app possibilities of the device) Clarification: The status of the music API itself is unclear; some developers report just this sort of approval delay when trying to use it. [Source] Also, access to files inside the media library is not directly possible, which can be compared to the status of Android.
  • File access: A separate http server is provided, with a parallel library, for users to store their own tracks – again, something found on numerous other approved applications. This doesn’t use the included library.
  • Included music / music distribution: Five included songs are for testing only – something found in a number of other, similar applications that have been approved. The application is not an alternative to iTunes for distribution.
  • Media decoding: Custom MP3 decoding technology – something not provided on the iPhone – was separately licensed. Clarification: This was not meant to imply that you can’t do MP3 decoding; the developers meant to make the point that they were not violating patents or licensing by using their own decoding, which presumably they did for the purposes of building a DJ app.

Of course, whatever the reason, we’ve seen in past applications suddenly approved after weeks or months, so who knows what will actually happen with this app.

Read the full explanation:

In Limbo Pt. 1 [Sonorasaurus]

While reading that, though, I also have to observe how significant these workarounds are. Without launching into an Android versus iPhone debate – believe me, there are many, many things to criticize about the Android as a platform, especially relative to music –  none of these is an issue on the Android. Forget platform wars or fanboys. Alternatives are good. I’d hope that we do have more than one approach to how to do this. These approaches should have to compete with one another, as they offer different tradeoffs and advantages.

If music is becoming an application, this kind of freedom is important.

Point by point:

  • Library access: Android’s standard, supported APIs provide access to the media library and user playlists. Clarification: this includes direct access to the files and the ability to read from the buffer of these files (with some effort), in public, documented, approved APIs, with no chance of having an app rejected for the use of these APIs. My understanding is that this is not exactly the case on the iPhone.
  • File access: Users are free to put files on their SD card over USB, and off-load those files – neither possible on iPhone. And yes, these will be integrated with the media library; iTunes-style sync isn’t necessary.
  • Included music / music distribution: Including songs is actually a bit of a challenge, but you can freely download content and store it on the SD card. Because Google doesn’t have an equivalent of iTunes, that includes creating your own alternative distribution methods – meaning a label or music store can do make their own outlet.
  • Media decoding: Decoding technology is included on the phone, including the ability to decode the open OGG Vorbis format. Clarification: Some folks read this to mean that the iPhone can’t decode MP3s, which was not what I intended; the key point here is that Android has in-box support for free formats and byte-level access to the audio buffers they give you, by default, straight out of the user’s media library. That is not entirely the case on iPhone.


More mobiles means more different ideas about how to distribute music and creative applications. Photo (CC) Jose A. Gelado.

Beneath all of this is the major fundamental difference, which is that you can install applications for Android whether or not they’ve been approved for Android. There’s actually a checkbox in the Market that allows you to opt into installing other apps you’ve downloaded directly from a developer or from another source.

Again, I don’t mean to make a pro-Android argument. In fact, I believe many of these items are also true on Windows Mobile, Symbian, and upcoming Linux platforms; I just happen to be working on Android now, so I’m more familiar with it.

What’s important is that this represents an alternative approach to how to provide music as an application, one in which the user is free to load content on and off the device.

Specifically, this paragraph jumped out at me:

Another problem would be that Apple could see this as a means to circumvent iTunes as a means to sell and distribute music. This we also addressed. These songs can only be used within the App. They can not be removed from the app / device for use elsewhere (iTunes on the desktop, burning to a CD, etc).

Now, we hear from many developers that the iTunes integration is something that attracts them to the platform. Likewise, many content creators will want just these sorts of restrictions.

But what if you want fewer restrictions? Let’s say you’re an artist releasing Creative Commons-licensed tracks, and you want to encourage remixing, sampling, modification, and free use of your tracks. Or what if you’re a label or artist collective, and want to experiment with new ways of using mobile for distribution, beyond what’s possible with iTunes and Apple’s stores? The same qualities that may attract someone else should, I think, concern you. I don’t think that necessarily means you shouldn’t write an iPhone application with your music, but perhaps you should also consider trying an alternative platform.

There seems to be a growing sense that the iPhone Way is The Only Way. Obviously, that’s not the case. This very debate demonstrates just how much room for interpretation the distribution of content can produce.

  • well, i have an iphone. i believe it is a wonderfully designed device andhas definitely changed the game,but iam currently waiting for that inevitable tipping point in android build and software quality,at which point, i will be giving my.iphone to one of my nieces.

    I still dontunderstand why they do it. they create amazing amzing devices (GUI, newton, itunes,etc) but they always think they are so clever that noone will ever match their "brilliance"until someone inevitably does,then they are left scrambling (windows, palmpilot,???)

    even after jailbreaking my phone, the amount of work arounds to do normal stuff is cringe inducing. why do i have to sync to 3rd party apps by wifi instead of the sync cable?!? its retarded! and DJ apps are the killer app IMO. if these developers are smart, they will start porting to andriod as well as cydia and the inevitable flood of people moving in those directions will, as has been usual with apple up to this point,help them, "see the light".

    I predict that by next holiday season, the articles will be discussing how apple lost so much marketshare and developer support to google so quickly. good riddance.


  • boonier

    fair point @onyxashanti, but are folk like us really a significant part of their market share? I think the number of power-users that want to use their iphones for stuff like this is miniscule compared with the more general users that have disposible income to purchased tracks through itunes.

    At the risk of over generalizing i'd say that the majority of users don't care about whether the music comes from itunes or where-ever, and the fact that it syncs to their computer is a matter of convenience. That i think is Apple game tactic, and has been for a while.

    I agree that they shouldn't restrict choice and freedom and its a shame that you have to unlock a device and lose a whole bunch of functionality as a penalty.

    I'm in the confusing place at the moment of not having a smartphone and not knowing which to get as a power user.

    Android is appealing, but I wish that the alternative iphones didn't look so shite also 🙂

  • At the risk of revealing how my last Saturday night unfolded, I know firsthand that the Power Music Hour app, which plays a different song every minute, has access to the onboard music library…

  • @Vijith: Really? Do you know if it's using a private API?

  • Yeah, playlists and everything, but I have no idea how they're going about it.

  • There are obviously a lot of issue that could be involved with the hang up. No one but Apple knows. And that's really not acceptable.

    A clarifications is in order though:

    First of all the iPhone/iPod 3.0 MOST DEFINITELY DOES allow apps access to the music library and playlists. (I've implemented this in my new music app so you can "play along" with your favorite music.) An app however doesn't have access to the physical files. The implementation allows an app to do almost anything that the built-in iPod/Music app can do. But since you can only play one song at a time, and you don't have access to the music data stream this is probably not sufficient for a sophisticated DJ-ing app using a traditional DJ metaphor. It does however support mix-in applications like mine to mix synthesized audio with anything in the music library.

  • Richard: Fair enough; I've clarified the story.

    I don't believe the state of the iPhone/iPod 3.0 is directly comparable to Android, however. There's question about whether the use of the music API can delay the apps. There's not access to the library itself, or files inside the library — both of which are possible, public, and documented on recent Android releases. (You can read from the buffer of a file in the media library and place a file inside the media library.) And you can move files in and out of that library over USB, with direct file system access.

    General observation: this may not seem like something of interest to end users, but you can bet that — whether users appreciate what's happening under the hood or not — they'll wonder "hey, why can't I do xx…" Perhaps they're not interested in manual sync, or think they're not — until they realize they have to run a special app just to move stuff onto the device, since Apple *also* doesn't provide developers access to iTunes. So I think these are worth considering as more than just a developer issue, or an academic/theoretical discussion.

    Again, some of the criticisms of the Android have to stand up to the same test. Most end users don't care about things like audio drivers or latency …until an app behaves in a way that feels wrong to them, or isn't responsive, etc.

  • Whether its using a separate API or not, It has little to do with this issue. This seems to revolve around apps that are used mix or play (in a performance setting) previously recorded music. The thinking seems to be if you are listening to someone play someone elses music you are not buying from iTunes.

    To add insult to this they have just released Touch DJ. While Sonasaurus remains "in review". This is really unfortunate as they would likely cater to different people. Touch DJ is specifically recommended on the 3GS and the 3rd gen touch. Meaning it has soft requirements for a newer more expensive iPod while Sonasaurus would likely perform beautifully on a second gen. It looks like it has less graphical overhead and would seem to have a feature set that pro djs could use quite nicely.

    I would hate to see an app like Sonasaurus covered up because iTMS seem to be playing favorites.

  • The iPod Library Access Programming Guide


    I was particularly excited by the addition of this functionality to the iPhone as I've been fascinated by the issue since Donald Bell put forth a challenge a few years ago to create alternatives to the "iPod" with specialized interfaces for specific applications and uses. I think he was addressing hardware developers (and we've seen some of that, most notably with the Pacemaker), but clearly a lot of those alternatives can be done in software when you have access to all of the functionality of the iPod through an programmable interface and a programmable multi-touch interface.

    (One caveat: I don't know if the Genius feature is controllable through this API. Otherwise, all of the built-in iPod/Music app functionality is present.)

  • Correct, but the concern is that Apple is publishing and documenting an API only to leave applications that use it unapproved. Without any specific information from Apple, it's impossible to know whether that perception is correct, but the reality remains — developers *think* they're going about this the correct way, but their apps aren't being approved. Now, perhaps it's coincidence and it's just the delays (11 months, huh?) in the store itself, but even that would be another problem.

    Also, see above comparisons of the way this media API works and the ability to actually access files and buffers on Android. And this still leaves the question of just where the line falls that you're seen as "competing" with iTunes.

  • > …tapku…

    My app PatternMusic is evidence to the contrary to that tapku piece and other conspiracy theories. PatternMusic makes heavy use of the iPhone's "iPod Library Access" SDK functionality, and was approved for sale by Apple in 9-days – ahead of my schedule.

    In the interest of full disclosure, I was extremely careful to avoid Apple intellectual property issues for icons and trademarks and ended up using a button labeled "MP3" rather than an iPod icon as originally planned – use of Apple-owned icons, artwork and trademarks is a well-known App Store approval gotcha.

  • Kevin Connor

    Hi RichardL, thanks for good link.

    Do you happen to know if it is possible do any kind of DSP on the bitstreams using this or a related API? AudioUnits or otherwise. I'm still waiting after 2 years for a plain little 5-band graphic EQ for playback, just like on my ancient, much loved Aiwa HS-G08 walkman. It's such an obvious thing to add to the ipod app. Do you know of any way to touch the bits as they are being played out? Any app that requires files to be loaded into special playlists on the host are just unworkable. Thanks.

  • @Peter

    The tapku app was approved for sale by Apple a couple weeks after that blog post and has been updated (thus re-approved) since.

    @Kevin Connor

    No. You can't do any processing of the iPod library streams. You don't have access to the audio buffers for iPod content. This is a clear distinction from the kinds of things you can apparently do on Adroid. I don't know whether that's just theoretical and how much is actually do-able. Peter?

    However iPhone apps do have access to everything in iTunes (even dreaded DRM'ed media tracks, podcasts, video). Yes iTunes is not everyone's ideal media solution. But let's not ignore the fact that iTunes is the elephant in the room. That's were most people have all their media.

    Playlists can be generated on the device either programatically based on search queries or through the Apple-provided on-the-go picker user interface.

    Another point of clarification is that the iPhone SDK doesn't allow for playback of media files physically controlled by the app. Encoded media file playback and internet transmission is a complicated issue with some legal entanglements from Thomson, but I suspect those issues would be similar on Android. Apple's Core Audio does provide a lot of codecs without need for licenses. And of course the OSS OGG Vorbis is available to iPhone developers too.

  • Correction: iPhone SDK 3.0's iPod Library Access DOES NOT allow access to video content in the user's iPod library. (The SDK does support video playback and streaming but not iTunes video.) Sorry for the confusion.

  • You guys both make great points….

    The real people you need to POKE IN THE ASS are the developers. Listen, nobody is developing these AWESOME musical apps for ANYTHING but the iPhone.

    You can argue that it's market share this or that, but the sad fact is the devs are making these things FOR the iPhone and really not much else as far as I've seen.

    Apple has it's grips on tight sure but if the devs said a collective F U to Apple and created their OWN platform to put stuff out then it would be Apple with their nuts in a vice not that other way around.

    Until there are nice little dev kits and such to make those "lazy" devs(completely joking I am a programmer myself or was) create awesome apps on OTHER platforms, maybe there are now. Just seems they flock to Apple and it can't be ALL about market share when there are huge markets for things like Blackberry, tons of Samsung phones and YES Android and Droid and products based off droidian tech if you want to call it that.

    They NEED developers and until the devs have had enough with Apple's ways then and only then will you see significant musical products being made any ANYTHING besides an Apple iPhone.

    Look how long it took the PC to even compete with an Apple MacBook or a G4 or G5 in terms of music production software and capabilities… I'd say that just happened in the last 10 years, in the 90's you certainly could make some great stuff on a PC but it was SHITE compared to what you could do on a Mac. That's a fact.

    So give it time, and tell every dev you can that hey, "Why not try porting your sweet app over to Android OS or some other possible popular platform/device because I hate the iPhone & Apple!" Then the devs will KNOW there's a market for people like yourself and they WILL start doing these things.

    But devs need to make money and not everyone can be a game designer at EA for more then 6 months if their sane. So, we decide to program games for cell phones and such and well the money is with the iStore at the moment. So until you can convice developers of apps that it's worth porting or even strictly making apps for anything other then the iPhone well you're just puffing hot air…

    Great read and good comments above mine. We need to talk about this more, monopoly was a shitty game and it's even worse in real life. 🙂

  • Sorry meant to say you all make great points. But I'm sure you know that. lol

  • I have very little doubt we will see new music things finally start to appear on the Android (or at least some of Android), but there have been problems.

    Fragmentation is not the least of them.

    My iPhone app uses FMOD — a lead which I picked up here on CDM. FMOD probably supports more platforms than any other audio library, but it doesn't support Android. Why? Because the Android device baseline spec doesn't provide the floating point processor nor a DSP which FMOD needs.

    Not all Android devices are created equal. Most Android hardware devices up until just recently have not had a floating point or DSP unit. Droid and some other new devices do address this issue and level the playing field. The question then becomes does Android == the Droid? We'll have to see how that plays out.

    There are many more reasons than just draconian control and an alleged iTunes monopoly why iPhone is currently dominating mobile music.

  • Oleg Yotymarr

    Fanboi's will continue to make excuses but the proof is in the pudding – the openness of Apple will continue to hurt sales. Until Apple recinds their ridiculous offer of painstakingly reviewing the source codes line by line, there will not be much hope. Let's hear it for Android – this is how Apple will feel without the cheearleading.

  • Oleg Yotymarr

    By the way, I love Sonar and Cubase and have an iPhone.

  • Gavin@FAW

    You have to ask the question though why developers are not doing cool things for android?

  • @RichardL: Will try to answer these queries; you definitely know more about the iPhone than I do, but I can try to cover the Android bases.

    You have byte-level access on Android to all video, audio, and image assets as well as the microphone and camera. Using java.nio, you can then process those buffers directly, or bounce them over to the NDK and process them in native code.

    I'm not entirely sure what you mean by "files physically controlled by the app" — you mean, assets distributed with the app? Android uses the apk file format, and I think it isn't necessarily possible to get at those assets. Now here's where the twist is, and it isn't necessarily a win for Android. Right now, those apk files are restricted in size both in distribution and in the way in which they're loaded on the device. So, let's say you want to load some big media files. Right now, the only way to do that is to load them, uncompressed and unencrypted, onto the SD card. I need to experiment with this some more, but my general sense is that's be really good for CC-licensed content and not so good for everything else. On the other hand, a whole lot of PC games distribute their audio files in user-readable formats, even when they're Copyrighted. So, the only real disadvantage here is that Android needs better ways of bundling bigger assets for distribution.

    OGG Vorbis: well, it's nice to have free and open source implementations of these out of the box, complete with APIs ready to use them.

    Fragmentation / FMOD: really two issues here, if related ones, one being the resistance of Android to native code and the other being hardware fragmentation. Libraries like FMOD have certainly appeared on other mobile platforms that did have different hardware. But even on fragmentation, that doesn't make things impossible — just a bit trickier. Now, I think the fact that it's open source becomes really essential, because it helps you find solutions that run across hardware. Pd already has a version that works in both floating-point and *native* integer modes. Someone has also gotten SuperCollider running on Android.


    Why are developers not doing cool things for Android? Well, I think some are, like Layar, while others hit the iPhone first because it was available first.

    But the other reasons seem pretty obvious:

    * the platform's only a year old

    * units are only starting to ship in larger quantities … which means developers may only now be getting their first phone, and I do find developers develop for what they own

    * there are still some rough edges on the development side — sometimes it just doesn't perform as well as the iPhone, etc., and sometimes it just takes more work

    Mobile developers know every platform has its frustrations and challenges, though. I'd give the whole situation time. And I'm still not sure just what the landscape will look like down the road. It's internationally still dominated by Symbian, a hugely popular platform that has very little in the way of interesting software. iPhone clearly has its niche, but where the mass-market stuff goes is up in the air. Symbian, Android, or (some other flavor of) Linux?

  • Gavin@FAW

    The image you posted of all the phones is the main reason I think!

    For independent developers, who make the Apple App store what it is,

    its just too much to make sure your app works well on all these different devices, with different screen size's, some touch some not etc. For apps like twitter or facebook clients, sure its fine, but more complex audio apps then you could be opening a pandoras box for yourself very fast!

  • @Gavin: I have to *strongly* disagree. The ability to run on more phones is a good thing, for the same reason that it's great to run on multiple PCs (or Macs). Android is doing more to bring devices together than pull them apart. You have very consistent graphics systems, input, sensors, OpenGL capabilities, all in APIs that do the work of being compatible across devices.

    And I'm sorry, anyone whose app I want to USE is going to be able to create something that works at more than one display resolution. It's not rocket science.

    Audio — yes, that does become more of a significant issue, but again, not necessarily because of fragmentation. The problem is that it's just a heck of a lot easier to code an audio app on iPhone (or Windows Mobile, as it happens) than it is on Android because Android doesn't have real native programming for audio, or Core Audio, etc. It's not impossible, but it is a lot harder.

    Now if we got Pd running properly on Android, that'd be a different story. And incidentally, Pd really does prove that hardware compatibility is not the enemy. PDanywhere runs happily on everything from ancient iPods to PocketPCs to — yes — the iPhone.

    Do you have to do more work to support more than one device than just one device? Yeah, of course. But you also get more devices on which to run, and it's not impossible.

    Nor is iPhone immune. I think it's inevitable that we'll have an iPhone with a different display resolution (more like the high-resolution screen on the Droid), and perhaps even a tablet. We already have fragmentation in terms of the mic input, the camera, and the OpenGL capabilities. Other generational differences will emerge. At least Android is *starting out* with robust tools for adapting to different devices.

    My complaints with Android — inconsistent performance, a desperate need for JIT compilation for Java, better tools for working with native code, and a need for more robust multitouch and audio APIs, as well as a less-clumsy bridge to OpenGL. But not having too many devices — that is a draw to me.

  • Gavin@FAW

    All very valid Peter.

    The point I was making is that for independent developers doing apps in their spare time, which is where alot of the success of the app store has come from, the iPhone is perfect. You have single device to build for, well documented apis, single screen size…Apple created the perfect storm so to speak and it works and is an great success. No doubt about it.

    Android at the moment though just seems abit half baked in comparison. If you then add in all the different devices, processors speeds, multi-touch on some not on others, different screen sizes…it just makes it not worth the effort for alot of independent devs, which is why they are not getting anywhere near the critical mass of applications needed to challenge the Apple App store.

  • Hey! Check out this cool photo tagging software called Fotobounce! It can help you sort your images using face recognition! It can also download & tag your photos from facebook & flickr! You can even use it from your cellphone, get it for free at:

  • Already I've had to confront fragmentation on the iPhone, and it's a significant hurdle for an indi developer. (I had to buy an iPhone EDGE on eBay to nail down some memory and resource issues specific to that device.)

    The first two iPhone models have a relatively small heap compared to the iPod touches and the 3GS. So that means you need to run a much tighter ship to create a sophisticated app that supports the first two iPhones. (The iPhone 3G is still on the market!)

    Obviously CPU capabilities are drastically different between a 412MHz armv6 CPU (iPhone, 3G, iPod 1st gen), 512MHz armv6 (2nd gen iPod touch) and a 600 MHz armv7/NEON CPU (3GS and 3rd gen iPod). Dog fooding (developing on the target device) is essential to the development process if you expect to support the whole range.

    As mentioned hardware capabilities vary and are limited too — mic, speakers, camera, video, GPS, compass, EDGE vs 3G cellular network vs Wifi, hardware audio decoding and encoding capabilities.

    I am fascinated by your mentioning Ogg Vorbis as I tried to use that codec early on in my development process. It sounds good on paper, it's not difficult to get working, quality is great and it's pain-free from a legal perspective, but then when you look at the CPU usage of realtime decoding a couple streams of Ogg Vorbis audio in software you'll quickly learn things are not so simple. You still have DSP processing and a user interface to run and you can't glitch the audio. Efficient audio decoding and encoding is critical if you expect to manage CPU and battery power.

    The point, I guess, is none of this is simple. Fragmentation is a particularly challenging issue for indi developers. I suspect we may start to see more services popping up offering multi-device app testing and validation particularly for Android if the device landscape for that platform gets as complex as is currently predicted.

  • Well, just to clarify, I'm not saying fragmentation and hardware specs aren't a challenge. I'm just saying they're not necessarily Android's biggest problem, the iPhone is clearly not immune, and I don't think you need to own every single phone. I think you can control for variables. Hopefully what we'll see soon is non-phone devices running Android, too, and then what you have — testing and targeting wise — is something more akin to desktop development. Yes, it'll have all the unpredictability of desktop development, but you'll also have gadgets with a range of capabilities for a range of different devices and not all of them will require punishing cell phone contracts to buy.

  • @Peter > …non-phone devices running Android…

    The recently announced Barnes & Noble Nook eBook reader is Android.

    It's a perfect example of the flexibility of the Android model. It's also a good example illustrating the paradox of talking about Android as if it was a single target. That device is a special purpose device and is constrained to a single application — eBook reading, and I don't think it will run "apps".

    By the way, a similar sized device with a color touchscreen targeted at hand-held music production would be really intriguing though. Anyone want to build it, please?

  • RichardL – yep, exactly agreed. Oh, and B&N says they would like to do "an SDK." I'm not sure what that would entail; I guess they're in an Apple-esque position where they don't want to threaten their own store. But I'm hopeful we'll be able to develop Android apps for their device, which would be amazing.

    A color touchscreen, Star Trek TNG-style tablet, seems inevitable to me. And the multitouch support is there. And, yes, this means the possibility to get devices that Boldly Go Where Apple Has No Real Interest Going.

    Again, the iPhone really does some things much, much better than Android – no argument there. So I hope we see more growth and development on both sides.

  • Pingback: Create Digital Music » TouchDJ Arrives for iPhone()

  • Just for reference, it's not just us in music/art arena that are fed up with Apple about this issue. Internet/Tech heavy-weight Paul Graham recently wrote an article called "Apple's Mistake" at

  • Hey,

    Just wanted to let everyone know the app was finally approved today. We spent the last few days sorting out some legal issues and after that hurdle we were approved and released.


  • Pingback: App Rejections » Blog Archive » APPROVED: Sonorasaurus, Touch DJ (after 70 days)()

  • Pingback: Un site pour voir les App lphone rejetées « V4.1()

  • Just got an Android phone from Santa… so the days of skipping over posts devoted to phone apps are over. Would like to see more Android posts. 🙂