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.

3 comments:

Brian Ellis said...

Dave,

Thanks for the comment. I posted a reply if you're interested at:

http://blogs.vertigo.com/personal/bellis/Blog/Lists/Posts/Post.aspx?ID=23#Comments

Brian

.NETeteria said...

Why couldn't there be an SDK for Visual Studio that will allow you to develop in C# and then use a converter and iPhone emulator for compiling/testing. This would be just like AppForge's MobileVB plugin for Visual Basic that enables you to create applications for Palm devices in VB. Is this something that could be done? I'm a long-time C#.NET developer and would love to be a part of creating something like this. Thoughts?

Dave Murdock said...

@.neteteria

I am not familiar with AppForge's MobieVB plugin.

Quicktime, Safari, and iTunes for Windows all port parts of the OS X kernel, Carbon, and Cocoa, so Apple at least has a good deal of experience with some of it. That said, while you can't say it can't be done, I don't think it very likely that Apple would release something similar. Just get a Mac, you can run Windows on it native or VM, and you can do iPhone dev on it. Apple has a feedback loop now with iPhone dev, there is just very low chance they are going to port the SDK to kill off a reason to get a Mac.