iCombat

2 Rejections and 42 Days of Waiting

Last week we received an e-mail from Apple’s App review team notifying us that after 14 days of review, our latest update to iCombat Lite would not be accepted because of “inappropriate keywords.” The offending keyword was “wii tank,” and we had chosen this because many of our users have told us that our game reminded them of the tank mini game that is part of Wii Play.

While we knew not to use current iPhone app names as keywords, it had never in a million years occurred to us that “wii” might be problematic.  In Apple’s words, they “cannot post applications that contain irrelevant keywords in their search criteria” and suggested that “it would be appropriate to remove ‘wii tank.’”  Interesting since they: 1) had already approved our iCombat paid version with the same keyword, 2) have approved an app with Wii in the title, and 3) they had already rejected iCombat Lite two weeks prior for some other reason without mentioning any problems with the keywords.

What is so frustrating about this latest round of trivial rejections is that the app review “feedback” seems to always come on day 14 (at the earliest), and happens serially.  To give you an idea, we first submitted iCombat Lite update 1.1 on September 8th, 41 days ago!  After being rejected for an issue Apple reported with the code on September 22nd, and spending several days working on replicating the bug (which we never even managed to), we resubmitted the exact same keywords and code on September 28th.

On October 12th (14 days later) we received notice that the entire update would need to be resubmitted because of the “wii tank” keyword.  Had anything changed from the approved iCombat Paid version or the previously rejected lite version?  Nothing at all…and so we deleted the words, resubmitted and for the third time started another 14 day approval cycle.  All in all, if we are lucky we expect the iCombat Lite update to be approved on October 26th, just 48 days to get to market (42 if we subtract the days we took to work on the first rejection).

Reasons to Avoid Developing for the iPhone

Ignoring how illogical this last keyword rejection has been, the real damage of the current app approval process is that it has created a slow and arbitrary development environment that does nothing but discourage indie developers.  The biggest issues with this setup are:

1. Slower development cycles – As if figuring out what users wanted wasn’t hard enough, now add a 14 day approval delay which quickly turns into 1 month with any rejection and you have a buffer that really starts to isolate developers from their users and this constrains the feedback – iteration loop
2. Product/ Market fit is replaced with Product/ Apple fit – To use Andreesen’s advice (worth a read), entrepreneurs should “do whatever is required to achieve product/ market fit.”  Here the only thing that matters is finding what users want and giving it to them.  Yet with Apple as the gatekeeper success is not determined by the market but first by whether Apple will LET you play in its garden. This perverts the goals of the developer and ultimately reduces the chances that an efficient product/ market fit can occur.  You could even argue that on the off chance that you find an exceptional product/ market fit you are at even a higher risk of being cannibalized or pulled or copied by Apple itself.
3. Impossible ROI calculations – If you are trying to run a business based off of App development, how can you possibly calculate the return on your investment when you have no control over your launch to market? Unless you are ngmoco with funding from Kleiner Perkins then how can you build a business on top of such uncertainty (market and execution risks should be more than enough to contend with without having to worry about the d-bag app reviewer risk)
4. App approval amnesia and the lack of a fast track system – What seems to be happening all too often is that previously approved apps, after waiting weeks in the queue, get rejected for features that had already been approved in past releases.  This approval amnesia combined with being lumped in with new app approvals creates a developer disincentive to work on refining applications.  Does it make sense when iCombat Lite, having been live for 3 months with 100k installs and no complaints, suffers a 40+ day delay because it is being forced to the back of the line over and over again to wait amongst what is new crapware?  The sooner these apps can get updates out the sooner they can deliver high quality experiences to Apple users.

All of these factors serve to undermine developer confidence, reduce the quality of apps in the store, and ultimately choke app development activity.  Developers are already looking to other platforms and are limiting investment as the environment has simply become too unpredictable to work with.  Sure Apple has its reasons, namely pushing its 85k or 100k or 250k apps commercials to prove it has the most evolved app ecosystem versus its peers.  But if Apple doesn’t fix these problems soon, those numbers will begin to mean less and less, and at some point the number of apps in the App store will be about as meaningful as the number of videos uploaded to YouTube.

Related articles by Zemanta

