The iPhone SDK has been out for couple of weeks now and I've been using it to develop an application for my work as a technology demonstrator. My experience thus far has been largely positive. I wasn't surprised by how well-made the SDK is, even at this beta stage. The amount of work involved in releasing any SDK, let alone one that is so tightly scrutinized, cannot be underestimated.

Consider that I am learning three new things simultaneously: programming in Objective-C, learning how to use Xcode, and what is available in the iPhone SDK, I am going to describe the whole experience instead of just confined to the SDK.

Two weeks ago we saw the first wave of third party applications for the iPhone. But because Apple has yet to open up the device and provides an API (Application Programming Interface) for software developers, making third party applications right now is not for the faint hearted or even regular developers. A couple of weeks ago in MacBreak Weekly, Leo Laporte called for Apple to open up the iPhone immediately and he could not see any reasons preventing that happening. What Mr. Laporte, and most pundits, seems to imply is that providing an API is a straightforward process. Publish the API online and let the developers use it, right? If only it were that simple.

An API is a contract between the provider (Apple) and the consumer, who in this case is the software developers. As with any contract, once it is published, a level of trust is established between the provider and the consumer. This means the provider describes the functionality accessible by outsiders in the API, and that functionality will work as advertised. The consumer has to depend on the provider to keep their word so the consumer can develop applications base on that functionality.

But establishing an API also means restricting internal development freedom for the device. It is no longer simple to rework a particular function to provide better capability or performance without substantial testings to ensure the existing APIs are not broken. There are a few ways to deal with this situation.

First, let me start with the full disclaimer: I develop Windows .NET application by day (and by night too for ecto) and use Mac OS X at home for everything else. Before getting my Mac Pro last December I used to work on ecto using a second Windows machine, but since then I have been using Visual Studio 2005 in an XP virtual machine using Parallels.

Whether you love or hate Microsoft, you have to give them credit for popularising programming on Windows. While I was a junior programmer fresh out of college learning C++ and working on train control software, truckloads of CS/Engineering graduates were learning to program in Visual Basic. Whatever faults VB has, the way it allows even beginner or causal programmers to learn the craft and produce quick and dirty applications means that programming for Windows was no longer the eminent domain of the traditional CS/Engineering graduates, where FORTRAN and C/C++ rules. Microsoft continues this trend with C#/VB.NET and the .NET Framework, providing a lot of built-in functionality that used to require hand-crafted code or expensive third-party libraries, freeing up developers' time to concentrate on problem solving instead of mechanics.

With OS X, Apple began with Objective-C and Java as the programming languages of choice but ever since version OS X 10.3 Java had been put onto the back burner and is expected to be phased out eventually. Unfortunately, making Objective-C the sole language of the platform also makes it difficult and 'expensive' for Windows programmers, such as yours truly, to join the party. The difference in syntax (despite the 'C' in the name it does not have much resemblance to C or C++), difference in framework and API, difference in IDE philosophy, and the lack of refactoring tools (ReSharper, CodeRush, etc.) and unit testing tools (NUnit, JUnit, etc.) mean that some of the more open-minded programmers (mostly Java and .NET) will not take an active interest in Apple software development.

The upcoming Xcode 3 looks like it would make a big step in closing the gap, but the IDE still lacks the tools mentioned above to attract the time-constrained, less hard core developers from the Windows side of the world. The dark horse may be the combination of Eclipse IDE and Mono project. The Eclipse IDE is mature and has a flexible plug-in architecture so refactoring and unit testing tools can be integrated into the IDE by third party developers. Meanwhile the Mono project has been making lots of progress as far as compatibility with Microsoft's implementation is concerned. And the ability to take code written in Windows and runs it in Linux or OS X (with some limitation, of course) will appeal to Windows developers, at least as a starting point.

In fact, Eclipse/Mono may actually achieve what Sun tried to do with Java all those years ago. Remember 'Write once, run anywhere'?

Geeks and designers alike have been grumbling about the fact that Adobe hasn't released, and won't be releasing (PDF) universal binaries of the current versions of their apps, in particular Photoshop, and Adobe's answers to the cries of "Why?" have so far been pretty unsatisfactory. So what's really going on? Over at Adobe's Photoshop blog (who knew they had blogs?), engineer Scott Byers explains. Basically, porting a huge legacy app like Photoshop isn't just a recompile like Steve Jobs said, and much of the problem lies in the fact that XCode, Apple's development environment, just isn't as mature as the tools Adobe's engineers are used to. Of course, Byers makes it sound a lot more convincing than that, so you should just head over to the Photoshop blog and hear it from him.

[Via TUAW]