Bean Blog

Apple’s iPad holds the promise to be a game-changer. So naturally, we at Bean Creative were thrilled to produce an app available on launch day. But how did we build for iPad before we ever actually got to touch one?!

Having developed for the iPhone/iPod Touch platform, we knew at least that a good portion of the process would be familiar, and figured that porting an iPhone app to iPad would be a great starting point. But when we began this work a month before iPad launch day, everything was a grey area. Would running the app in simulation really be like running it on the actual device?

With iPads in your local Apple store, and iPhone OS 4 and SDK 4 currently in beta, things are about to change again. But here is a look back at some insights from the adventure of building an iPad app using only the iPad Simulator and a lot of caffeine…

The first issue was installing the beta SDK 3.2 for iPad only. This presents an interesting conundrum right from the start: unlike other SDK updates, version 3.2 represents a schism in development. While the tools support both iPhone and iPad development, 3.2 is an iPhone OS that does NOT support the iPhone. From Apple: “Note: iPhone OS 3.2 does not support iPhone and iPod touch devices. It runs only on iPad.” Then why call it “iPhone OS 3.2”, I wonder…As with other iPhone SDKs, the filesize is a few gigabytes, so you may have time for a bite or a weekend in Vegas while it is downloading, depending on your connection speed. Once installed, we had to decide what sort of project we wanted: a brand new one, or a port. We were doing a port of an existing iPhone app. With an existing project to port to iPad, we still had an important decision to make. Apple recommends that you make a “universal app” that will run on either iPad or iPhone. Short of that, they recommend that you setup one project that can publish to either iPad or iPhone.

We actually decided to go with the unstated Option 3, which is to leave our iPhone project alone and instead make a fresh copy that we completely overhauled for iPad. Why? Several reasons: time and budget were high on the list, but we also didn’t want to be debugging both versions simultaneously in such short order. And in our case, the most important decision-making factor was the app itself: our app contains a large number of image assets, and these needed to be revised for the larger iPad size.

Given the overall limitations of iPhone (in terms of memory and storage), we felt that trying to handle many more image assets in one project was ripe for problems and would require a large amount of code modifications to handle the either-or scenario. In the end, we are opting to simply make ‘an iPad copy’ of our existing iPhone app project. [Note: we fully expect to be more integrated with future projects and updates.]

So getting to work, Apple conveniently includes a new “Upgrade Current Target for iPad” command in Xcode, and their documentation says that you should always use this command to migrate existing projects. “Do not try to migrate files manually,” they warn, and we heed this warning and use this command first. Unfortunately, in practice, the process is a little more involved.

After upgrading the target of a project, a simple Build and Run to test on the simulator is unlikely to work (though it may tease by bringing up the iPad Simulator momentarily…). Here we get into our specific experiences… your results may vary.

Right off the bat, if you want to run your project on iPad, the Base SDK has to be set for the project – be sure it is for all configurations – to something that will play nice with the device… meaning SDK 3.2. Once this change was made, we noticed that Xcode began to recognize MOST but not ALL of our included frameworks for the project. Which means we are headed in the right direction, but still not able to run the project. In our case, the Google Analytics library was not being recognized, so after fruitless tinkering, we just deleted it from the project and reinstalled it. And guess what? With all our frameworks in place, we could run the project as an actual iPad app! Woot!

And what exactly did we see? Well, as mentioned, our app contains a large number of image assets done for the iPhone platform. Depending on the code, the iPad version either left them at their original (now TINY) size, or scaled them up to fit the new larger screen. Neither is ideal. The smaller images created a small active window within the much larger iPad screen, and the larger images were clearly pixelated from the scaling process. Plus, any calls to scale, animate or otherwise place objects on screen was now working within a much smaller window.

What we needed to do was: a) revise all the images to create a new library of iPad-sized images, modifying the code as needed to display these images at their new larger size, and b) come up with some sort of multiplier to translate animation points and scales to the new larger screen.

Well, it would be awesome if the iPad was, say, exactly 2 times as big as the iPhone. Then our multiplier would be an easy 2. But iPhone is 480×320, and iPad is 1024×768. That means the multiplier is actually different based on axis: X values can be multiplied by 2.133333 to scale them up, but Y values need to be multiplied by a different factor, 2.4.

Then we began the somewhat arduous process of revising all of our graphics to the new size, as well as modifying code to revise the placement and scale using our multiplier. For our multipliers, we have defined them as:

#define iPadMultiplierX(x) (x * 2.133333)
#define iPadMultiplierY(x) (x * 2.4)

Plodding forward, we got all the new graphics in place and our multiplier working. Everything was generally looking good, until we ran into a really weird issue…

When playing only one part of our app game, at only one specific instance in the game, portions of the iPad screen would flicker. Why? Well, that was the subject of hours of debate and research, including calling in the assistance of Apple tech support. In the end, it was determined that somehow the system was interpreting two overlapping views as actually being on different 3D planes – seemingly impossible since nothing in app utilizes 3D – and was randomly slicing through the top plane to show portions of the underlying plane. Needless to say, this was perplexing, unexpected and a truly unsatisfying tech support response [Rule of thumb for tech support: whenever a tech support response involves the word “somehow”, expect to feel unsatisfied by the process].

The issue however was not affecting any game play and was extremely temporary and small on screen. The revision process has us pulling all elements apart and rebuilding the app in a totally new way to look and play exactly the same [Rule of thumb for programming: whenever a ton of work has to be done to achieve the exact same user experience, expect to feel unsatisfied by the process].

But we did it. We made launch day and the app looks beautiful on the new bigger screen. Now to see how it works on SDK 4…

[SUPER WHY! for iPad developed by Bean Creative for PBS KIDS and Out of the Blue]