Destination: iPad

For the past few weeks, we’ve been working on some side projects at Needmore HQ, with the intention of bringing our own apps to an iPad near you. We see this side project as a convergence of several things we are really into right now: our child, our iPads, fine art, and a longing for the days when building interesting stuff in Flash was a realistic option for web designers.

Getting Started

The biggest obstacle to a newcomer to iOS development is the steep learning curve associated with developing in Objective-C, using the Cocoa Touch framework, in Xcode. None of these are things I have any experience with whatsoever, and since iOS developers are in such high demand, we’ve decided that we’re not interested in hiring someone for this work, at least not quite yet.

So that leaves me to learn these things more or less on my own here. And so I began my journey. Unfortunately, having just turned 39 yesterday, my brain is made up of an extremely firm substance that is incapable of taking on new knowledge like it used to. So while learning these things, I decided to shop around for some alternatives (or, ways to “cheat”).

Luckily, there are a ton of alternatives to brute-force development in Xcode. We’ve already experimented with a few, researched a bunch more, and they cover a complete spectrum of options. Many of them are very compelling, all of them involve a great deal of trade offs. Here are some highlights from our investigation.

Baker

First is the Baker e-book framework. This is undoubtedly the easiest option, since you really just need a series of HTML files. Being a web developer, that’s not a problem at all. You just build a series of “pages” with HTML and CSS, aiming for the 768 pixels width of a potrait-oriented iPad, then build the resulting project in Xcode. In just a few hours, you’ve got a custom-designed e-book on your iPad. You can swipe left and right to navigate between pages, and swipe vertically to read more. You can even embed JavaScript if you need more interactivity, but it needs to be fairly simple.

We’ve already built a Baker project to show to a client, and while they were suitably impressed with how quickly we had a working app, the limitations are very apparent if you want anything beyond a simple e-book.

PhoneGap

Next, in terms of complexity, comes the PhoneGap framework. This is a little more ambitious than Baker in that it lets you make just about anything you want, using HTML, CSS, and JavaScript. Using PhoneGap (and optionally, a framework like Sench Touch to give you iOS style widgets and features), you can make a very convincing app. You can’t build games or anything processor-intensive, but you can build simple apps in a way that we already understand here.

For example, we built a demonstration of an interactive e-book, using navigation widgets that look and behave just like the iPad’s, in an afternoon. It’s by no means finished nor acceptible at this point, but it does work and proves a concept. It’s also probably a decent way to prototype a more complicated app if you’re a web designer and are already familiar with the technologies involved.

Certainly, one big benefit from building in PhoneGap is that since you’re basically building HTML pages, you can use your existing toolset and the things you build can be tested – and used – in any web browser. So if you suddenly decide you want to see your work on almost any other platform besides Apple’s, you can do that. It’s an appealing option, but it isn’t one that interests us that much, since the iPad is the only thing we are building for, and we really want to optimize the experience for that one device. Not to mention that when you’re mostly limited to general web technologies, you aren’t always able to use the cool features of the device. There are exceptions to this rule, but it’s still worth knowing.

An Aside on Performance

So far, neither of these frameworks lets you actually send something to Apple that’s using Objective-C, so you’re on shaky ground. Not only has Apple shown themselves loath to accept apps that don’t use their own programming language, the apps themselves don’t work nearly as well if they’re not in that native language. It’s clear, for example, that an app built with Baker is really just HTML, if you know what to look for.

Why is performance so important? Turns out what we want to develop can be considered a “game.” I don’t like to think of it that way, but we want something that children can interact with, and so performance is important. You want them to believe the illusion; to feel as if they’re really touching something with their fingers. Also, when you’re building a game, you are looking at controlling things like physics and animation of objects on-screen, which is exactly what’s going to make a compelling experience for a toddler.

