Noel Llopis recently posted a review of “The Business of iPhone and iPad App Development”, a book I read (first edition) shortly before launching my own app. His conclusions about it are pretty similar to my own, in that it’s nothing groundbreaking, but has a lot of good, practical advice. There were definitely parts that seemed out of place, such as code snippets in sections that didn’t really require any technical explanation, but overall it was a solid read.

The book contains little nuggets that developers new to the platform may not’ve considered, such as whether it’s better for certain apps to have a separate Lite version versus a single free version (with in-app purchases.) Another example I appreciated was a section about the length of an app’s name. During development I hadn’t considered that “PhotoTangler Lite” doesn’t fit in it’s entirety on the iPhone home screen, so I used the little trick where both versions are called “PhotoTangler”, with the “Lite” banner placed on the icon itself. Granted that’s a common practice these days, but having little pointers to details like that is certainly handy. I also found the book’s list of news and review sites useful when it came to publicizing my app.

If you’re looking to sell apps of your own, I definitely think it’s worth checking out.

Posted under: Miscellaneous, on April 13, 2011.

PhotoTangler was my first iPhone app. My programming background has largely been in 3d video games and simulation, primarily on the Windows platform. I’ve been using a variety of other platforms for quite a while (including Linux and Mac), but most of my serious development projects had been on the Windows side. To learn about iOS development, I spent a week consuming two iPhone books (and Apple’s documentation), then got to work on my app idea.

When I began the project, I had to make a few decisions about what versions of iOS to support. For example if I used OpenGL ES 2.x, my app would only work on the iPhone 3GS or later. It so happened I had one of the very first iPhones (Edge, 4GB) lying around, so I decided to test its capabilities. After a quick prototype, I concluded that ES 1.x could do all i needed, meaning I could support any iPhone out there. My strategy was then to do all development on this ancient phone, expecting that if it ran well on this bad boy, it’d run like a dream on newer phones. This is something I used to do in games– write stuff on older machines, with older graphics cards– with hopes it’d run well on the newer stuff. And it usually worked great. Turns out that for the iPhone, that just wasn’t the case.

I wrote and tested the app on the aforementioned phone, as well as an iPhone 3G that a friend gave me. By the time it was finished, everything worked perfectly. I hammered it with a pretty rigorous combination of test runs each time I did a build, and it never crashed. It seemed rock solid. I sent it to a handful of friends for testing, and they reported good things. So I published it.

For the most part, I considered the launch a success. People seemed able to run it, and it was selling better than I expected. But I kept receiving sporadic reports (or the occasional negative review) about the app crashing. I followed up with anyone I could, trying to get the steps to reproduce it, but I simply could not get it to crash on my old iPhones… ever! The whole time I kept thinking “if it runs on this old thing, it should run on anything!”

The turning point came when something strange happened with the App store. I pushed a new version (1.1) of the app to Apple for review, and the full version was accepted– but the Lite version was rejected due to crashing. This was odd because they were the exact same code with a few #defines to limit the number of images the Lite version can import. I had to figure it out. The crash report they sent was from an iPhone 4, matching my growing suspicion that crashes were only happening on the newer phones. I bit the bullet and bought an iPhone 4, hoping I could find a way to reproduce the crash (after playing all the latest 3d games of course!) Turns out, I could. First try.

As most developers know, being able to reproduce bugs is typically the hard part. Once I was able to, fixing them was simple. But crashes aside, I was kind of shocked at how many differences I noticed in the way my app looked and ran on the iPhone 4 compared to my other phones. It took barely an afternoon to fix all of the issues I found. Most were related to what happened when memory warnings occurred if a lot of apps were open simultaneously, which explains why it didn’t crash for all iPhone 4 users. Since 1.2 of the app was released, I haven’t received a single crash report. Knock on wood!

Overall, I suppose I’d expected a greater degree of backwards compatibility as I’d been used to with most other SDKs I’ve used. I learned the hard way that deprecated on iOS really means deprecated. Of course I take full responsibility for the quirks that were in my code. But I wrote all this both to remind myself, and to caution others (with limited access to devices) against using a similar development strategy. Expecting an older baseline to provide maximum compatibility didn’t work well for me, though I also don’t know that it would’ve worked any better the other way around. Moral of the story? Assume nothing. Test everywhere. Best of luck.

Posted under: Technology, on April 9, 2011.

If you’re an app developer, one of the best ways to get people to look at your app is to make a short, sweet promotional video that shows off the core features. For apps that do somewhat unique things (such as PhotoTangler), it can be very difficult to describe in words what the app is, let alone why someone should spend their precious time giving it a try. Ideally a video will solve that! In this post I quickly explain the steps I took to create the following promo video:

For starters, the core problem was finding an approach to record video of my app, which could then be cut and edited into a nice promo video. To my knowledge, there’s no reasonable way to export video directly from the iPhone, which left the following primary options: a) Run the app in the simulator, or b) Film the phone with a digital camera.

Given the number of shoddy cam videos I’ve seen for apps (and the fact that I don’t have a good camera), I decided to explore the use of the simulator. The goal was to run the app directly in the simulator, and record video using a desktop capture application. A bit of Google searching revealed a variety of desktop capture apps, at myriad price points. However when I asked my Mac developer friends, consistently the most popular recommendation I received was for Snapz Pro X (no affiliation), which I found to be simple and effective.

Equipped with fancy capture software, the next obstacle was figuring out how to record the actual demo. For apps with simple inputs, recording from the simulator is smooth sailing. In my case however, I needed to use multi-touch to effectively show the features. That’s of course a bit of a problem with a single mouse! That is, until I found out about iSimulate (again, no affiliation.)

iSimulate is a slick app (and corresponding SDK) which lets you use your actual iPhone device to control your app through the simulator. The quick version is that you link with their provided sdk library, then run your app in the simulator. It creates a listen server, which you can connect to from your phone (via Wi-Fi) using the iSimulate app on the device itself. It forwards touch events, accelerometer data, etc, to your app transparently. It can also stream video back to the phone so you can see your app on the device as well. It might sound pretty complicated, but the cool thing is that at least in my experience with it, it just works. There’s a free trial version.

Once I had a way to capture video and device inputs, the rest was a piece of cake. I scripted out a simple sequence of events to show off the main features in under 2 minutes, and quickly edited the pieces together in iMovie. The music I used came from Kevin MacLeod’s Royalty Free Music collection, which has a bunch of great content under the Creative Commons attribution license.

The entire process took under 2 hours, and I’m pretty happy with the results. Hopefully the above explanation gave you some ideas about how to get your own video made. And if you know of any better ways to capture iPhone video or input, I’d love to hear about them.

Posted under: Technology, Tips and Tricks, on April 4, 2011.