REJECTION – part 1

Okay– so what is every developer’s worst nightmare? Finishing a long, arduous development process only to get your app REJECTED by Apple! That’s exactly what happened to me.
rejection01
Owtch!

Hopefully Apple won’t mind if I share a few of the details just so others may learn to avoid my mistakes.

The whole point of my app was to allow users to prank their friends by putting a ‘real’ spider on their phone. To this end, I added a bunch of device screenshots to the app that simulated an ios desktop. Apparently this is a no-no.

rejection02

So according to bylaw 8.3 (which I had not read), it’s against Apple’s rules to ‘simulate an ios behavior’. Including still screenshots of ios backdrops qualified and my app was rejected.

Should I have seen this coming? I suppose so. I was caught with my pants down, that’s for sure. I thought I’d seen apps that had done this sort of thing before… ie simulated stuff that appeared to be on your actual device.

Like this one:
Volt

Or this one:
Shake Break Make

But after digging deeper I started to uncover some others who had run into the same roadblock. Specifically, I found this great post from all the way back in 2009. Some guy wanted to simulate an iphone screen like I did. And he paid the price.

I love the evolution of his app design which illustrates his harrowing rejection process (image from www.mani.de):

rejection and iteration

So how come apps like Watchdog and my app got rejected, and other apps like Volt and Shake Break Make made it past Apple’s watchful eye?

It’s well documented that sometimes Apple’s review process is a little random. Get a cranky reviewer on the wrong day and you’re just out of luck (although I can’t blame the overworked review team). But my hunch is that the real difference is that in the apps that made it through, desktop imagery did not ship with the app. Users were instructed to take a screenshot to add as a background… something that should, in theory, be entirely legal.

The problem for me, however, is that without a screenshot shipped with the app to greet the user right away, a lot of the punch of the main concept of having a spider on your phone is deflated.

As a developer, my first reaction was to drink a lot of whiskey. I’d just spent a solid six months working on a project that would never see the light of day. FAIL. It was a brutal disappointment.

BUT, after taking some time to wallow, I picked myself up, dusted myself off, and asked the question that developers MUST ask after app store rejection:

HOW DO I SAVE THIS?

After all, I appealed Apple’s decision and they wrote this:

rejection03

Granted, it seems like a boilerplate, form letter response, but it was still encouraging.

“We hope you will consider revising the app to address the issue…”

Apple WANTED my app– they just needed me to fix it. And all-in-all I think in retrospect it was a pretty fair process. Upon reflection I understood that it made little sense for them to allow apps in their store that made it seem like their devices were busted or inoperable.

So HOW DO I SAVE THIS?

Challenge accepted.

Stay tuned for part 2 where I’ll fill you in on the solution I came up with.

Comments (0)

› No comments yet.

Leave a Reply

Allowed Tags - You may use these HTML tags and attributes in your comment.

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Pingbacks (0)

› No pingbacks yet.