by Sebastian Dittmann

Today I’m going to share the somewhat darker side of being an app developer for Apple’s iOS platform by telling you about the black box that is the App Review. The institution within the Apple ecosystem that developers send their applications to for them to be reviewed by the wise and wary eyes of  men and women working to protect he public from malicious apps that break the rules of Apple.

These men and women adhere to a set of rules that is ever changing. They’re called the App Review guidelines and they’re your bible if you decide to become a developer for iOS.

These rules help you - the aspiring developer - guess what the App Review team might find OK and what they might not quite like. 

And you want to please them, oh, do you want to make sure they’re happy when opening and testing your app. 

 Because if they are not, your app is going to get rejected. Your update won’t be online any time soon time. Your bug fix won’t be live and you’ll receive more complaints, bad ratings etc. 

There’s a process that you can use to complain about a rejection but that entering process means you cannot submit any new update in the mean time. Which is not what you’re going to do because it’ll take a lot longer than if you just change your app and resubmit it.

And you will not - ever - be able to reason with them outside of this process as you would be able to with a colleague or business partner. 

Instead they will answer with almost fully predefined text blocks which most likely have been written by Apple’s legal department. 

You cannot talk with them before submitting an app, you can’t ask them what they think about your implementation.

They have no telephone number. No real email address that they answer with anything else by short blurts of predefined text. You cannot send them a fax or a letter. You can call developer support and ask how to get through to App Review. They will tell you that App Review has no phone, no way to be reached. Only a little box in the submission form that you can try to squeeze in some info for App Review to maybe read - you’ll never know if they actually did.

Don’t call us, we’ll call you

Because if they could be reached, a hundred thousand development teams would try to reach App Review and try to explain why their newest update needs to be let through. Why their app is going to be awesome and thus must be approved.

It’s the one bottleneck the iOS ecosystem has and the more developers there are, the more apps there are, the more updates they submit, the more in-App Purchases they need  App Review to approve, the more of a bottleneck it becomes.

It’s an understandable policy that App Review cannot really be reached, not really be reasoned with in advance and it’s understandable that they won’t answer with anything but short messages of predefined text.

But it sucks. 

Boy does it suck if you’re a developer.

And it’s frustrating because in my opinion developers should be entitled to be able to have a real conversation with the person who judges their work if Apple receives 30% of the revenue (which is ok, the iOS ecosystem is great and Apple deserves that share for creating and maintaining it).

The Deadline

It sucks even more if you have an actual deadline. Like - as it happens - we do right now:

The biggest newspaper in Germany has contacted us to provide them with a version of our app that they can show in their next issue of the personal computer magazine section that they publish. We’re talking about roughly 600.000 readers from three countries. 

So we made that special version and submitted it to Apple in time. 

The Plea

To make extra super sure that it’s going to be online later this month I furthermore submitted a plea to Apple via intricate means offered by their intricate contact system for developers. 

I sincerely asked for them to make sure to review it fast because this one is extra important to us. And since in mentioned support system there is an option that deals with exactly that case we had high hopes to have our app reviewed a bit faster so we could prepare for the minuscule chance that we would have to fix anything that App Review doesn’t like. 

My plea fell on deaf ears.

Which is almost funny because Apple seems to like us. Whenever we submit an update to our app we’re ending up in the ‘What’s hot section’ of the category our app belongs to.

Apple even had us make a special version of our app for them for internal use (though it seems like they never really ended up using it, but thanks - the request by Apple marketing was flattering enough for us to spend a week on making the demo version for them - so we could hold their deadline). 

 You could say we’ve got a hot-and-cold kind of relationship. Pun intended.

We’ve got a little more than a week until the special version of our app has to be approved by App Review. Wish us luck.

PS: To clarify - we’d pay almost any price for the opportunity to talk with App Review before beginning development of new feature. As it is right now it’s always a gamble to come up with a new feature or way of monetization only to have it denied by App Review after weeks of development and spending thousands of european monetary units on development. We’d like to think of our work as a craft. Gambling should not have to be a part of it.

UPDATE 1 (one day later): Just had a long conversation with developer support which seemed to have been constructive. Let’s see what comes out of it. I’ll keep you posted.

UPDATE 2: Also had a telephone call with the people at [important German newspaper] and we’ve figured out a Plan B together should we miss the deadline. Thank you people at [important German newspaper]!

