---

Choosing a Graphical Environment for Your Application

Mac OS X offers many options for transforming your applications with a graphical user interface from a UNIX code base to a native Mac OS X code base, or even for wrapping preexisting command-line tools or utilities with a graphical front end, making them available to users who never want to go to the command line.

This chapter describes some of the issues you will face when porting a GUI application to Mac OS X or adding a GUI wrapper around a command line application. It also describes the various GUI environments supported by Mac OS X and gives advantages and disadvantages of each.

In choosing a graphical environment to use in bringing a UNIX-based application to Mac OS X, you will need to answer the questions posed in the following sections:

• “What Kind of Application Are You Porting?”

• “How Well Does It Need to Integrate With Mac OS X?”

• “Does Your Application Require Cross-Platform Functionality?”

These questions should all be evaluated as you weigh the costs and benefits of each environment. You may already be using a cross-platform toolkit API. If you aren’t doing so, you may want to port your application to a native API such as Carbon or Cocoa.

If you are a commercial developer adding a new graphical user interface to a command-line application and want to take advantage of the greatest strengths of Mac OS X, you will probably want to use the Cocoa API. In some cases, you may want to use a different API for reasons such as cross-platform compatibility.

If you decide to use a nonnative API, like X11R6, to provide a user interface for your Mac OS X application, it is important to remember that users and developers with a UNIX background might be perfectly content to just have the application running in Mac OS X. Traditional Macintosh users, however, will pass up an application with a traditional UNIX interface for a more integrated and modern interface. Whether you target a straight port to the Darwin layer or a more robust transformation of your application to take advantage of other Mac OS X technologies (like the Cocoa frameworks) is your decision.

What Kind of Application Are You Porting?

Are you bringing a preexisting code base to Mac OS X, or are you adding new functionality—for example a graphical interface—to a command-line application? If you already have a code base written to a particular API, and that API is supported in Mac OS X, you probably want to continue using that API for any large, complex application unless you desire features of another API.

For simple applications, or for applications where you are wrapping a command-line utility with a graphical user interface, you need to evaluate what API to use. Reading the next two sections will help you recognize the benefits and drawbacks of each technology.

How Well Does It Need to Integrate With Mac OS X?

Who are you marketing your application to? If they are traditional UNIX users that just want to run, for example, a gene-sequencing application alongside Microsoft Office, then it may be sufficient to just install an X Window System on their Mac OS X computer. You would simply port your X11R6-based application to Mac OS X, leaving your code as it stands (aside from the little changes you may need to make to make it compile in Mac OS X). For more information on X11 in Mac OS X, see “X11R6.”

If you are an in-house developer of UNIX applications, this may be as far as you want to go, particularly if you want to maintain the same user experience across multiple platforms. However, you may still want to use Carbon or Cocoa APIs to improve the overall look of the UI to make it easier to use.

If you sell an application, some customers might at first be happy just to have it on their platform. However, if a competing product is released using Mac OS X native functionality, customers are likely to gravitate to that product.

A hot topic in the science and technology industries is not only bringing a code base to Mac OS X, but also giving that application a Mac OS X native user interface. This is not a decision to be made trivially for an application with a complex GUI and a large code base, but it is one that can make or break a product’s success in the market. The individual discussions of the APIs that follow should help you to make a well-informed decision.

If you’re an open source software developer, you will probably gravitate toward a basic port of the X11 application. However, you should consider creating a native GUI if your application is likely to be used by consumers such as a word processor or a web browser.

Does Your Application Require Cross-Platform Functionality?

If you have an application that must work on multiple platforms, Mac OS X has you set up for success. You have many options; some are built in and shipped with every version of the operating system; others require the installation of additional components. Figure 5-1 depicts the distinction between the cross-platform APIs that are native and those that aren’t.

You can see that Mac OS X includes some standard cross-platform APIs: Java, OpenGL, and QuickTime. There are also commercial and free implementations of some of the traditional UNIX technologies. If you are building a cross-platform application, you should evaluate which platforms you are targeting with your application and determine which API allows you to bring your UNIX-based application to Mac OS X. Table 5-1 lists the platforms on which Mac OS X cross-platform technologies run.

In the next two chapters, you’ll find brief descriptions of each of the technologies available to you for your application’s graphical user interface.

---