Journeys inside the iPhone's SDK

I have now spent a pretty solid week writing applications for the iPhone. And what an exciting week it's been. I've been privileged to view and interact with the iPhone in a way that few other people have had the opportunity to. The iPhone is tight, robust and its SDK--even seen through such imperfect tools as class-dump--is beautiful.

Let me give you an example. This morning I decided to write a basic word processor for the iPhone. In about 30 lines of code, I was able to create an application that saved all changes to disk and reloaded that text launching the application. That kind of success doesn't happen because I'm some sort of phenomenal programmer, it happens because Apple makes amazing, usable libraries. I was able to use classic Cocoa strategies like reading a string to and from disk and combine it with new UIKit strategies like creating a keyboard that automatically knows how to enter and edit text.

The hardest part of the process was figuring out how to know when the iPhone Application was about to quit. I fumbled around for a while trying to use standard Cocoa delegates, like "applicationShouldTerminate". In fact, I should have gone straight to the UIApplication include file instead of trying to "Think Cocoa". The correct delegate was applicationWillSuspend. This reorientation of the discovery process is important. The iPhone is not a Macintosh. Its vocabulary, libraries and frameworks reflect that difference.

I've put all the source code for the TextEdit app up over at Textmate.org. If you're interested in looking through the code, here's the Makefile, mainapp.m, SampleApp.h, and SampleApp.m. Or you can find all four on our iPhone hacks page.

As you can see, the application basically sets up a UIWindow, allocates it and establishes its bounds. It then adds a main UIView and to that view adds two subviews: the text and the keyboard.

I added persistence (the way the application remembers its text from one time to the next) with two lines, both provided by NSString. The first writes the string to a file, the other creates a string with the contents of that file. That's a pretty awesome amount of power for two lines of code and again shows why Apple rocks.