UPDATE 3 (two days later): developer support called. They tried to inform me that there’s a form that developers can use to request an expedited review. Or write an email to App Review. Wow. Back to square one I guess.

UPDATE 4: SoundPrism CBE is being reviewed. Not sure if any of my mails or phone calls had anything to do with it. Most likely not since it’s happening a bit less than a week after we’ve submitted the binary to Apple which is the usual timeframe as of July 2011.

UPDATE 5: Updates to SoundPrism 2.1 and SoundPrism Pro 2.1 which we’ve submitted at the same time as this special version have been reviewed and approved. SoundPrism CBE is still in review. It shares literally all of the features of SoundPrism Standard with a special functionality for the readers of [important German newspaper] which has been used in dozens of other apps before. Oh well…

UPDATE 6: The eagle has (partially) landed. No communication with App Review but the app has been reviewed and approved.

UPDATE 7 (8 days later): I couldn’t make this up even if I wanted to. Apple approves a non-existing In-App Purchase. And informs me about it.

My reply:

And App Review replies:

From: App Review <appreview@apple.com>

To: Sebastian Dittmann

Subject: Re: Your in app purchase status is Ready for Sale

Please include the line below in follow-up emails for this request.

Follow-up:  xxxxxxxxx

Hello,

Thank you for contacting us regarding the review of  SoundPrism CBE.  In order to properly prioritize the review of your app, please let us know the reason, or reasons, for this request.

We will await your response before proceeding.

xxxxx

App Review Team

… never mind. I’m giving up. You guys win.

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

After Apple’s rejection of our new feature that we wanted to sell via InApp Purchase something dawned on me:

We will never be able to sell our work on new features if they’re based on technology - software or hardware - that Apple has just released without creating a new application specifically for that reason. Neither will any other iOS developer without breaking Section 11.8 of the App Review Guidelines.

That’s a huge difference to creating and selling software outside of the iOS ecosystem. If you’re part of Apple’s ecosystem you can’t charge for updates. Neither through having users paying for them directly nor via creating a store inside of your application and charging for new features that make use of new features on iOS.

Implementing a new technology that was released by Apple (like CoreMIDI, GameCenter etc…) isn’t as easy as flicking a switch. To do it nicely multiple developers will usually have to work for at least a week or more (obviously depending on the technology).

Example: it took us a week or so to implement CoreMIDI into SoundPrism. It took us another month to reach the quality that we were ok with charging for it.

As a developer that’s pretty bad but it also isn’t great for users/customers.

It either forces smaller teams of developers to release new apps instead of making their existing ones better. Or it forces them to improve their applications but they have to do it without getting paid for it.

From Apple’s perspective this is awesome. They release a new feature which (usually) rocks and their developers can choose between:

1. Creating a new application to make use of that feature and charge for it.
2. Spending quite a lot of time (usually a week or more) to implement it in their existing apps and giving it away for free.

Now why would any developer choose option 2? That depends on what their competition is doing. If their competition is implementing that feature then they’re forced to do it as well. If their competition is not implementing that feature then it’s probably a good idea to be the first one who has it.

Option 1 isn’t optimal for developers as well because it means they cannot stick with few applications and make them better and better.

One could argue that quality prevails and that even free updates to an application result in higher sales - which is true - but releasing a new application or actually charging for a feature results in higher revenue. In fact, sometimes free updates don’t change revenue at all if they don’t drive enough attention to your application.

The implications of this are that whenever Apple releases a new technology developers will either:

1. implement it for free. Result: Apple and users of older apps win because developers create better applications without users or Apple having to pay anything. Developers lose.
2. create new applications containing the new features and abandoning older apps. Result: Apple wins. Developers and users of older apps lose because nobody wants to buy a new application if they got used to the old one. Also the App store gets ‘spammed’ with new apps which is great for Apple’s statistics but bad for users trying to discover good apps.

Either way Apple always wins:

• By having tens (hundreds?) of thousands of developers getting to work literally for free after releasing a new feature.
• And by indirectly forcing users to buy new apps - which will will be more expensive for them than if developers could have offered the feature as an upgrade.

Please excuse me now, we still have to submit two new applications today.

by Sebastian Dittmann

UPDATE: You might want to read this follow-up post about the implications of this for all iOS developers.

Today our latest version of SoundPrism got rejected from Apples App Review team after an excruciatingly long waiting period of 20 days since we submitted it to them (you can read about it and the things I’ve found out about the review process in my excruciatingly long previous post).

