Impressions of iPhone Application Development

This article provides a summary of my impressions of writing software for an iPhone, after spending a couple days playing around with the SDK and doing online tutorials to build sample apps. This article is intended for folks who have not done development using Apple's iPhone SDK (Xcode, Interface Builder) but are curious about it.

Let me provide some context on my background, so you know where I'm coming from:

• Prior to purchasing an iMac just over a week ago, I had never done any coding on a Mac platform
• This was the first time I had written code in Objective-C
• I am a software architect who has worked primarily on systems running on Linux/Unix platforms. I have been doing OO Design and Development for 13 years
  

I will use the term "iPhone" throughout this article, but that implicitly includes iTouch devices.

Development Platform
You have to use Apple's SDK on a Mac platform to do the coding. There is no SDK for Windows. Also, the only apps that you can distribute on Apple's App Store are ones that have been built on a Mac platform.

While you can "jailbreak" your iPhone so that you can write code for it on Windows, you won't be able to distribute / sell your apps on the Apple App Store. That's a significant business concern. You can sell / distribute your jailbroken apps on a site called Cydia, but I don't know many iPhone users would "jailbreak" their phones and buy apps from a 3rd party other than Apple.

So, on the one hand, developers benefit from the iPhone platform, which provides:

• a soup-to-nuts platform for distributing and selling their apps through the Apple Store
• a growing customer base (iPhone = mass market)

On the other hand, here are the downsides:

• you have to develop Apple's Way: their platform + their SDK
• Apple takes a 30% cut of sales from iPhone apps
• to register as an app developer costs $99+

If I were to write and sell an iPhone app, I would consider a "fremium" implementation and figure out how to charge customers for upgrades outside of the App Store, so I could limit Apple's cut on my product. But that is a whole different topic.

From a business perspective, I decided to go with the "standard" way of write iPhone app code, which meant I had to buy a Mac. That was fine with me, it was a good reason for me to learn the Mac platform (where stuff lives, keyboard shortcuts, etc). So far, I've enjoyed using my iMac, but that is another topic for another day.

So I bought my iMac and registered on the Apple Developer site. I submitted an application for my company 6 days ago, and I am still waiting to hear from Apple if it's been approved. In the meanwhile, I downloaded and installed the SDK. You don't actually need an iPhone device to write apps; there is an iPhone Simulator for running and testing your code.

Impressions of the SDK
I'm not going to go into detail about how to use Xcode and Interface Builder, as online tutorials cover that.

I do recommend the tutorials on icodeblog.com; you can start with the Hello World tutorial. While Apple's site has good reference and architecture documentation, I recommend using online tutorials on blogs, because you can read the comments and questions from other folks using those tutorials. That's not a ding on Apple, it's typical of a lot of development languages, frameworks, and toolkits. It's the power of Web 2.0.

In terms of ramping up on iPhone app development, there are really 2 separate topics:

1. learning the programming language Objective-C
   
2. learning the Xcode and Interface Builder SDK apps
   

Impressions of Objective-C
I programmed C and C++ middleware back in the 1990s for several years, and I did some complex makefile writing. But since 1997, the OO language I've used the most is Java. So it was interesting to see header files again; I've gotten used to having one file for the interface and implementation, as is the case with languages such as Java and Ruby.

A big part of the learning curve for Objective-C is learning the API libraries. That's the case with any language.

Several things stand out about Objective-C:

1. you have to manage memory
   
2. the syntax for invoking methods on an object
   
3. it supports dynamic typing

A lot of developers think memory management isn't difficult, but people are forgetful and make mistakes, which lead to memory leaks. A lot of the tutorials I saw actually neglected to free up memory in the dealloc method, e.g. for the IBOutlet variables used in Controller classes:

- (void)dealloc {

[txtFirstName release];

[txtLastName release];

[lblMessage release];

[super dealloc];

}

