« Posts tagged behind the scenes

How Much Work in an Indie App?

As I near the end of this seven month development process, my thoughts turn to reflection. What a journey it’s been. I initially thought I’d create a fun ‘spider’ app for Halloween. I had this thought back in mid October of last year. I was working on a pretty involved game project at the time that seemed like it would take another five years to finish. So I thought why not take a break and throw together something quick?

My initial plan was to give myself ONE WEEK to see what I could pull off. I coded like crazy and even pulled an all-nighter. I was super close to having something actually publishable.

But I ended up missing Halloween by a day or so. At that point I decided there was no longer any rush. Why not tinker with it and make it perfect?

I went from a cheesy 2D sprite spider to a fully rendered 3D spider equipped with a rudimentary artificial intelligence. I spruced up the interface considerably and added a lot of bells and whistles including localization in twelve languages.

Suffice to say it’s no longer October. What I thought could take a week instead took basically an entire a year.

Now to be totally fair, I work full time as a Motion Graphics artist, so it’s not like I could work every second on this app. I’d sneak in coding time where I could on nights and weekends. But it was still quite a slog.

So how much work did I actually do?

I use to-do lists to help me stay sane with my projects. My favorite list app is Wunderlist. It’s great cuz it synchs through the cloud over my phone, desktop, ipad etc.

Anyhoo, here’s a screengrab of my Wunderlist list for my app. Each checkmark represents a stage of the development process. Some items took me an hour, some took me over a week. Moreover, I wasn’t totally committed to list-keeping… so I’d say maybe 50% of the work I didn’t even bother listing. I use lists to help me stay organized– not to punish myself in some sort of OCD ritual.

Here’s the list! Whew. Quite a lot of checkmarks for such a simple little app. And you’ll notice that it’s not finished either. Any day now I hope! Of course, that’s what I was saying seven months ago.


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.

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.


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:

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:


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


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.


Challenge accepted.

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

Evolution of an Icon

Icon design is tough business. It’s gotta look good at full size, but it also has to scale down and look good when it’s just a tiny icon on your device.

Here’s my first stab at the icon for Spider Prank. It was back when I had a purple interface.

Actually I think this looks pretty good. But the purple interface wasn’t working for me. So back to the drawing board.

Here’s version #2:

I was trying to match the silver, sleek interface I’d settled on. But I think I missed the mark with this icon. The silhouette looks pretty boring. Plus the uniform legs make a visual mess when shrunk down.

A challenge I had was I wanted the icon to be really dark and menacing. But the spider was black. Hard to make black show up on black. I wondered what would happen if I tried the spider inversed. Version #3:

I kinda liked that version. But ultimately I decided that I need to showcase the hero– the spider itself in all of its 3D glory. That’s the main selling point of the app, so I figured I needed to at least feature it prominently in the icon. Version #4:

I was pretty happy with this. Decided it just need a little levels adjustment to make it pop more. So I added more contrast, and voila, version #5:

I think this one’s a keeper. But who knows? I’ll have to sit with it a little and play with it on my device(s) to see if it really does the trick. Also it’ll be important to get some feedback from testers. Almost to beta testing! Yeehaw!



Is this amazing or what? Thanks to the very simple and easy to use localization plugin for Unity3d, I can localize the text in my app at the click of a button.


It’s all automated through google docs– including the translations. Here are some blurbs from my app in French, Spanish, German, Chinese, Russian, Japanese, Korean and Thai– the list goes on and on.

spider prank in korean

Spider Prank in Korean

I love living in the future. (PS– anyone know how to say ‘swipes’ in Korean??)

Procedural Logo

In my latest app, I came up with what I thought was a cool look for the logo. I created the following in After Effects. My initial thought was to render out the still frames and have them run in the app as an animated sprite:

However, rendering out all the frames led to over 200mb or so of raw assets. Granted, this number would drop after combining onto sprite sheets and compressing, but it was still far too much bandwith for a simple logo. Moreover, I’m not a fan of the aesthetics of compressed still imagery. I needed a different solution.

sprite sheet

A handful of the 90 odd images that would have gone into a sprite sheet for the animation.

I created a single god ray sprite in Photoshop (seen here).

I also created two logo sprites (one normal, one glowing). So instead of 90 images, I was down to 3. In Unity3D, I duplicated the god rays several times and added a Box Collider to each one. Then I wrote a godray script. The script told each god ray object to fade up and scale depending on its relative intersection with a trigger object. I also gave each ray a little wiggle. Finally I told the glowing logo to fade up when it intersected with the trigger to boost the overall glow effect.

The last step was to write a simple script to make the trigger object move back and forth over the logo. Because it’s procedural, I got the added benefit of being able to randomize the speed and the direction of the trigger from pass to pass. Here you can see the trigger object (the longer box) and the god ray objects at work in Unity3D:

And the final result below. Since the three sprites fit on the same sprite sheet, this version of the animated logo only takes a single draw call and costs 322 KB (uncompressed).

Not quite as pretty as the original After Effects version, but worth the extra work to get the size down. Now users won’t have to wait an extra several minutes for a heavy sprite logo to download. Instead this streamlined version should load fairly instantly.