According to Hoyle...
Cross-Platform Software Development from a Macintosh Perspective
September 2005
"We'd love to do a Macintosh version of this product, but we can't justify the cost. By the way, we need you to finish that Windows version right away."
Sound familiar? Most Macintosh software developers will hear these words at some time or another during their career...usually far too often. So here's the dilemma: the costs for producing a software package on the Macintosh is nearly the same as producing one for Windows. However, whereas Windows commands a 90+% marketshare, the Macintosh is only in single digits. Even if a Mac developer could somehow double, triple or even quadruple his productivity level, the ratio of expected sales per development dollar will always remain significantly lower on the Macintosh than on Windows. Corporate bean-counters want the biggest bang for their buck, and they need a compelling argument to justify that bang. What's a software engineer to do?
MacHack 2005
I attempted to answer this at this past summer's MacHack 20 conference in Ann Arbor. The paper and slide presentation I gave became the basis for this upcoming series of articles in MacCompanion. For this reason, I want to thank Robert Pritchett for the opportunity of being MacCompanion's Software Engineering Columnist.
As an aside, the 2005 conference became the final MacHack. Even with the new name "ADHOC" (Advanced Developers Hands On Conference), its time had come to an end. I was glad to be a part of its final iteration. Perhaps in a future column, I will dedicate an article to the history of MacHack. In the meantime, I heartily recommend Doug Houseman's book Late Night with MacHack.
Modern Cross-Platform Frameworks
One practical solution is the use of a cross-platform framework. For almost the same engineering costs, a single code-base can then be used to create both Macintosh and Windows applications. In recent years, a large number of platform independent approaches have become available for the Macintosh developer to use:
There are full-featured application frameworks, such as Qt, wxWidgets and CPLAT.
There are entire cross-platform development environments, including Java and REALbasic.
Unfortunately, there are many "solutions" with varying support for the Macintosh, and many give you a "lowest common denominator" look and feel.
Over these next series of articles, we will examine various cross-platform approaches from a Macintosh perspective. We look particularly at the ability of a given approach to give the Mac OS X user the appropriate user experience, while still being able to cross-compile for Windows.
Cross-platform frameworks have been in existence for a number of years. But before proceeding to examine the modern frameworks available today, let's look at a selection of some of the more popular frameworks of the past. Seeing how and why some of these past attempts have failed may be helpful in choosing a modern framework.
Legacy Cross-Platform Strategies
Visual C++ Macintosh Cross-Compiler
One of the earliest entries into cross-platform development was, surprisingly, from Microsoft with their Visual C++ Macintosh Cross-Compiler. This product was an add-on to their standard Visual C++ compiler, allowing you to take applications written for MFC (Microsoft Foundation Classes) and cross-compile them for the Macintosh. Unfortunately, there were a number of drawbacks to this approach, not the least of which was that it was Windows NT-hosted. This means that a Windows PC was needed to create Macintosh applications. As you might suspect, this was not a very popular aspect for Mac developers. Secondly, it was outrageously expensive, retailing at $1,999 for the add-on alone (which does not include the $495 Visual C++ compiler itself). Finally, it created notoriously slow and clunky applications. The most well-known example was Microsoft Word 6.0, which many Mac users remember. In retrospect, it is not surprising that Microsoft would offer a development tool that was slow, expensive and Windows-only. As you might expect, the Macintosh development community never took this product very seriously, and the product was cancelled after only a couple of years. In 1996, Microsoft slashed the price to $199 to clear out remaining inventory, and Microsoft has not offered a Mac development tool since.
Mac2Win
Essentially, Altura's Mac2Win is a port of the original Mac OS API to Windows. By adding the Mac2Win libraries with your project, your application can be compiled and run on Windows. The appeal of this for the Macintosh developer was that he could develop his project in the standard Mac Toolbox and compile for Windows without a large rewrite. Unfortunately, only about 80% of the System 7 Toolbox was ported. And of the functions that were supported, many behaved differently on Windows than on the Mac, requiring extensive debugging. Mac2Win was an expensive, royalty-based product, well outside the price range of the small developer. However, many well-known Macintosh applications got their initial Windows ports via Mac2Win, including Claris Works, Macromedia Director, 4th Dimension and Metrowerks CodeWarrior. By the way, there is an interesting way to discover if a given Windows was built using Mac2Win: By hitting ALT-U-R-A (for the company name Altura), the Mac2Win libraries display Altura's secret About Box.
PowerPlant for Windows
Metrowerks, the company that made CodeWarrior, the dominant Macintosh development environment for over a decade, already came free with an object-oriented Mac-only framework called PowerPlant. In 2001, Metrowerks announced a Windows version of PowerPlant; unfortunately, it too was crippled by corporate greed. Instead of releasing it free, Metrowerks decided to charge for this Windows version. Metrowerks chose a price point that priced themselves out of the market. At first launch, PowerPlant for Windows cost anywhere from $20,000 to $50,000. By early 2003, Metrowerks dropped the price to $15,000 plus 1% of the total product sales above $1.5 million, capping at a maximum of $150,000. Clearly not for the faint of heart. This price structure strangled any hope of survival for this product. Although some large companies (like Adobe) were able to afford it, the development community at large was simply not interested in such outrageously priced offerings. Due to lack of sales, PowerPlant for Windows was withdrawn from the market in early 2004.
Yellow Box for Windows
One other cross-platform initiative that should be mentioned was introduced by Apple Computer itself. At the 1997 Worldwide Developer's Conference, Apple announced a plan for a new operating system called Rhapsody. To run natively in Rhapsody, Mac applications would have to be re-written in to Yellow Box API, an updated version of NeXT's Open Step API. In exchange for this rewriting, Yellow Box applications can be easily recompiled for both Windows and Macintosh. Unlike Visual C++, Mac2Win or PowerPlant, creating YellowBox applications was free with no royalties. Unfortunately, there was a cost at the other end: the user, not the developer. Each Windows user would have to pay $249 for the Yellow Box libraries needed to run such applications (Mac users received it as part of Rhapsody). For the shareware writer, it was unreasonable to assume that a Windows user would pay such a sum just to run his application. The following year, the flawed Rhapsody plan was replaced by Mac OS X and Yellow Box was redeployed as the Mac OS X-only Cocoa API.
Where We Are Today
The flawed attempts of the past appear have one trait in common; they were expensive ... some were extremely expensive. Today, with the availability of free and low cost development tools for most programming languages on virtually any platform, these old approaches are almost laughable from a modern viewpoint. For the C++ user, CPLAT costs a mere $50 flat with no royalties. Many other frameworks (e.g. wxWidgets) are fully open source and free. Even the expensive Qt offers an open source license option. Java developers can download Eclipse at no charge, and Basic programmers can purchase REALbasic for as little as $49 per platform. The world is truly your oyster if you are a cross-platform programmer in 2005.
In exchange for this large quantity of solutions, there is a catch; not all of these solutions produce quality results. SourceForge.net, the place where open source projects go to die, is filled with partially supported and incomplete cross-platform frameworks. Which of these will remain viable when Apple switches to Intel next year? If there is a bug in the framework, how timely can I expect a fix? Will I be able to create applications which look like native Mac OS X apps and native Windows apps? Tune in next time as we explore the answers to these exciting questions!
Coming Up Next: Qt
http://www.adhocconference.com/cgi-bin/blosxom.cgi/Speakers/#Hoyle