iPad App Development – Behind The Scenes

    Since January 27, I’ve been hard at work building the Rackspace Cloud iPad App.  In a sense, it’s a port of the iPhone App, but I don’t like to call it a port because it will ultimately offer much more than what was reasonable to offer on the iPhone.  I’m extremely excited about the eventual final product and about the ultimate user interface potential of the iPad.  I’d say more, but Joe Hewitt sums up my thoughts nicely.

    Start From Scratch?

    The first question everyone asks me about this app is whether or not I started from scratch or used the existing code in the iPhone app.  While reusing the existing code was tempting, I find that I often solve a problem better on my second attempt, and since the iPad screen size makes so much more possible, I wanted to start fresh.  There are however, a few things that I am reusing that I would write exactly the same way today as I did when I first built the iPhone app.

    The first fresh approach I’ve taken is one I picked up while building Cloud Notes.  When I built the Rackspace Cloud iPhone app, I used a framework called Objective Resource, which is a great way to simplify communication with RESTful Ruby on Rails web applications.  I had used it on the Slicehost iPhone apps and it was a perfect fit.  The Rackspace Cloud API, however, forms its XML responses a bit differently than a Ruby on Rails app, so I found myself spending a lot of time altering the framework instead of focusing on the user interface.

    New Approaches to Old Problems

    With Cloud Notes, I took a new approach and tried out ASIHttpRequest, an easy to use CFNetwork wrapper for Objective-C.  While I had to write my own XML parsers, it was ultimately easier because of the clean design of ASIHttpRequest.  The best advantage of ASIHttpRequest for me is that it follows the Delegation Pattern, which I had not considered while using Objective Resource.  Because of this, I realized that I didn’t need to get into the risky business of iPhone thread management to talk to an API.

    So, before the iPad project began, I contributed Rackspace Cloud Files support to the ASIHttpRequest project (Cloud Files support is currently in the integration branch on Github and will eventually be in the official stable version) and then used it for the iPad once the SDK was available.  I’ve since added Cloud Servers support in the iPad code line and will use this approach for any future REST APIs that I bind to in Objective-C.  In fact, I think the ASIHttpRequest approach is so great that I will eventually migrate the iPhone app code to this style.

    Another fresh approach I’ve taken is to take more time than I usually do to build version 1.0. Since the iPad hasn’t been released yet, I have been taking the time to constantly revisit every aspect of the app as I build it, from user interfaces to behavior to even the code itself.  Ultimately, this will be something I will be proud to share on Github.


    From a code perspective, the iPad SDK is essentially identical to the iPhone SDK, but there are a few key differences between the two devices that make development significantly different.

    1. Device Orientation

    The iPhone and the iPad both have an accelerometer that lets the device know how a person is holding it.  If you have an iPhone, you can see the accelerometer at work in the Photos application.  If you’re holding the iPhone upright (portrait mode), but the photo you’re looking at was shot in a landscape orientation, you’ll see a black area above and below the photo since the photo isn’t as tall as the screen.  Then, when you hold the iPhone sideways, the accelerometer lets the Photos app know the device is being held sideways (landscape mode), and the photo is rotated and zoomed into view so it fills the entire screen.

    In other apps, holding the iPhone sideways may present a larger on-screen keyboard that some find easier to use.  However, many iPhone apps (including the Rackspace Cloud app), choose not to support a landscape view because the user interface may be too crowded for the limited screen space when rotated.

    The iPad, however, has a very large screen, so there are few excuses for apps to not support landscape and portrait views (certain types of games are the obvious exception).  Apple will support both in all of their apps, so a third party app shouldn’t force a user to hold the iPad in a different way than he or she wants.  For the app, this means a more pleasant experience for users, and for developers, this means more work designing user interfaces and more time testing.

    2. Screen

    The iPad screen is much larger than that of the iPhone, so the natural inclination is to fill all the new space with buttons.  The Rackspace Cloud iPad app will definitely include more functionality than the iPhone (there’s room now!), but simply adding functionality isn’t enough.  iPad users will expect breathtaking graphics in all of their apps, so extra care must be taken to make the app a beautiful experience. 

For instance, I display server details in a UITableView with a plain pinstripe background.

    This works great on the iPhone, but it looks sparse and bland on the iPad.  So, with the server table on the iPad app, I provide richer details in a table view that doesn’t consume the entire width of the view.  I also add background imagery to enhance the visual appeal.  This wouldn’t make sense on the iPhone, since the background takes up such a small portion of the screen.


    As a Racker, I’m fortunate to have access to several bright people who have been able to help me with any API questions I’ve had.  I know how valuable this is, so if you need any help at all, feel free to reach out to me at mike.mayo@rackspace.com or via Twitter at @greenisus.


    The iPad SDK is a very fun world to immerse yourself in.  It’s an exciting frontier for developers to build new intuitive ways to interact with computers, and I highly encourage anyone with the stomach for learning Objective-C to dig in right away.  When the time comes, I’ll release the source code for this app to the public and welcome contributions.  But even if you don’t look at the code, I can’t wait for you to at least touch this app.

    Once the iPad is released, I will hold a live demo session and you will have the opportunity ask any questions you might have. Stay tuned!

    Rack Blogger is our catchall blog byline, subbed in when a Racker author moves on, or used when we publish a guest post. You can email Rack Blogger at blog@rackspace.com.


    1. I agree with you about a ‘rebuild-from-scratch’ approach to iPad development. The iPad is a fundamentally different device and apps can greatly benefit from going back to the drawing board and getting the design & interaction patterns feel ‘right’ from version 1. I hope a lot more devs will have taken this approach when the iPad finally launches in a few weeks.

      • I hope so too. I only see the universal approach as sensible when you’re building an app that will be essentially the same on both devices. For instance, I’ll port Cloud Notes to the iPad with a universal approach because the functionality will be exactly the same as on the iPhone.

    2. […] Rackspace Cloud Computing & Hosting | iPad App Development … […]

    3. Totally agree! The design of iPad apps shares very little in common with its iPhone version.
      I would personally use more than one table on one iPad screen rather than a single stretched table. This will allow you to present more data on the homescreen.

    4. I was interested in doing something like this for Android. It was going to be for VMware, until I started messing with OpenStack. Where would I start to understand the Rackspace cloud API? Also, would it be easy to port this to Android and could it actually work with OpenStack? Our leaders at my workplace don’t want to move anything to the cloud, but we do have a lot of hardware and a really fast connection to the Internet that I could use to build something for our developers.


    Please enter your comment!
    Please enter your name here