Getting Started on the iPhone: A Primer for Non-Mac Development Shops

What do you do if you're an existing software provider and you want to get into doing iPhone Development? Well, if you're already a Mac developer using Cocoa, you're probably already elbow-deep in the SDK and having a blast. But if you're a mobile developer who has worked with other platforms, or if you are primarily a Windows or Java shop,  the prospect of getting into the iPhone is probably daunting. You've likely had some of your developers sign up for the SDK and start reading up, and chances are they're having a a lot of big WTF moments.

So, let's take it step-by-step. How do you get up to speed quickly if you're completely new to objective-C, Cocoa? Here's a high level plan for you.

1. Join the Apple Developer Connection or ADC. This is Apple's developer support organization, similar to MSDN. There is a free membership available, but splurge for at least the Select membership, which entitles you to a hardware discount, some one-on-one support with Apple engineers, and access to Apple's compatibility labs. You'll also become seeded, which means you'll get early access to software, including versions of the iPhone OS. If you're serious about bringing existing applications to the iPhone as quickly as possible, consider splurging for the Premier membership. Make sure anybody on your team who's going to be looking at the SDK signs up with at least a free membership so that they are covered by the iPhone SDK.
2. Have your developers learn Objective-C. At first, don't worry about Cocoa (the application building framework), just have them learn the syntax and nuances of the language it's based on. Your more advanced developers can probably get by with just reading Apple's language reference, as it's a relatively simple superset of the C language.  There are other books that will take you a little more by the hand through the language for people who need it. Unless your folks have worked with something like SmallTalk before, some of Objective-C's syntax is going to feel alien at first, but it's really an elegant and rather fun language to work with once you get over the initial hump. 
3. Buy some Macs. If you've downloaded the SDK, you've probably already figured out that you need a Mac to code for the iPhone. And you need an Intel Mac, and it has to be running Leopard (the latest version of Mac OS X - it's version 10.5). If you joined ADC as I recommended above, you can get a substantial discount on buying your hardware, which is why I had you do that before buying any hardware.
4. Learn Cocoa. Cocoa Touch is a bit different from Cocoa, but a lot of the design patterns, and all of what Apple calls "Core Foundation" is common between the two, so it's a good idea to learn it, even though a lot of the stuff won't be directly relevant to coding for the iPhone. The Big Nerd Ranch offers training classes in Cocoa that are supposed to be excellent. There are also several books out there on programming Cocoa, unfortunately, as of this writing, none of them have been updated to use Objective-C 2.0, the version of the language used to develop for the iPhone.
5. Start dissecting the sample code. Play around with the iPhone templates in Xcode, and browse the API documentation. Experiment. Play. Do a bunch of stuff wrong before starting on porting or re-writing any of your applications.

Okay, I know you were expecting something better than step 5. Unfortunately, because the iPhone SDK is under NDA, and will be until June, nobody can publish books or articles on how to code in Cocoa Touch until that time without violating their NDA. Places like the Big Nerd Ranch can't offer classes prior to June (although I notice they're thinking ahead and have an iPhone class scheduled for September - sign up now if you're interested, their classes often sell out).

If you want to be one of the first ones out of the gate, and you aren't a big enough company to warrant special attention from Apple and don't have deep enough pockets to lure away their existing iPhone developers, you're basically stuck with this approach for now. You need to let your developers experiment in lieu of formal training, or else you need to resign yourselves to waiting and losing the competitive advantage of being an early entrant into an emerging market.