Monday, March 17, 2008

iPhone SDK Thoughts

It's been a little over a week since the iPhone SDK announcement on March 6, and of course I downloaded the SDK. For a good general overview, I recommend reading Kevin Hoffman's take. I have started development on something I have wanted for the iPhone pretty much since it came out. With the economics of iPhone development and distribution through the App Store pretty good, if you have any idea, why wouldn't you?

As with all iPhone SDK developers, we are under NDA and not at liberty to discuss anything we know because of having the SDK. I want to address though once part of the conversation, that moving from .NET and Visual Studio to Ojective-C and Xcode hurts...bad. First, you can't go from a class library/runtime (.NET) to a language (Objective-C). You go from .NET to Cocoa. The language analogy is closest between C# and Objective-C, though of course you can be using any number of languages in .NET, you really only have Objective-C for OS X development in general (though there are some choices), and specifically on the iPhone that's all there is. But language syntax isn't that much of a switch right, the real pain is learning a new framework. That all said, does moving from .NET/C# to Cocoa/Objective-C hurt? Only a little bit, and I believe starting with the iPhone SDK actually makes it easier. How? Because by necessity Cocoa Touch has to be a subset of Cocoa for Mac OS X (Cocoa Click?). The footprint on what you have to know to get work done is greatly diminished. But it's more than that. Interface Builder for Cocoa Touch isn't available yet, so you have to wire up Views to Controllers completely manually. This sounds like a chore, but what I had previously found dabbling with Cocoa on Mac OS X and the whole Xcode tool chain was hooking up views to controllers was the possibly least intuitive bit of the whole experience. That's because with .NET and Visual Studio, you just double-click on a visual control and you end up with an event handler somewhere, no matter what. With Cocoa, nearly all frameworks, project templates, and the tools are built around the Model-View-Controller (MVC) pattern. This is a pretty decent mental departure for .NET developers because with either ASP.NET or WinForms to date (ASP.NET MVC is in beta), neither use a any kind of pattern other than "drop your controls on forms and handle events". Anything past that is really up to the developer to implement. With Cocoa, you really have to understand how the pieces work together before you can build even a crappy app :-).

So if you are a .NET developer and are interested in iPhone development (or Mac development for that matter), don't listen to the fear mongering and dive in. Even with someone that says they "tried OS X development, it was scary", they may not have looking at Leopard, Xcode 3.0, and Objective-C 2.0, when the whole stack saw monumental revisions. One word of caution though, on Mac OS X 10.5 with Objective-C 2.0 you get garbage collection for memory management, on the iPhone, it's the old style release/retain mechanism.