The other interesting thing is the syntax for invoking methods (messages) on objects. E.g.:

Fruit *orange = [[Fruit alloc] initWithName:@"Orange" description:@"Citrus rocks for juicing"];

That statement says to allocate memory for a fruit object, then initialize it with 2 hardcoded string parameters.

Objective-C supports dynamic typing (as do other popular framework languages such as Ruby), here's an excerpt from Wikipedia:

Objective-C, like Smalltalk, can use dynamic typing: an object can be sent a message that is not specified in its interface. This can allow for increased flexibility — in Objective-C an object can "capture" this message, and depending on the object, can send the message off again to a different object (who can respond to the message correctly and appropriately, or likewise send the message on again). This behavior is known as message forwarding or delegation (see below)

You can read more about Objective-C elsewhere. There has been really intense debate on the choice of Objective-C as the language for iPhone development.

Impressions of the Xcode and Interface Builder SDK apps
Xcode is the "main" IDE for organizing files and resource in projects and writing Objective-C code. Interface Builder (IB) is the tool for UI elements: specifying UI elements on the canvas, setting their properties, and tying them back to Controllers in XCode.

The Xcode and IB IDEs have the typical Apple high-quality "polish" in terms of elegant UI design, and they are very stable.

Here are some criticisms:

1. There isn't a built-in unit testing framework for iPhone app development
   
2. The console/log error messages and stack trace can be quite cryptic
3. Xcode and IB are separate apps. You need to be conscious about saving files in one IDE if you are working with the other IDE

I was disappointed to find no built-in unit testing framework in Xcode for iPhone app development. One powerful trend in software development has been the rise of unit testing as an critical step in the process. Unit tests improve the quality of code, enable you to re-factor with confidence, etc. Google has written a unit-testing toolkit for iPhone app development, and Luis de la Rosa has written excellent articles on his blog about using it.

The console error messages can be quite cryptic, and the stack trace is not human-readable. E.g. here are the console error messages caused by an unrecognized method ("selector") call on an object:

2009-05-12 09:04:47.870 HelloUniverse[1098:20b] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[NSCFString fooCall]: unrecognized selector sent to instance 0x55c690'

2009-05-12 09:04:47.871 HelloUniverse[1098:20b] Stack: (

2459910411,

2473467451,

2459939594,

2459932940,

2459933138,

10465,

816115430,

816516406,

816517630,

816514372,

816216343,

816148479,

816144864,

827743722,

827753484,

2459411957,

2459413720,

827745792,

827745989,

816114848,

816160924,

9156,

9010

)

The 3rd point is a minor one, but still worthy of note. I was expecting 1 IDE not 2. When you write code in Xcode, you should make sure to save the file(s) before toggling over to IB, and vice versa.

Summary
Apple has provided a feature-rich app development environment, albeit limited to their own Mac platform and SDK. Apple could improve their SDK for iPhone apps to support unit testing and make tracking down bugs easier.

I'd love to hear your opinions, so please post them!

Why I Started This Blog

Back in 2002, I wanted to write about my experience in getting Linux to run on a Windows laptop, because I was sure other folks had the same questions and issues that I did.

The question back then: should I roll my own site or use a blogging tool?

