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.”
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
