Developing iPad Apps: 5 Lessons Learned

We recently completed our first ever app for the hottest gadget of the year: the Apple iPad. We’ve been wanting to build something for iPhone/iPod/iPad for a while now, but finally got our chance.  And while we’re proud of our first app, the process was not without its challenges. Here are five quick lessons that we learned by entering the world of iPad:

1. The Apple Giveth, And The Apple Taketh Away

Our first rude awakening that we were in unfamiliar territory was when we started dealing with Apple. I am an admitted fanboy and greatly admire the whole ecosystem that Apple has created around iTunes and its mobile devices. But their insistence on control in every phase means that getting up and running as a developer is not a simple process. You are painfully aware that you are playing by Apple’s rules at all times.

A breakdown of a few difficulties in the process:

• To even think about (legitimately) developing for iOS devices, you have to first register as a developer with Apple. There is a yearly fee of $99, and you are only admitted after a fairly thorough approval process involving legal proof of identity. For us, it required phone, fax, telephone and a notary public. And this process is not instant.  It took us nearly a week, but there are reports of companies waiting months for approval.
• Once you have an app to test, getting it on a device is a multi-step process. You must create a developer certificate. Next, you must register the device with Apple and sync it with your iTunes. Then, you must develop a provisioning profile. And finally, you must ensure that all these puzzle pieces fit together as you compile and install your application. Otherwise, your app is simply not going onto your device.
• Deploying your app on any more than one device will then require the appropriate licensing. This means setting up a new profile based on how you plan to distribute and use your app.
• If you choose to deploy your app to the iTunes Store, you can expect another thorough approval process that can take months to complete.

There are good reasons that the process works the way it does. And I’ll admit that the result is overwhelmingly positive for the end user. But when it comes to client work, you should set deadlines and make promises very carefully if Apple is involved.

2. Start Developing Yesterday

On top of all the time issues I just outlined in the previous lesson, you can count on delays at every turn in this work flow. Web design is not without it’s quirks and frustrations, but this process really tested the sanity of myself and our developer. If you’re not familiar with the term “Burn Rate”, you will be when you’ve finished your first app. There are difficulties registering with Apple. It’s easy to screw up your developer certificate. The device won’t sync. The code did not compile correctly. On and on and on. The best advice I can give is to leave more than enough time to get hung up at every step of the process.

3. It’s An iPad – Use It Like One

Every platform has its own inherent strengths and weaknesses, and the iPad is no different. But as I previously mentioned, the process of developing an iOS app can be significantly more time consuming than others. So the decision to take on its challenges should be made carefully, and in order to make the time investment worthwhile,  you should ensure that your app will take advantage of the device’s unique capabilities.

For example:

• Portability – Because of its sleek form, robust battery and web connectivity, the iPad is particularly well-suited to those who travel, who work standing up or who need 24/7 access to the app’s features.
• Touch Screen -  A touch screen means no need for a keyboard or mouse for input — so it is effective in almost any situation. It is also easily passed back and forth for collaboration or demonstration.
• Multimedia – The iPad is a very capable device for storing and playing video, audio and other multimedia. Look for opportunities to use multimedia where you may have previously be unable to.
• Ease of Use – Ask yourself who your target user is. The iPad’s easy-to-learn interface may open doors for less tech-savvy users who previously may have been uncomfortable relying on digital solutions.

4. We’ve Got An App, Now What?

It’s pretty easy to get swept up in all the shiny new features you’ll have once your app is finished. And so there is a risk of overlooking  all the other implications that come with adopting a new technology. You may find yourself happy with your new app, but presented with a whole host of unanswered questions:

• How are we going to deploy the app to our user base?
• How will users be trained?
• Who is going to maintain the devices?
• How will we handle updates?
• Who will provide tech support?

Be sure to start considering these questions very early in the process. The answers may have a significant impact on how the app is built and used.

5. Adobe Has A Long Way To Go

We chose to use Adobe Flash CS5 as our development platform because of our familiarity with its features and our restrictive deadline. This let us bypass the learning curve associated with using Apple’s developer tools in an attempt to save time. However, there were so many problems stemming from this work flow that the time differential between the Adobe and Apple models was probably negligible.

I won’t come down on Adobe too hard because, after all, it is their first attempt at compiling their proprietary Actionscript into Objective C. And Apple did not help things by first approving, then banning, and finally ok-ing the Adobe model again all within about nine months (leading to sporadic development and support by Adobe). But the fact remains that the whole process is riddled with bugs, is light on features, and is supported by almost no documentation.

It was our decision to go this route, and we knew most of these dangers going in. But given the number of Flash developers out there who would love an easy transition to iOS, we hope Adobe puts some work in to improving this model.