My First iPhone App: Lessons Learned

I recently finished my first iPhone app and submitted it to Apple to get a feel for the iPhone App Store. I didn't want to invest a lot of time into this experiment, so I decided to add some polish to a very simple game I had already written for my own amusement, and put it out there.

I'm probably going to write a second article detailing some sales numbers (they're practically non-existant, so I'm not sure how interesting that is going to be), but since sales never were the goal of the app, I'm going to start out with some more important things I've learned when writing and releasing this app.

Search

This is just something weird I have noticed. Different stores show different results for the same search term. Searching for the exact name of my app in the Swiss store shows it as the first search result, while the search position in the US store fluctuates:

I have no idea what causes the difference.

Reviews

Most larger sites are swamped with review requests and won't even respond to mail. Smaller sites and YouTube Channels are happy to get promo codes, but they don't have much reach. Some sites encourage posting gaming news to their forums, which is pretty cool because it gives you quick feedback from people who actually play your games.

To my surprise¹, some sites and podcasts actually request money for reviews or frontpage placement of news items. Some even take money for reviews, and offer to not release the review if it turns out to be negative. Others have written about this:

But when I find out that certain sites are using gutter tactics like selling reviews on the sly, that's where I draw the line. I recently lost an advertiser to a competitor that offered him a review along with his advertising package – "impartial," of course - to better promote his game.

Needless to say that this is not the kind of behaviour the iPhone app market needs. Perhaps this might help.

iTunes App Loader

Since "Release" versions of iPhone applications are signed with a specific App Store Provisioning Profile, there's no obvious way to test them (there is, however, a non-obvious way). In fact, you can't even be entirely sure that the application is signed properly. To get around that, you can use the Application Loader to upload apps to iTunes Connect. It seems that the Application Loader will verify the signature when uploading the app, although I haven't tested this (signing worked fine for me). The bickbot blog explains where to find the Application Loader.

Crashes

About a day after releasing the game, I got a mail saying basically "well, you got my money, but I can't play your app because it crashes."

To me, this feels like getting punched in the stomach: Somebody gave you his or her money, and the app doesn't work because you screwed up or didn't test enough or didn't think of some special case. They have every right to be pissed off, because you basically stole their money.

From the description of the crash, it became obvious to me that the game crashed because it ran out of memory. During beta testing, nobody had had this issue. I assumed that my app's memory usage was well within the limits of what any iPhone should be able to handle.

So I made the boneheaded decision to ignore memory warnings; I simply assumed that my app was small enough that it would always fit into the iPhone's available memory and never receive a memory warning.

Turns out the person who had the crash had a jailbroken phone that hadn't been restarted in a while. Restarting solved the problem, but the other issue is the jailbreak. Jailbroken iPhones tend to have less available memory, probably mainly due to background processes that some non-Apple-approved apps can create.²

I haven't found an easy way of testing my app for iPhones with memory issues. What I did to check my fixes was to

1. Create a test build which allocates and retains a bunch of unused memory when the app starts
2. Create a test build which constantly leaks memory, eventually triggering memory warnings

That should cover most situations people might actually encounter in real life.

Daniel Ericsson points out that memory warnings can also be tested by using "Hardware" -> "Simulate Memory Warning" in Simulator.app. That that doesn't replicate the actual low-memory situation on the actual hardware, but it's useful for testing the code triggered by memory warnings.

For the record, my game simply turns off some animations when it receives the first memory warning, releasing the images used for those animations. This seems to have fixed the problem.

2.2

Something else I discovered during beta testing is that a lot of people still use iPhone OS version 2.2. Some don't want to risk updating a well-running phone. Another reason is that updating jailbroken phones requires quite a bit of time, and a lot of people with jailbroken phones simply won't bother to do it.

So it's probably a good idea to support older versions if possible.

Performance is your Number 1 Problem

I started writing this particular game even before I got accepted into the iPhone developer program, simply to get acquainted with iPhone development. It ran just fine in the simulator, but when I put it on an actual iPhone, I was able to get about two frames per second. There was no way to salvage my code; I had to rewrite the game, making entirely different assumptions about the iPhone's performance.

There's a saying in software engineering: premature optimization is the root of all evil. As a general rule, this may be true, but on the iPhone, you should probably optimize constantly. Otherwise, you might end up with an application you can't possibly get to work.

Start out with a "performance prototype" simply to see whether your idea can actually work at all. Then, during development, do on-device performance tests regularly. Fix issues as soon as they come up if you don't want to get stuck with a wonderful application you can't get to perform acceptably.

Finally, not all "Touch OS" devices have the same processor. Some newer iPods have faster processors. Make sure to also test your app on older, slower devices and perhaps allow the app to adapt to them in some way, either by measuring performance, or by checking what specific device your app is running on. For example, some racing games show fewer opponents on slower devices. Here's a way to detect what device your app is running on.

Memory is also your Number 1 Problem

As noted above, memory is a constant issue on the iPhone. You may be tempted to improve performance by increasing memory consumption. On desktop computers, this typically works just fine since the operating system can page out idle applications and give your app almost as much real memory as you ask for. On the iPhone, this doesn't work. You pretty much get the amount of memory that is currently free, and if you want to use more than that, you're shut down.

So it's often not a good idea to fix performance issues by increasing memory consumption. As a general rule, you should probably keep memory consumption low and release stuff as soon as you can, even if it's bad for performance. You'll be glad you did once the iPhone grows the ability to multitask³.

Even if your app runs perfectly fine on your iPhone and your beta testers' iPhones, chances are your actual customers will run into memory issues you did not. They will have jailbroken phones with background processes running. They will have iPhones that haven't been restarted in weeks or months. So even if your app requires little memory and you never had any issues, it's probably a good idea to catch low-memory warnings anyway.