Results of radical design can’t be planned for in advance.

Apple was right. I was wrong. 

Roughly a year ago I wrote this blog entry about how it is impossible for developers to get a definite answer from Apple App Review before starting development of a planned feature or app.

As a developer it would be so cool to figure out if App Review would be ok with a certain way of implementing a feature or something that an app does before sinking weeks or months of development time into its creation just to have it denied by Apple App Review.

Only it won’t work.

Not because Apple is never going to open up their App Review Team to developers’ requests for communication but because results of the development process of apps are impossible to predict with absolute certainty. If we can’t predict the way we’re going to implement certain features, how would Apple App Review be able to give us a carte blanche for it. You want an example? I’ll give you an example. It’s going to be about Audiobus.

In a previous post Michael demonstrated the concept about inserting a slide-in menu into apps to switch between them and to trigger functions in apps running in the background from an app running in the foreground. He called it the “Connection-Panel”. Both of us thought the idea was very neat. Other developers thought so as well. But from previous experience I know that what developers think can be very different from what users think. So I asked a few iPad musicians on Reddit about it.

Some of them said that they didn’t like the new notification menu in iOS 5 and compared our super neat connection-panel to it. How could they?

It forced us to re-think the implementation. We tried to go for a very subtle way to implement a means to control apps running in the background. The less screen real estate it consumed, the better. Now one of our users says that he hates it already. He even posted a video about how to disable the iOS 5 notification thing that slides out from the top of the screen completely.

So we came up with a slightly different solution:

We’re going to keep the Connection-Panel. But we’re going to make it optional in case you have a second iOS device that the Audiobus app is running on. If that’s the case, the Connection-Panel is going to be disabled in all apps and they will be able to be remote controlled by Audiobus running on the other device. To make it clear, here’s how the currently preferred solution looks like.

For users running Audiobus on one iOS device:

  • Use the Connection-Panel to switch between apps and trigger functions.

For users running Audiobus on more than one device:

  • No interface at all in apps that you want to play in.
  • All of the interface on a second device.

Is Apple going to let us do that? We don’t really know. It’s likely they will. Would we have been able to ask them before we started the implementation and got feedback from users? Before even announcing what we would be doing to the public? What if we come up with an issue while development is almost finished?

They couldn’t have given us a carte blanche because we wouldn’t have know what ask for.

Apple is doing the right thing by not even offering one.

  1. audanika reblogged this from audiobus
  2. audiobus posted this