Introduction (IPhone Application Development)

In the first edition of iPhone Application Development For topic, I said that when Apple opened up the iPhone to developers, I got as excited about developing software as I did when I first discovered the power of the Mac. And you know what, I still am.
As I continue to explore the iPhone as a new platform, I keep finding more possibilities for applications that never existed before. It is a mobile computer, but not simply a mobile desktop. Its hardware and software make it possible to wander the world, or your own neighborhood, and stay connected to whomever and whatever you want to. It enables a new class of here-and-now applications that allow you to do what you need to, based on what is going on around you and where you are.
The first edition of iPhone Application Development For topic was based on iPhone OS 2.2.1. When iPhone OS 3.0 was released, and then quickly followed by OS 3.1, I knew that I had to do a second edition. There were some additional features that I wanted to show readers how to use. The new MapKit, for example, makes it much easier to use the location-based features of the iPhone in an application. This is a significant step forward since one of the hallmarks of a great iPhone app is that it leverages the iPhone’s unique hardware, especially its ability to know where the user is. The new MapKit makes it possible for even a beginning developer to take full advantage of the location hardware, and I’ve added a new topic to show you how. There are also some other changes to the nuts and bolts of how to develop iPhone applications that required changes in the examples I showed about how to use the SDK to create real applications.
But as important as iPhone OS 3.1 is, Snow Leopard and its accompanying Xcode release 3.2 are (almost) equally as important. OS 2.2.1 and Xcode 3.1 provided a set of mature, easy-to-use, and (the best part) free tools. The frameworks were amazing! I had used frameworks before, but the ones that came with the iPhone were especially rich and mature. All I really had to do was add my application’s user interface and functionality to the framework, and then “poof” . . . an instant application.
But are you ready for this — from a developer’s standpoint, Xcode 3.2 is a lot, lot better and easier to use. This became obvious when I first started using a beta version. In fact, I subsequently moved all of my own and my team’s development to Xcode 3.2, and when I do have to use Xcode 3.1, I find myself grumbling the entire time.
As a result, this new edition is based on iPhone OS 3.1 and Xcode 3.2. If you want to learn how to develop applications, this is the set of tools you absolutely need to use to do it the right way.
If this seems too good to be true, well, okay, it is, sort of. All that convenience comes at a cost. At first, it was really difficult to get my head around the whole thing, conceptually speaking; sometimes I found it difficult to figure out exactly where (and how) to add my application’s functionality to that supplied by the framework.
And while there were lots of resources, the problem was exactly that: There were lots of resources! As in, thousands of pages of documentation I could read, and lots of sample code to look at. I could only get through a small fraction of the documentation before I just couldn’t stand the suspense anymore and started coding. Naturally enough, there were a few false starts and blind alleys until I found my way, and it has been (pretty much) smooth sailing ever since.
That’s why, when the For topic folks asked me to write a topic on developing software for the iPhone, I jumped at the chance. Here was an opportunity for me to write the tropic I wish I’d had when I started developing iPhone software.

Next post:

Previous post: