Kick Ass for iOS (iPhone, iPod touch and iPad) has been out for a couple of weeks now. This post is intended to be an analysis of how the launch went, how the app has been doing and what steps are needed to improve it. I might break it into smaller pieces, but I want to be able to begin on Kick Ass 1.2 as soon as possible so it might just be one large wall of text.
The things I will discuss are the before, now and after. I’ll try to include as much imagery as possible and be as forthright as I can. Let’s begin shall we?
- Now (coming soon!)
- After (coming soon!)
This section is about the development up until the launch. I will begin with some history, move on to some technical bits and top it off with a discussion about the launch.
The inspiration came from (surprisingly enough) the web version of Kick Ass, found at http://erkie.github.com/. The web version was immensely popular and was written about all over the web and rough estimations (and according to Google Analytics) say that it has had around 1 million unique visitors to date. It still has a steady stream of visitors.
Selling in the App Store was another advantage. Apple makes it so easy to create an app and actually sell it without much hassle from the developer or the user. When Kick Ass went viral I was still in school and took the odd job when I could get one. Selling something that I had created and marketed myself was not even in the realm of possibility, let alone making a decent living off of it. It’s funny how life can turn things around in a matter of hours, right? With 1 million users (not active) there is definitely a possibility. 7 months later and I have finished school and am (un)officially unemployed (on a summer vacation). Making a living is now more important than ever.
Early stages of development
Prior to this app I had no knowledge of developing for iOS. I had touched upon the occasional Objective-C but never really understood how it all fit together. So I started reading the Apple Developer documentation which resulted in nothing of use. It consisted mostly of technical information and nothing on how making real-world applications. So I downloaded all of Stanford’s lectures on iTunes U. They were exactly what I needed, and after the four of fifth lecture I was ready to go!
It began slowly. Just trying to get to know the tools and such. This turned into trying to draw a ship over a small browser window. (This was quite tricky for a beginner!) After that getting the interaction with the browser to work (destruction of elements). This was fairly easy and took only a couple of weeks. The downside was performance. Trying to destroy a huge page was nearly impossible and locked up the entire app for several seconds at a time. So working on performance issues was the most time consuming task and is the reason it took 4 months to complete.
The UI was also a difficult part. Making intuitive and fluid UI’s is not as easy as it looks. Thanks to my bro the app looks fantastic, but the touch-and-feel-part is up to the programmer to do great. Johan’s whipping when it didn’t work too well helped a lot. I’m still not 100% happy with the UI. One part being the URL-bar. I would have wanted a navigationbar that follows the browser when scrolled like in Mobile Safari, but thanks to Apple’s restrictions this is not possible.
All the difficult and bad stuff apart, making apps for mobile devices is rewarding! There is something about holding your own creation in your bare hands that is quite a powerful experience. It takes it to a new personal level. I enjoyed it.
You’d think that blowing stuff up is an easy thing, considering how easy it was in the browser. Now I even had a native language to do it in! It still turns out that it is slow.
It’s not the shooting that is slow and it is not the drawing (mostly). It is the redrawing of destroyed webpages. Say you hide/remove an element in your browser; it happens instantaneously. You start noticing a problem if you try to remove tens or hundreds of elements at the same time. For a mobile browser it is almost the same. But this rears its ugly head after you remove only one element on a large page, or two/three on a smaller webpage. You can try it out yourself. Go to reddit.com on your iOS device and pick a random comments-thread. Scroll down to the comments and press the +-sign next to the author of a comment to hide the thread. How long did it take before the thread disappeared? On my 1st gen iPod touch it takes around half a second. On an iPhone 4 it still takes a considerable amount of time, for a game, where you’d want 40-60 frames per second. Even if it just takes 0.1 seconds it averages out to 10 frames per second.
To circumvent these problems I changed the mechanics of the game a bit. Instead of removing the elements I simply hide them. This action is actually hardware accelerated so it’s lightning fast and it makes the game a bit more challenging to play (no more shooting at the exact same place the entire time).
The second large performance issue was the collision detection. In the first version of Kick Ass for web I maintained a list of element’s positions that were destroyable. For every frame I looped through that list and looked for a collision. When an element was removed I had to update that index, because elements moved up or changed dimensions due to losing a child element. This resulted in bad performance when removing elements, so I found a native DOM-method that did it for me. document.elementFromPoint(x, y) which was a lifesaver! Naturally I tried to incorporate it into the iOS-version too. The bad news was that, because I was running the game on a separate thread, I had to lock that thread every time I wanted to search for collisions. This could cause stuttering and really annoying waits.
The most difficult part about making something is getting to point where you are content with it. Launching a product that you’re not 100% happy with is not good for the mind or for the users. Finding bugs in the last minute can be even worse; if you find one, how do you know that it was the last one? There could be a couple left creeping around somewhere. This was definitely the case with Kick Ass. One day I was prepared for launch, but the next I had found several critical bugs. When I finally decided to launch, Apples uploading process was so difficult that I was afraid I broke something on the way. It hadn’t, and a week later it was on the App store! (Buuuut it had a critical bug that I had to fix before publicly announcing the launch).
So this was a brief outline of the performance woes I’ve had when making the app. I’m still looking to improve the app, so any ideas from you guys would be awesome. In the next post I will talk about the Now, how sales are going and what I could and should have done better ad my thoughts about the subject. After that I will talk about the future of Kick Ass the app and discuss what I will be improving and why.