by Sebastian Dittmann

The manager of an open air rock concert calls a specialist to install a light show with lasers, additional spotlights - a whole visual entertainment system to turn the concert into an exceptional audiovisual experience for the audience.

The specialist works on this for months, talks with artists about which features they might like, makes plans and comes up with a concept that is liked by everyone involved. He implements it together with his employees (he’s the owner a small company specializing in this kind of work) over the course of weeks, tests it, rearranges some of the stage setup for it to work beautifully.

When it’s time to get paid for his work, the manager of the rock concert tells him:

“Sorry buddy, the electric framework needed for what you did there was already in place before you I called you to do this. You’re just building on top of that, how dare you charge money for this? You didn’t invent the fuses, cables, spotlights, you’re just using them and rearranging them a little.”

That’s exactly what we were told by Apple when we tried to sell a feature via a store inside of our app SoundPrism. This feature is based on a framework that is part of iOS since version 4.2.

These are the words they used:

“The application is using In App purchase to unlock the use of the Apple Camera Connection Kit, which then enables MIDI Support.

It would be appropriate to revise this In App Purchase product to provide functionality other than what the iOS provides; or to remove it.”

Our submission was rejected.

This statement shows that the person who reviewed this was thinking exactly like the manager in the story above. I’m sure that person didn’t mean us any harm, it’s more likely that the reviewer doesn’t understand what the implementation of a framework means. They (as well as some music blogs) might assume that it’s just as easy as flicking a switch.

In fact, the wording of this statement shows that they think unlocking the Camera Connection Kit enables MIDI Support. Which is absolutely untrue. Plug in the Camera Connection Kit into your iPad while it’s running any music app and then see if the app ‘magically’ sends out MIDI information. If the application developers didn’t support it in the first place - which means they  had to write the code for it - then nothing happens at all.

I’ve tried to contact App Review multiple times over the course of the last days but I haven’t received any answer from them regarding this matter.

But there’s a more important aspect to this.

It seems like the section of the App Review guidelines forbids to sell any implementation that unlocks a framework provided by iOS. The wording from the actual guideline is:

That sounds like it’s only limited to hardware features. But with the rejection of our IAP for Core MIDI (which is not based on hardware at all) this has far fetching implications.

It means that iOS developers cannot - ever - charge via InApp Purchase for a feature that is based on a framework supplied by Apple’s iOS.

That means that a photo app cannot for example offer an additional video feature that uses the Core Video framework as a purchase in that application. An ebook reader app cannot charge for an audio book feature because it’s based on Core Audio via IAP.

Developers of these apps would have to release completely new apps with that feature and offer them separately if they want to make up for development costs - instead of improving their existing ones. Customers of the initial application would have to buy the new one instead of being able to decide if they need the feature or not and just buying it separately within the app.

I sincerely hope someone with a connection to the App Review team reads this and manages to persuade them to reconsider this part of the guidelines.

Sebastian Dittmann

CEO Audanika GmbH

mail: sebastian dot dittmann [at] audanika dot com

by Sebastian Dittmann

Not being told what’s going on is always a bad starting point. Knowing that you’re not being told what’s going on is even worse. Trying to find it out on your own is usually complicated, creates tension and most likely leaves a bad aftertaste.

That’s exactly what’s going on right now with some developers for iOS. I’m talking about Apple not telling them why their apps aren’t being reviewed for a long time. And if they’re reviewed the review seems to take a lot more time until approval.

This might not sound like a big deal but in fact it is. It has the potential to severely hamper the iOS ecosystem. And since the iOS ecosystem is pretty much the only economically relevant mobile ecosystem at the moment it’s a big deal for mobile.

So lets talk about details.

Then…

This is how things were: You would develop an application, submit it to Apple, wait for a week at most then your application would change status from ‘waiting for review’ to ‘in review’. Then you’d wait another day and your app would be approved and you could sell it. Hardly ever would it take more than a couple hours to have your app approved after being in review. Sometimes process from submission to approval would take only two days. Great stuff!

and now.

This is situation for some (not yet all) developers: Develop an application, submit it to Apple. Wait for a week to ten days (or more?) for the application to switch status from ‘waiting for review’ to ‘in review’. Then you wait a day. Then another. And another. Then you start writing emails to the App Review Team asking them what’s going on and if there’s some bug that they’ve found and if they can give you any insight into the progress of the review. 

Apple will send you an automated(?) reply that they need more time. No details.

You wait for another day, and another… it’s a week now. You write another email to request an expedited review because your customers have now been waiting for more than 20 days since you’ve announced submission to Apple. They’re writing emails to you asking why Apple is taking so long. Videos from betatesters of your app are appearing on the web because they can’t wait anymore and want to show off their creations.

Apple answers to your second mail with another reply that lacks any substance or real information.

Asking around

Then you’re making calls to friends, trying to find out what’s going on. Turns out the Apple Review team is busy with all the submissions from the Mac App Store since Mac OS software developers are now finding out that App Stores are pretty neat.

Can you imagine how many submissions of regular Mac OS Apps must be happening as I write this? I can’t. More than ten years of Mac OS X development all over the world and every single one of these developers all of a sudden sees a chance to make (more) money with their applications.

The Bottleneck

So we’ve got a bottleneck here: App Review. Since Apple wants a walled garden for their iOS and Mac App Store ecosystems they will have to stick with reviewing each and every single app.

Even if the review team could handle the flood of Mac and iOS submissions right now without huge delays (which they can’t) - there’s another problem looming and it’s name is ‘In App Sales’.

Show me the money!

As of this year revenue from sales within apps has surpassed regular sales of apps. That means more money is made from selling stuff within an application than by selling the app itself. That’s why some apps are completely free but charge for important features (Wordlens being an example for that).

We’re going to offer In App Sales in SoundPrism (our own app) as well and since we’ve added this feature I’ve noticed something interesting in our team.

Our developers were all of a sudden coming to me with ideas of how to monetize features. Really good ideas, simple, feasible, easy to implement. Before that we would have to create a new application for every feature, which is bad for our customers, tricky to handle, a nightmare to support.

But let me emphasize this again: the tech guys were thinking about how to monetize features. And they were having fun with that. 

A flood of submissions

Usually thinking about that is the job of the business people. Many development teams on the App Store most likely don’t even have business people in their team. 

But when techies start having fun with thinking about how to monetize their work that means there’s going to be a lot more submissions for small features.

So we’re looking at a future that looks like this: more apps with InApp Stores, a lot more submissions for these InApp Stores by more people developers because monetizing your ideas has never been easier.

Monoculture

Most of this has to be handled by one company - Apple - because they’ve got the only ecosystem for which developing apps makes sense financially. At least until Android revenue surpasses roughly 20% of iOS revenue (which we might see in 2011).

Apple really has to begin to talk with their developers - and the public - about their App Store and their internal review process to make life easier for teams like ours. Their current way of handling this leaves developers in the dark about what’s going on, how potential problems like the one described above will be tackled. Otherwise it’s incredibly hard to plan for releases, marketing measures, tests.

More and better communication by Apple is needed.