Is developer support important?
The first part to this argument is that the overall success and long-term viability of a
platform lies with it's potential developers. There are numerous examples to demonstrate
this, but the basic idea is that the easier it is to develop for a platform, the more
software will be developed and the more successful the platform will become.
First, consider the largest share-holder of the market, Microsoft. Some may say that their
dominance is due to unfair business practices and shady ethics. While that is outside
the scope of this article, I would say that much of Windows success has been the wide
variety of software available for it. Most desktop applications today are written for
Windows and ported to other platforms. Why? Windows has the some of the best development
tools on the market. Anyone who has ever done a serious project using Visual Studio
knows what I'm talking about. It is integrated incredibly well with their help system
(which is far superior to anything else out there) and tools like MFC and Visual Basic
allow a developer (or non-developer) to pump out an application very quickly (Whether or
not you are a fan of the IDE-style of development, it should be fairly obvious that an
IDE makes entry into the market as a developer much easier, especially when you are
building a GUI using a complicated framework). Even at the API level, things like DirectX
are far more advanced than their competitors on Windows or other platforms. This makes
developers happy, because they have good tools that save time and great support. Thus,
the platform flourishes.
Now, let's consider Linux's success in the server market. Linux is a success because
it is based on UNIX, which is a well-known, widely used set of APIs and way of
developing which has been around for years. Thousands of UNIX developers world-wide
can log into a Linux box and be ready to go. Here, Linux has embraced a standard that
resulted in attracting developers. Those developers built rock-solid applications
that made Linux a viable platform. Linux's cost locked it in to make it a success. If Linux
had been free, but not been based on UNIX, it would not be very successful.
Compare this to Linux's (lack of) success in the business desktop market. There are
numerous GUI APIs, none with an advanced development environment, and certainly nowhere
near the amout of reference or online help and support that Windows has. This makes it
harder for a developer to learn what he needs, and more difficult to write desktop software
for Linux. Thus, Linux has a lack of decent desktop applications, and is not currently a
viable business desktop.
to attract existing web developers to the IE platform as well as industry-wide speculation
that the XBox will crush its competition because it can capitalize on the huge PC gaming
industry, since XBox will support DirectX. Also consider the success of Java: javadoc
alone is a huge factor (allowing anyone to create very readable documentation of their
code and APIs), and Sun's support for it's developers is huge.
The point is that a big part of a platforms success is in it's developer support. If a
platform makes it easy for developers to write software for that platform, much software
will be written and the platform will succeed. If it makes it difficult, it will be
harder for developers to write software for the platform, and less software will be
available for it, and it will not succeed.
So, how does OS X fit in?
Using OS X, I was amazed. It's the Linux desktop I never had. Everything just works, and
I can run real business applications (such as IE and Office) while using tcsh and UNIX
for doing server-side Java work in Tomcat. It seemed to me to be the best of both worlds. When I started reading about
the system architecture and the features it offered developers, I continued to be
amazed at the potential of this platform. Then, I tried to write an application for it.
Writing an application for Mac OS X using "Cocoa" (which gives you the full range of Aqua
GUI elements and is the native API for OS X) involves using mainly two tools: Interface
Builder, which lays out GUI elements on a window, and Project Builder, which is a
Visual C++ style IDE for writing your code. The code can be written in either Objective-C
or Java (but writing it in Java involves use of the "Java bridge", where calls to
the Cocoa API in Java are translated into Objective-C calls and executed).
Let me first say that Interface Builder (IB) is a pretty good tool.
It is clearly superior in some
ways to the equivalent tool in Visual C++ for laying out a GUI. IB makes it very easy to
conform with the "Aqua interface guidelines" and will go a long way towards preventing
ugly interfaces. That said, there is little to no documentation on how to use it, and
connecting your GUI to your code is very non-intuitive. For example, in Visual C++,
double-clicking on an object brings up a dialog allowing you to specify the code
called during events relevant to that object. Not so in IB, double-clicking allows
you to change the label. Connecting the button to code is a two step process
that involves dragging lines from one window to the button and vice-versa. In fact,
this metaphor is used frequently, and not always to the same effect. This makes IB very
confusing and counter-intuitive to me, and certainly to the army of developers out there,
it makes it tough to use.
Project Builder (PB), the IDE, is where things really start to fall apart. PB has typical
features of an IDE: A tree view of project files, integrated build and debug, and a
semi-decent code editor with syntax coloring. The real problem is that there's no
integrated help system. In visual C++ you can cursor over an object, hit F1, and
see documentation about the keyword in question. Even before that, however, when
writing your code, you can tell Visual C++ to pop up a list of method names for the
object you are using and it will even show you the parameter list. All from within
the tool without having to go to the documentation. Not so in PB. Integrated help
is one of the main points of an IDE. You might think that
this is excusable because OS X is so new, but IB is from the old NeXT days and has been
in constant use and support through the years, because it is the development tool
for Apple's web application server, WebObjects. I would think a tool that has been around
for so long would have more advanced features or at least be close to the competition.
Next, is Apple's online documentation. Searching the documentation is almost pointless,
as it seems to use a typical web search that returns numerous unrelated documents.
Browsing the reference is equally difficult. When you look at the docs for a particular
class, you are not given an alphabetical list of methods and public interface elements,
but you are given a list of methods grouped by "purpose", and even then the list is not
complete (there are documented methods for a class that don't show up in
any of the groupings or any other method list).
So, finding the parameters for a method you need to call is very cumbersome
and difficult. The documentation has been this way for at least 3 years (it's format
and usefulness doesn't seem to have changed since I started using WebObjects). The
documentation seems difficult to use for beginners and experts.
Finally, we come to Objective-C. I don't think there's anything inherently wrong with
Objective-C, but it is fairly obscure (try searching Amazon for Objective-C books). Given the
lack of reference materials and the fact that it's syntax is a large departure from two of
the more popular desktop application languages today (Java and C++), this also can be a
problem for developers
new to the platform.
I'll finish this off with a brief anecdote of writing an application. I wanted to have
one main window and a preferences window that pops up when you choosed "Preferences..."
from the drop-down menu. I could not figure out how to open a new window by reading
the docs, so I looked at some sample code. Fortunatly, they had the code to TextEdit
available, and it has a preferences window that operates similarly to the one I wanted.
I traced the paths of execution through IB and PB and found the API call that (apparently)
causes the preferences window to appear. The code wasn't documented, and the call
didn't seem to be something that would open a window. So, I tried to find the documentation
for that call. I couldn't find it anywhere. So, their example code is using an
undocumented API call with no inline code documentation explaining why! And keep in mind
this was example code of what I consider to be a basic task; opening a window. So, already
in my first project to do something very basic I have to use an undocumented API
I've shown that a platform's ultimate success lies with it's ability to attract and retain
developers. The best way to do that is to support standards or to provide top-notch
development tools, backed with highly available documentation and support. I've shown
several examples of this. I've also described the current state of OS X's development
tools and documentation, which is to say many years behind the competition, despite the
age of many of the tools and APIs.
So, what can Apple do? In short, Apple needs to:
- Provide an integrated help system with Project Builder; something searchable
with reference, knowledge base and tutorials all in one. Think MSDN Library
for OS X.
- Vastly improve their developer documentation. Looking at what Apple
has compared to Javadoc I generated for code I wrote makes Apple's documentation
look just plain embarassing.
I think OS X has incredible potential. I think the features of OS X could crush Windows
as a desktop OS and the rock-solid BSD core could compete with Linux and Windows in the
server market. But right now, as a development environment, OS X is really lagging behind