An Engineer

We recently released the Mac version of Phanfare Photo. The issue of Mac versus PC for the end user is hotly and endlessly debated but you don’t see that much about the pros and cons of the platforms from a development standpoint. I developed the Mac version of Phanfare photo, and worked extensively on the PC version. It is not often that one gets to build a large application for both the Mac and PC, written to the exact same network API, both written with native tools. I am going to go over our experiences in developing the Mac versus the PC version, and I encourage you to try both so you can see the final result. Some of these thoughts came from other team members. I brought it all together.

First some high level stuff. Both programs do the same thing. They allow the user to upload, organize and share photos and video on the web by communicating with our online web service. Our online web service runs on Windows Server 2003. The Mac version was written in Objective C using Xcode (Obj-C for those who love it). The PC version was written using C# and Visual Studio 2003. The first question you might be wondering is why did we choose these technologies?

We wrote the PC client version first, and it seemed most natural to write it in C# in .NET. Everything we could find pointed to Microsoft being committed to .NET for client application development. We knew we wanted a full featured “fat” client because we wanted to give the user an immersive interactive experience based on a multithreaded architecture. One might argue that these things are possible using AJAX on the web, but we thought that a Winforms .NET app would be far easier to write and maintain. The choice of using windows for the back end web service came naturally because the integration between Windows .NET applications and Windows web services is no less than brilliant. We had a lot of Unix guys on the team, but even they agreed that web service was most naturally written using Windows if the first client was the C# .NET Winforms version. Windows does a nice job letting you read in the WSDL description of a web service and then letting you code against it as if it is local in Visual Studio.

We knew that someday we would be doing a Mac client so deliberately used only the most basic data types on the service side. We used arrays, strings, longs, ints and floats and structs. We avoided some of the proprietary types offered by Microsoft because we thought that whatever tool we used to translate WSDL for the Mac implementation would probably choke on those types.

When it came time to build the Mac version, we considered Java. To my dismay, doing Java on the Mac means going with the proprietary Apple bindings (killing hopes of having an easy port to Linux) and according to Apple Cocoa-Java has been has been killed with Tiger. So it looked like Objective-C, a 20 year old competitor to C++ used primarily by Apple, would be our best choice. Plus we were no fans of Java for reasons we won’t go into here.

The Mac version is not entirely finished yet, and is missing key features that the PC version already has. Roughly eliminating the PC code that has no Mac counterpart yet and any open source, the Mac client is 44,973 lines and the PC version is 55,736 lines. We wrote the Mac version second and had the advantage of a more stable API against which to code.

Before we begin here are some high level observations about the finished product. The Mac version starts a lot more quickly than the PC version. Chalk that up to native code versus the .NET CLR interpreting the IL. The PC version is as fast as the Mac version once it gets running. The Mac version looks nicer than the PC version and has some visual eye candy that the PC version lacks. This is partly because I care more about UI design than the guys who wrote the PC version, but it also is because the Mac has so little support for any decent UI widgets that you pretty much wind up rolling your own for everything. And if you are going to roll you own, you might as well make them better than the generics.

In the next installment, I will be writing about development environments and IDEs.