Although I don’t play many games, I do have experience making them, having spent a year in Santa Cruz during the dot-com bubble building 3D games. Because of this, I’ve got a pretty good idea of the importance of performance and of choosing the right framework from day one. Hence all the painstaking research.

This led us to examine some options for apps that were able to run on the iPad in the native language. Last week, I wasn’t aware of any, but have since stumbled upon several promising options.

Cocos2d

Cocos2d is a framework that lets you add common game behaviors to your Objective-C code. This makes it easier to do the types of things games commonly do, like sprites (cell animation, like running characters), physics, detecting when things collide, having multiple “levels” (pages, in our apps), and so on. Having this at your disposal, for free, means you can build games faster, and you don’t have to reinvent the wheel. This is a very important shortcut.

This framework has actually been written for a number of different environments, and you can even build JavaScript games in a web browser using one of its many variations. It’s very interesting to me, but still very low level, and it still requires that the user master Objective-C, because you’re still writing in native iOS code. I don’t want to do this if I can at all help it.

Corona

Corona is a framework with a twist. It uses a completely different programming language called Lua, which I like a lot. It’s far simpler than Objective-C and reminds me of Ruby, a favorite. You can build and test your app quickly, and then before you submit it to Apple, you build it into native code, so it runs very fast and Apple likes you. While this is a commercial option that costs money, you can also use tools with it that help you to build your scenes graphically, and other such tasks.

When it first came out, Corona was marketed as a general-purpose framework to make iOS development easier. This is reflected in the fact that many of their showcase apps are not games at all, but guides for museums, books for children, and more. That’s also appealing since while we need many of the features of games, we’re not technically building games. Seeing such a variety of apps gives me a greater degree of confidence in the framework.

Another big benefit is that Corona was made by ex-Adobe employees whose goal was partly to make life easier for folks who had experience building Flash work and programming in its ActionScript language. Having looked at this a bit, I find that they’re right – it does feel very similar, and that makes it that much easier to get started with.

GameSalad

GameSalad is something different altogether. You don’t write any code at all. You use a graphical editor to lay out your items, drag behaviors onto them, and move on to the next scene. You can probably build games faster this way than with any other method, but it’s obviously not very flexible. For instance, if you want to customize something in a way that’s not supported by the graphical toolkit, you’re out of luck. I’ve read many reports of outgrowing this environment fairly quickly.

It’s also the most costly option, in that if you want all of the features, you have to pony up $499. Since we’re trying to build this project in our spare time and on a budget, this is a drawback. Also, while I’m not the best programmer around, I do know how to write code, and I would quickly get frustrated with the inability to write even the most trivial code by hand. Without this ability, things that should be simple could quickly get far more complicated.

Anyway, I think this one would quickly drive me insane. I don’t like the idea of something so user friendly and so social. It was slow and clumsy, and just plain feels wrong.

Conclusion

In the end, we’re leaning toward Corona for our work, but we will certainly keep the other options in mind. It’s been in use for at least a year now, and lets you do pretty much everything we want to do, with a much smoother learning curve than I’d expected. It’s given me hope that we can actually start building apps without the daunting task of learning Objective-C and the iOS SDKs from scratch. I still think it’s worthwhile to learn, but I’d rather that was a choice than a prerequisite.

One thing I haven’t really covered here is how excited I am. I had no idea a week ago that it was possible to build these things so easily. I saw this as a very long-term effort, perhaps taking six months to get a working app made. Now it seems like two weeks might be enough for something simple. That’s huge.

It’s as if I was suddenly given a knowledge of physics that a tenured professor might have. I feel obligated to make apps for my iPad, things my two year old can play with. I need to build things that are beautiful and interesting and compelling and unique. If I don’t, it’s as if all that knowledge is wasted. How can I, in good conscience, allow that to happen?

I no longer have any other choice. I must try my hand at building iPad apps.

Raymond Brigleb

Creative Director, dreamer, partner, father, musician, photographer. Has been known to ride the rails. Pulls one heck of a shot.