programming in the
twenty-first century

It's not about technology for its own sake. It's about being able to implement your ideas.

App Store Failure and Personal Responsibility

"I wrote an iPhone app, and it didn't make any money" is a growing literary genre, and I sympathize with the authors. I really do. Building any kind of non-trivial, commercial application takes an immense amount of work that combines coding, writing, interaction design, and graphic arts. To spend a thousand hours on a project that sells 103 copies at 99 cents apiece...well, it's disheartening to say the least.

Dismissing that failure as losing the "app store lottery" (meaning that success or failure is out of your control) dodges important questions. When I was writing and selling indie games in the mid 1990s, I went through the experience of releasing a game to the world--euphoria!--followed by despair, confusion, and endless theorizing about why it wasn't the smash hit I knew it deserved to be. Most of the failed iPhone app articles sound like something I would have written in 1997. Of course the iPhone and Apple's App Store didn't even exist then, but my feelings and reactions were exactly same.

What I learned from that experience may sound obvious, and that's precisely why it's a difficult lesson to learn: just because you slogged through the massive effort it takes to design and release a product doesn't have any bearing at all on whether or not anyone actually wants what you made.

See? I told you it sounds obvious, but that doesn't make it any easier to deal with. Getting something out the door is the price of entry, not a guarantee of success. If it doesn't go as planned, then you have to accept that there's some reason your beautiful creation isn't striking a chord with people, and that involves coming face to face with issues that aren't fun to think about for most bedroom coders.

Have you ever watched complete strangers use your app? Are they interpreting the tutorials correctly? Are they working in the way you expected them to? If it's a game, is the difficulty non-frustrating? Maybe you designed and polished twenty levels, not realizing that only a handful of players get past level one.

It's harder to judge if the overall quality is there. Your cousin might draw icons for free, but do they give the impression of high-end polish? Are there graphics on the help screen or just a wall of text? Are you using readable fonts? Are you avoiding improvements because they'd be too much work? Developer Mike Swanson wrote an Adobe Illustrator to Objective-C exporter just so images would stay sharp when scaled.

It's also worth taking a step back and looking at the overall marketplace. Maybe you love developing 16-bit retro platformers, but what's the overall level of interest in 16-bit retro platformers? Is there enough enthusiasm to support dozens of such games or is market saturation capping your sales? If you've written a snazzy to-do list app, what makes it better than all the other to-do lists out there? Can folks browsing the app store pick up on that quickly?

It would be wonderful to be in a position of developing software, blindly sending it out into the world, and making a fortune. It does happen. But when it doesn't, it's better to take responsibility for the failure and dig deeper into what to do about it rather than throwing up your hands and blaming the system.

permalink August 11, 2012

previously

archives

twitter / mail

I'm James Hague, a recovering programmer who has been designing video games since the 1980s. Programming Without Being Obsessed With Programming and Organizational Skills Beat Algorithmic Wizardry are good starting points. For the older stuff, try the 2012 Retrospective.

Where are the comments?