Like lots of other Apple-faithful, I had pre-ordered and iPad and received it on iPad launch day yesterday - April 3rd. Since I develop software for the iPhone and iPad, it was a definite requirement to have an iPad in-house for testing as soon as possible.
While I did have a native iPad app (Artificial Life - HD) ready for sale on launch day, it was a bit of a leap-of-faith endeavor. The Artificial Life app makes use of a lot of texture maps via OpenGL and the performance on the provided iPad simulator from Apple was less than ideal. In all my initial development and testing using the simulator, the frame rate was pretty poor - around 9 frame-per-second. Since it was not possible to test on a real device before the iPad launch day, the simulator was the only available baseline. I knew based on iPhone testing that for certain optimized OpenGL operations (such as using PVRTC textures) the simulator was significantly slower than the iPhone hardware, but for a lot of other simpler operations the simulator was faster than the iPhone.
Apple had required that in order for an iPad app to be guaranteed available in iTunes on launch day, the app had to be submitted to Apple for initial review approximately a week before the launch date. Not wanting to miss the opportunity to be in the store on launch day, I optimized things best I could and sent the app to Apple for review. Thankfully, Apple approved the app with no comments regarding poor performance, but still I was a bit apprehensive. I did however have a fail-safe option. Since I knew I’d be getting my own iPad on launch day, worst case, if the performance was really bad, I could just remove the app from the store. Thankfully, that turned out to be unnecessary.
The Good
The iPad turns out to be one speedy hand-held device. My own app, which ran at a poor 9 frames-per-second in the simulator was running at a smooth 35 frames-per-second on the actual iPad. Because of this, I’ll now be able to make some significant enhancements to future updates of this app - the main one being able to increase the population cap from 300 individual protozoa to over 1000, without much a noticeable change in frame rate.
Others have done some benchmark comparisons of the iPAd processing speed vs. the iPhone 3GS and the results are impressive. For CPU operations the iPad is on average about twice as fast as the iPhone. Based on what I am seeing with OpenGL performance, I suspect the graphics chip may be more than twice as fast than the one in the iPhone 3GS.
While the iPad shares much of the same SDK functionality as the iPhone, the larger screen on the iPad makes possible a lot more functionality than the iPhone. Those who say the iPad is just a larger iPhone are missing the point. The iPad isn’t just a larger iPhone. A more accurate comparison might be to say the iPad is a smaller laptop. The things you can do on an iPad are a lot closer to laptop activities than iPhone activities, and once you start developing applications for the iPad this quickly becomes apparent. While a lot of existing iPhone apps will initially be blown-up iPhone apps, in the long term there will be a much richer experience available with the iPad versions of apps in comparison to iPhone apps.
XCode project conversions
Since many developers will have existing iPhone apps, Apple has made it fairly easy to do an initial port over to the iPad from an iPhone project. There’s a built in menu item which gives the option to convert a project either to a Universal app (which supports both iPhone and iPad) or modify the project to it now contains two separate targets - one for iPhone and one for iPhone. Both options have there plusses and minuses.
A Universal app means just one listing in the iTunes store - someone can buy your app and not have to pay attention to what device it runs on. The drawback is more on the developer side. You have to do run-time checking for which device you are running on and present the appropriate UI. Also, you app will have to contain all nib files and artwork for both versions in one bundle, leading to larger binary sizes.
The double-target approach has the benefit of more easily being able to segment your code. You can use macros to conditionally compile code based on the target. This is the approach I used for Artificial Life.
In either approach, when the XCode project conversion first runs, it automatically creates iPad versions of all your nibs, although their sizes have not automatically been updated - you still have to do that by hand, properly adjusting where all the subviews and controls should be. Also, since Apple highly recommends supporting every view orientation, you’ll want to make sure you have the proper resizing and positioning options so your controls are placed properly as the views rotation. I found this was one of the most time consuming parts of my application porting to the iPad.
Pop-overs are your Friend
One very handy new UI element for porting and iPhone app to iPad is the UIPopoverController. As the name implies, it’s a window that appears over a portion of the screen. From a developer’s perspective, think of it as a modal View Controller that isn’t full screen. What is nice about these is they can take a UIViewController as an argument when they are initialized. This makes converting existing helper view controllers very simple. If you previously had a UIViewController on the iPhone which was used for configuring something, you can easily re-use it as a pop-over without having to change any of the underlying UIViewController code. Just make the pop-over the same size as the original iPhone UIViewController and you instantly have your existing view controller now working as a pop-over.
Using this approach is very helpful if you want to make a fairly rapid port of an existing iPhone app. For example, using this technique I was able to have a fully working iPad version of my existing Artificial Life iPhone app in just one day. For iPad, Apple discourages the use of full-screen transitions which were common on the iPhone (such as animated page slides), so using pop-overs for such content is an easy solution. Granted, long term I’ll be making a lot more enhancements to the iPad version of the app to take better advantage of the larger screen real estate, but short term, this was a quick way to get something up and running with a fairly good presentation.
The Bad - the iPad App Store
One thing with which I was very disappointed on launch day was the iPad App Store. For an indie software developer without a large advertising budget, the new design for the app store is absolutely terrible. As of this date, Apple no longer provides a way to browse the full categories of the app store. Sure, they list all the store categories (music, games, education, etc.), but going to view any one category now gives a limited “New and Noteworthy” view sometimes accompanied by a “What’s Hot” category. Completely lacking is a way to browse all the apps in the category. If you aren’t lucky enough to have your app featured by Apple, the only way a customer will find it is via keyword searching.
I’m hoping this is just an opening weekend glitch, but nevertheless this was a huge disappointment, especially after Apple had encouraged developers to have their apps ready for launch day. Shopping the iTunes store via iPad right now feels sorta like walking into a Wal-Mart and only being allowed to walk into the first 20 feet of the store. Anything else you might want to buy, you have to ask someone to get from the back room for you.
Posts