I checked out some blogging tools, including Blogger, and decided to roll my own site (Ed's Software Guide on Linux), because

• blog software back then wasn't as evolved as it is now
• I wanted to set up multiple sites on different topics (e.g. linux, online gaming, and Raiders football) and manage them with 1 account
• I wanted control, partly because I was learning and experimenting with CSS
  

In retrospect, I made a mistake: my sites didn't support user comments. So I missed out on a huge value-add of Web 2.0: input and interaction between users.

I got a lot of emails, thousands actually, regarding stuff I wrote on my Linux site. E.g. one page in particular has been listed top 2-3 on Google for almost 7 years, and it's been viewed millions of times and translated into 6 languages. That was really cool.

While it was worthwhile building that site, both in terms of what I learned in doing so, as well as sharing knowledge that was helpful to people, I didn't publish that content in a Web 2.0 way.

So here I am, 7 years later, trying a blogging service. I've read multiple articles on choosing a blogging platform (best and current article by Melanie Nelson). For simplicity I'm going with Blogger, because it's easy-to-use and I am more concerned with cranking out content than having complete control. Down the road I may switch to another blogging platform (or run my own on a framework like Rails), and if I switch, I'll state why on this blog.

I'll use this blog to write about technical challenges I run into, especially when I can't find clear documentation on the Internet, because I won't be the only person wrestling with any given issue. And my hope is that people will Google and find an article from my site that enables them to solve their problem.

Cheers,

Ed

Palm to iPhone Data Migration Guide (for Mac Users)

This guide describes how to migrate (transfer/convert) the data from your Palm device to your iPhone, if you are using a Mac. If you are using a Windows computer, look elsewhere for help.

There are many different ways to migrate data from Palm to iPhone. Here are the benefits for following the approach in this guide:

1. you won't have to buy any software. Just use the default software for both devices
2. you won't have to import/export any data manually
3. you won't have to upload any of your data to a 3rd party site (e.g. Google). If you're concerned about privacy, I'm right there with you
4. you won't have to "jailbreak" your iPhone
   
5. the process I describe is logical and repeatable
   

Are there any gotchas with my approach? Yes, but they are issues with how Apple implemented the iPhone:

1. iPhone doesn't support Palm Memos or Palm To Do's. iPhone has a Notes app, but there is no mapping from Memos to Notes
   
2. iPhone Contacts does not support custom user fields. Palm supports up to 4 custom user fields for addresses
   

Step 1: sync your Palm device using HotSync Manager to Palm Desktop

Think of this as your final sync, after which your Palm device is no longer where you manage your address book or calendar. By doing this, you'll have the data on your Mac, accessible via the Palm Desktop app, that doesn't get copied over to your iPhone.

If you were already using HotSync on your Mac for your Palm device, HotSync, then skip to Step 2 iSync your Palm device.

If you weren't using HotSync on your Mac (this was my situation, I had a brand-new iMac), you need to get HotSync working:

1. install your Palm Desktop software from CD, or if you don't have it anymore, download the Palm Desktop software that closest matches your device from palm.com. It's OK if you don't see an exact match, just download the latest Palm Desktop software. It should work, with some possible tweaks below
2. during the installation process, when prompted for a user, create a fake one (e.g. "Fake User")
3. launch Palm Desktop from your Apps directory. You should see 2 user profiles, one for your Mac account and the fake one. Delete the fake one
4. connect your Palm device via a USB cable to your Mac, and hit the HotSync button on your Palm cradle. This may take a while, depending how much data you have. If your Palm device reports an error "SystemMgr.c, Line 185, Unimplemented", your Palm Desktop may be trying to sync conduits (aka apps or modules) that your Palm device doesn't support. That is, HotSync is asking your Palm device for data it doesn't have. This happened to me because my Palm device didn't support a "Media" Conduit. To fix this, in Palm Desktop, go to: HotSync -> Conduit Settings, and set any unsupported conduits to "Do Nothing" using the "Make Default" button:

You now have all of your Palm device data available in Palm Desktop app, in case you ever need to go back to it.

Step 2: iSync your Palm device to Mac's Address Book and iCal apps

Now that you have a backup of your Palm device data in Palm Desktop, it's time to move the data that Mac supports into Mac applications. The flow of data looks like this:

1. launch the iSync app
2. select Devices -> Enable Palm OS Syncing
3. launch Palm Desktop
4. select HotSync -> Conduit Settings, then for iSync Conduit, click the checkbox for "Enable iSync for this Palm device"
5. make sure your Palm device is connected, then hit the HotSync button. The data in your Palm device will get copied over to the Mac Address Book and iCal apps, per the diagram above. This may take a few minutes, esp if you have a lot of records in your Palm device

The most complicated steps of the process are now behind you :)