I’ve made a video showing what we were trying to do in our latest update and what we were trying to sell as an InApp Purchase since it would take some time to explain it (badly). So here’s what we were trying to do:

Back from watching? Cool.

So we didn’t comply with section 11.8 of the App Store Review Guidelines which says (Statement #1):

“Apps that use IAP to purchase access to built-in capabilities provided by iOS, such as the camera or the gyroscope, will be rejected”

Apparently CoreMIDI is considered to be on the same level of importance as the camera or gyroscope which is probably a correct assumption by Apple.

Let our misery be a warning to you if you’re a budding iOS developer of audio apps - CoreMIDI cannot be sold as an IAP. Which is quite a shame if you ask me. Just because the capability is there that shouldn’t mean one can’t make any money off of it via InApp Purchase because IAP is probably the way to do business as an iOS develper in the future. InApp Sales/Purchases are a really nice way to monetize features of an application without letting the customer/user pay in advance for them.

But ok, it’s their store so it’s their rules.

Our solution to this is that we’re going to create multiple Apps. We’re going to leave our current one (SoundPrism) as it is. Then we’re adding a lite version which doesn’t have certain features and are offering it for free. And for our professional users we’re going to offer a version of SoundPrism which has the capability to change the scales and - tada - CoreMIDI support built in. That should do the trick, right?

Only there’s a catch.

The email sent to me by the “iTunes Store” reads like this (Statment #2):

“We’ve completed the review of your app, but cannot post this version to the App Store because it did not comply with the App Store Review Guidelines, as detailed below:

• 11.8: Apps that charge users to access built-in capabilities provided by iOS, such as the camera or the gyroscope, will be rejected”

See the difference? No “IAP” in that version of Section 11.8. So it’s not ok to charge for capabilies that are provided by iOS at all? Must be a typo, right?

Here’s another statment of the rejection from iTunes Connect (the developer area of Apples iTunes portal) (Statement #3):

“Mar 9, 2011 02:25 PM. From Apple.

11.8

We found that your In App Purchase product provides access to built-in iOS capabilities, which is not in compliance with the App Store Review Guidelines.

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

So we’ve received three statements. Two of them are contradicting themselves in an important matter and the third one doesn’t really bring any clarification.

1. The first statement from the actual guidlines says that InApp Purchases can’t charge for features that are based on iOS capabilities.
2. The second statment from iTunes Connect says it’s not ok to charge for features that are based on iOS capabilities. At all. Which doesn’t make any sense because literally every single app is built onto some basic capability of iOS.
3. The third statement via mail from “iTunes Store” says we’re breaking the rules because we’re supporting the Camera Connection Kit to enable MIDI support. Which we are not.

MIDI via USB via the Camera Connection Kit is just a byproduct of enabling CoreMIDI. I’m never using it at all. Connecting wirelessly is the really cool part about our latest release.

Also, it’s simply wrong that the Camera Connection Kit enables CoreMIDI. Enabling CoreMIDI is what enables the Camera Connection Kit as a way to connect.

What’s also slightly worrying is that some people in App Review are either working with a different set of guidelines or they’re quoting them incorrectly. Both of which isn’t optimal.

What now?

We’re now putting CoreMIDI support into a different application which we’ll sell independently. It’s just not feasible for us to not charge for CoreMIDI at all or making our ‘vanilla’ App (SoundPrism) more expensive.

We’re also ignoring the implications of Statement #2 because our common sense tells us that’s ok.

Hopefully Apple is ok with that.

So to end this on a positive note here’s a video of Roger O’Donnell using a midi enabled beta version to control his Moog Voyagers with his iPhone running SoundPrism.

Hopefully we’ll be able to see more musicians do something like that in the future. Wish us luck.

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.

Part one Part three

As a developer for mobile apps on Apple’s platform you’re born completely blind.

This is one of the hard lessons we’ve learned in the few months since the founding of our company.

When you release an app for the iPad you will get some data from Apple every other day about how many people have downloaded it. But that’s pretty much it.

You won’t know when they downloaded it, you won’t know the referring URLs of the sites they came from.

Sure you can track the clicks on your homepage (we use Clicky for that) but you will have a hard time bridging the final gap between your homepage and your app store page. There is no easy way to be able to tell if a potential customer that has clicked on the ‘download’ button on your homepage has actually clicked on the ‘buy’ button in iTunes after that.

You won’t know what people are doing with your app.

Once a customer has bought your app, Apple provides no direct way or means for you to find out what they’re actually doing with it. How long they are using it, how often, who they show it to, what they like about it.

The only way you’re going to receive feedback from your users is via reviews on the app store. And they will have a negative tendency because: When do people voice their opinion? When something has thrown them off. Therefore keeping a positive ratio of three or more stars on the App Store isn’t that easy.

Of course all of this can be fixed but it takes a lot of work.

Get some glasses!

We’ve solved some of these things by adding a voluntary statistics function in our app that makes it send us anonymous usage data of the people who have enabled it. We’ve added a feedback button right in the app that lets people send us an email from within the app so we know what our customers want and what they don’t like.

Right now we’re working on finding out how to use tradedoubler.com to find out referring URLs to our app store page.

But at the same time we’ve caused more uncertainty for ourselves by going universal with the new version of SoundPrism.

Why is that?

Because to my current knowledge there is no way to distinguish between iPod, iPhone and iPad sales with the sales statistics provided by Apple.

Feel free to comment with your findings and solutions to these problems if you would like to share them and please point out any errors on my side.

Part two Part three

There are lots of misconceptions out there about what it takes to be an app developer. Especially in the genre of music apps for Apple mobile Apple devices there are tons of apps and great ones at that so competition definitely exists. But I’ve talked with a lot of other developers and have yet to meet someone who isn’t a great person so that’s definitely a big plus.

As you can already guess this is not going to be one of those number posts. Instead I’m going to write about some of the things our team has found out that might be of great importance to whoever creates apps (be they audio/music related or not).

What’s awesome:

If you create useful and ideally beautiful apps, you will receive attention. Not just by people but also by Apple. They pick beautiful apps and they feature them prominently in multiple spots. The iPad Version of SoundPrism has been featured for roughly a month on multiple locations in the App store.

Obviously the higher you are in the charts, the more you will sell. But your ranking in the charts will mean more than being featured by Apple because you will be visible on top of the important lists for people buying apps on their devices. Some of them won’t see the big banners visible in iTunes on their desktops because they buy apps directly on their iPads.

As far as I can tell being featured with a huge banner on top of everything in the App Store store wasn’t half as good as being in the ‘What’s hot’ section on the top left corner. So if you want to you can take home from this that you should put as much love into your app as possible because Apple likes beautiful things. It payed off for us.

What’s a bit tricky:

We’ve started with an iPad App which turned out to be a great idea. Not only is there quite a hype going on and whoever develops iPad apps exclusively will profit from that but also is there only one version of the operating system (iOS 3.2) and only one hardware that you will have to develop for. The iPad Screen is large and bright, colors will be great. The iPad is fast so if you’re not able to tweak the §&§$ out of the platform yet you’ve got some very forgiving hardware which has lots of resources.

That being said we’ve got very good developers and even they had work hard on tweaking and optimize things for the iPad before our initial launch.

Also we knew some very good developers who had been creating iPhone and iPod apps before. But even they weren’t able to help us with some memory leaks that were supposed to be fixed already. In the end we had to remove some eye candy from SoundPrism to be able to ship a bug free version.

The iPad is still a young platform so this was to be expected.

If you’re unsure of if your app will run on older generation iPods or iPhones, then go for the iPad first. Only one (powerful) hardware version and only one OS version gives you lots of head room and few limitations you have to keep in mind.

What’s hard:

Going universal (releasing for both iPad and iPod/iPhone) for platforms of all generations is hard.

Especially so after you’ve released for the iPad and have used most of it’s ressources already.

Our team spent a month optimizing our sound engine to be able to run on first generation iPods. Optimizing graphics and graphic effects was part of that process as well. More eye candy had to be removed.

When developing for 8 different devices (iPhone 1, 3G, 3Gs, 4, iPod 1, 2, 3, 4) with different screen resolutions, speakers, screen brightness,  performance and multiple versions of the operating system (iPod 1st gen can only use iOS 3.1.3 at most while the iPod 4 and iPhone 4 start out with iOS 4) then you’ve got a basket full of things you have to keep in mind.

You can also choose to ignore that and have your users end up with a version of the software that makes them send you angry mails and leave upset comments on your website, blog or in reviews of your app. Or you can decide on releasing later and fixing and tweaking things for 1, 2 or 3 more weeks.

We’ve chosen the last option and I hope it shows.