• iPhone Apps: From Idea to Implementation (slideshare.net)
• Big Game Publishers Muscle In On iPhone Upstarts (wired.com)
• ngmoco Hires MySpace Executive Jason Oberfest to Helm Social Applications (wireless.ign.com)
• Shazam hits 50 million user mark and raises funding from Kleiner Perkins (thenextweb.com)

For anyone interested in creating an iPhone app but wondering where to begin, I think the best thing you can do is just sit down and lay it out.  I have always been a big fan of whiteboards and as of late the huge Post It Easel Pads but these are impossible if you travel a lot and are of limited use when trying to collaborate over long distances.  The answer for me has been to use Balsamiq, a tool that allows you to quickly create mock-ups of both websites and iPhone apps.  With Balsamiq I can work through the mechanics of how an app should work, and visually see the flow from action to action.

In previous posts I have suggested to first time app developers the importance of creating proper specs when planning to create an app.  I think mockup tools like Balsamiq are even more useful than making great specs and writing out usage scenario examples.  Not only does it help you better develop your idea but it also gives you the ability to share your mockups with other people instantly.  For example, if you are thinking about outsourcing development or are talking to other team members, Balsamiq will let you share your mockups and convey clearly what you want to do (for info on how to protect your idea with outsourced developers read this post).  And by visually demonstrating the flow of how you want your app to work developers will have a much better idea of what you are looking for.  This will pay off in terms of the quality of developer you manage to get and it will also improve the accuracy of the time and budget estimates you get from developers.

Even if you plan on developing the app yourself, you can benefit from working through the fuzzy parts of your idea.  A mockup tool will give you the simple tools you need to work through EVERY aspect of your app structure before you begin the development process.  This is important because it can alert you to fundamental flaws in your idea or logic before you put the time and effort into building it.

In addition to the sketches of the iPhone and its main interface tools you also have sketches of dozens of buttons, switches, icons and other items that you can customize.  For example, when you drag an iPhone image to the drawing area, a box pops up where you can select whether to include the status toolbar at the top, change the orientation, the background look, etc.  You can even drag call out boxes into the picture as well to insert commentary about your mockup.  Check out this video for an example of what is possible.

Balsamiq includes a free trial version so you can test it out today…give it 5 minutes and you will see how quickly you get the hang of it.

Related articles by Zemanta

• Don’t Have an iPhone But Love its Gaming Apps ? Here’s The Alternative (techpluto.com)
• The Week in iPhone Apps: Grow Up, Slacker [IPhone Apps] (gizmodo.com)
• Developers Sneaking Porn, Profanity Onto iPhone Via Easter Eggs (cultofmac.com)
• You should be using Balsamiq Mockups (devlicio.us)
• 5 of the Best iPhone Apps for Political Junkies (mashable.com)

Before launching iCombat I wrote a post discussing the question of what to do with App store piracy.  The options basically boil down to either: A) doing nothing, B) using RipDev or a comparable solution to make the app more difficult to crack, or C) implementing an info.plist check that allows the developer to see which users are using a cracked version and then altering the app for those pirate users (see Beejive IM’s response as one of the more decisive moves you can take with this approach).  See description of how to do this here.

As a first time developer I wanted to protect my effort but did not want to pay an upfront fee to Ripdev without having made a dime so I opted to go for the more benign yet not totally passive option.  I chose to detect when they cracked the application and then have a pop-up screen say something inoffensive along with a button routing them away from game play after 5 levels.  The button redirected the pirate to a hidden page I created on my site called “You Jacked My App” where the text read:

“Hi if you have been directed to this page it’s because we see that you have a pirated copy.  While we are glad you are interested please understand that we want to continue making it better, but to do that we need people to each pay for their copy.  If you want to continue using please purchase today.”

The idea was to get the user to empathize with my cause and maybe convert a tiny fraction of those users into sales.  While it was a cheesy move and probably a bad idea I figured it couldn’t hurt to try (maybe I should have just rickroll’d them all!).  For a great example of a better executed version of this strategy see developer Ben Chatelain’s pop-up here which mentions needing the sales to help feed his 1 year old!  I just found this but had I seen it pre-iCombat 1.0 I would probably have implemented something similarly guilt evoking.

See below some stats to give you an idea of the scope of the problem for iCombat as well as some conclusions I have drawn from the experience: Read more…