Step 3: sync your iPhone to the Mac to pick up the Address Book and iCal data

You're now ready to hook up your iPhone to your Mac. Your iPhone syncs to the Mac using iTunes, and under the covers (from what I've read) iTunes uses iSync to synchronize the Address Book and iCal app data:

You can now follow the really brief instructions in the "Finger Tips" guide that came with your iPhone:

1. Download/install iTunes
   
2. Connect your iPhone to your Mac
3. Sync, following the instructions in iTunes

You're done!

I hope this guide was helpful, please post any feedback / corrections.

Cheers,

Ed

FAQs

Q: Is it possible to sync data back to my Palm device?

A: Yep. Just configure your Mac, per the diagrams above. I've been able to add a calendar event to my iPhone, sync that event through iTunes to iCal, then use the iSync Conduit to HotSync that event back to my Palm device's Date Book app. I would recommend, though, that you pick either your iPhone/iCal or Palm/Palm Desktop as your primary place for editing data.

Q: I was an avid user of Memos, what the heck am I supposed to do?

A: I wish there was a good answer. If you did Step 1 above, at least you have your Memo data accessible via Palm Desktop. As far as how to store memo-like information in an iPhone, check out this article.

Q: Some of my Palm address fields didn't get transferred, in particular my custom user-defined ones.

A: Unfortunately, those fields are not transferred. Palm allows a user to define up to 4 custom fields, but Apple does not support custom fields (the list of possible fields is pre-defined and fixed). I had 4 custom fields defined in my Palm: account #, cross street, rating, and price. I used the rating, price, and cross street fields when adding a new restaurant. I may have to move those custom fields manually (ugh) into the Notes field in Mac Address Book.

Q: Where do I access my iPhone data on the Mac?

A: iPhone doesn't have a corresponding desktop app, like Palm Desktop, for managing your address, calendar, memos, and to do's. On a Mac, you manage your media files (music, video, etc) with iTunes, your calendar with iCal, and your addresses with Address Book. And not all the data in the iPhone (e.g. your Notes data) is sync'd to your Mac.

Appendix: our switch from Palm to iPhone

My wife and I both switched from Palm devices to iPhone 3G devices the weekend that I wrote up this guide:

• my wife had a Treo 700p, which she sync'd to her Mac laptop
• I had a Samsung i500, which I sync'd to a Windows laptop. I also migrated to using a Mac workstation (iMac)

Obviously my case was more complex, as I switched not just the phone but the computer too. But once I figured out how iSync and HotSync on a Mac worked, I was able to use the same approach for migration.

I started using Palm devices in 1997, and I bought a lot of the original wireless-enabled Palm devices:

• 1999: Palm VII: this device used the same network that the RIM Blackberry devices used, but it wasn't a phone
• 2001: Kyocera QCP-6035: this was one of the 1st PDA/phone Palm devices on the market. It was a brick in terms of size (about 2 inches taller than today's iPhone, and much heavier), the device was painfully slow, and the display didn't have colour
• 2001: Samsung i300: I re-sold my Kyocera on eBay and upgraded to the i300. It was the 1st successful Palm PDA/phone device in terms of usability, size, and performance. My main complaint was that there was no tactile keypad; the keypad was digital
• 2004: Samsung i500: this 1st Palm phone that had great form factor and size. I loved having a tactile keypad for dialing, and that the screen was flip-up, so I could close it to protect it and stow in my pocket. I used this phone for years, as most of the PDAs that came out after were too bulky for my taste. Did I happen to mention this device had a killer form factor? I will miss it!

In my short time using my iPhone, I've come to realize it's a wireless media device + phone, whereas my i500 was a phone + PDA with strong support for data entry. I'll write up the differences in another article.