With its transitions from Mac OS to OS X, PowerPC to Intel, and Panther to Tiger under its belt, Apple is all about moving on. Now it’s the developers’ turn to move on. If you haven’t done it yet, it’s time to bid farewell to C and Carbon, and to embrace Objective-C and Cocoa for your GUI applications. It’s time to count on Universal Binaries, not Rosetta (Apple’s PowerPC translator for Intel Macs), to get your software out to the whole Mac market, which will soon be dominated by 64-bit Intel Macs. If you haven’t yet broken the habits of jamming new icons into the menu bar and turning every convenience utility into a CPU-sapping background process with its own always-on-top window, you should get to know Dashcode. If your application terminates because it can’t locate a critical file, learn the ways of Time Machine. And if, when you think of Web applications, your mind automatically zeroes in on Java, you might look at Ruby on Rails as a far simpler, much lighter-weight open source alternative that’s remarkably well appointed.
Leopard’s development tools will include an SDK that targets Tiger, and as far as Apple is concerned, Tiger is as far back as developers need to reach to accommodate users who don’t jump on Leopard as soon as it ships in October. Leopard carries forward the characteristics first seen in Tiger, including Intel support, the 64-bit Darwin kernel, Universal Binaries (which combine 32- and 64-bit PowerPC and Intel executables into a single file), the Automator graphical scripting environment, Core frameworks for such essentials as multimedia and databases, and the Dashboard HTML widget panel. To create native Mac applications that reach back to Panther (OS X 10.3), you’ll not only be making more work for yourself, you’ll be depriving users of the Tiger characteristics that define the thoroughly modern Macintosh.
Now you're 64
One of the clearest lines of demarcation separating Leopard from Tiger is 64-bit. Tiger has some 64-bit capabilities, but just enough to satisfy Apple’s old message that 64-bit is all about accessing more than 4GB of RAM. Having a product line tilted heavily toward 32-bit systems, Apple characterized the need for 64-bitness as rare and advised developers to apply it sparingly. For Leopard, Apple’s message has shifted dramatically: Leopard is 64-bit from stem to stern, from kernel to presentation, and developers have the green light to leverage 64-bit platform features. At the 2007 Worldwide Developers Conference, Steve Jobs pointed out that “practically all Macs are 64-bit” (only the Mac Mini remains 32-bit) and presented a demo showing that demanding applications run markedly faster as 64-bit software. The performance advantage is not just about memory: 64-bit gives applications access to double-wide (128 bit) CPU registers and a much larger total register set for speeding complex calculations and reducing the number of trips that a 64-bit optimized application must make to slower RAM.
All of that sounds inviting, but how does one get an application from the 32-bit world to 64? The same way you get from PowerPC to Intel: Let Xcode, OS X, and Apple worry about it. Apple’s Universal Binary executable format folds multiple native architecture types into a single application file with one installer. You can develop and debug your app once on a 64-bit Mac Pro, and then spin out your app to target 32-bit PowerPC, 64-bit PowerPC, 32-bit Intel, and 64-bit Intel in a single executable. Or start with any one of the other architectures and target the other three. You ship your application with one installer, confident that it will work exactly the same way on every Mac that runs Leopard. The OS X loader automatically picks the correct architecture out of the executable at runtime, and the frameworks optimize your application for the user’s system by default.
There’s another reason that Apple wants 64-bit all the way down the line: Apart from speed, Apple wants OS X to be taken seriously as a commercial Unix, right down to equipping Darwin to qualify for the Unix trademark. Apple hopes to raise Darwin to the stature of Solaris, AIX, and HP/UX. If Apple comes up short in its bid for Unix certification for Leopard, it has an ally in Sun Microsystems, which has open-sourced most of its Solaris System V Unix and which makes widespread use of Mac client systems internally. In other words, while Unix certification for Leopard is not a done deal, Apple has a ready base of thoroughly certified code from which to borrow. Leopard will be Unix. Your software should wear that label with pride.
Apple is using the advent of Leopard’s 64-bit pervasiveness to prepare the way for the gradual de-emphasis of the Carbon C API. For example, Apple is not porting the QuickTime, QuickDraw, and Sound Manager C APIs to 64-bit. Instead, it is supplanting them with the 64-bit Objective-C framework's QuickTime Kit, Cocoa, and Core Audio. It’s reasonable to assume that the OS and API facilities Apple chooses not to bring forward to 64-bit are heading for deprecation.
The way I see it, Dashboard offers lessons to developers of native Mac applications as well. Users can audition widgets before committing to their installation. The install process is a one-click affair, and it’s just as easy to uninstall a widget as it is to install it. I can’t say whether Leopard incorporates a mechanism for removing installed applications, but because that’s one of few remaining pain points for Mac users, figure uninstallers into your application design whether Apple helps you with it or not.
Standard behavior for any application, Mac or otherwise, is to saddle the user with using Save As or file/folder copying for versioning of documents and projects. While Cocoa has built-in facilities for unlimited levels of undo in text editors, there is no equivalent for this on a file level. And while a Revert option belongs in every application’s File menu, it’s seldom seen because the only practical way to implement it is to create a backup copy of a file every time it’s saved.
When your application can’t locate a file where it expects to find it, or when a file turns up corrupted, instead of bailing out you should tap the capabilities of Time Machine. Time Machine maintains deltas of file modifications by taking non-destructive snapshots of the entire file system at regular intervals. Time Machine is not enabled by default because it requires the one-time selection of an external volume or Time Machine server for the storage of file deltas. It’s a facility that applications written for professional and commercial use should urge users to activate, and when it’s found to be present, applications should assist the user in locating a valid version of a missing or corrupted file. The fact that Time Machine is more efficient and reliable than either Save As or versioning via duplication is a sound justification for recommending Leopard for applications with large or critical documents and datasets.
Ruby on Rails
Apple remains strongly committed to Java. A 64-bit optimized Java Virtual Machine based on Java Standard Edition 6 is incorporated into Leopard. Apple’s current published documents indicate that Java SE 6 will be present in Leopard as a preview. However, that documentation may have presumed a June release date, rather than October.
OS X Server, and OS X clients that are equipped for server duty, bundle the Apache Web server and various means to implement and deploy Web applications. Tiger includes Red Hat’s JBoss Java 2 Enterprise Edition server, and Apple’s close working relationship with Sun is likely to enhance its Java offerings. Apple’s own Java app server, WebObjects, which is used for Apple’s online operations including the iTunes Store, is a powerful option. But all of these require a substantial investment in skills that might not be justified for all Web applications.
Apple has endowed the Ruby scripting language, and by association the Ruby on Rails Web application framework, with two-way connectivity to Objective-C native code and the Cocoa and other object-oriented frameworks available to Objective-C applications. While other languages lay claim to being easy to learn, Ruby rivals BASIC’s ease with regard to the swift movement from zero knowledge to productive code. Ruby has a large community behind it that has generated a massive repository of RubyGems[dd1] classes covering practically every imaginable purpose.
Ruby on Rails is a server foundation that makes the creation of basic dynamic Web sites and applications almost effortless. It scales to handle more complex server-side requirements while retaining its simplicity and the readability of code. Apple bundles Mongrel, an extremely lightweight HTTP framework for Ruby. Mongrel does not rely on Apache for communication with HTTP clients, so Mongrel integrates easily with any HTTP server. Mongrel has the ability to operate as a standalone Web server, which takes a Ruby on Rails application straight to the Web.
Apple has endowed the Ruby scripting language, and by association the Ruby on Rails Web application framework, with two-way connectivity to Objective-C native code and the Cocoa and other object-oriented frameworks available to Objective-C applications. While other languages lay claim to being easy to learn, Ruby rivals BASIC’s ease with regard to the swift movement from zero knowledge to productive code. Ruby has a large community behind it that has generated a massive repository of RubyGems classes covering practically every imaginable purpose.
Ruby on Rails is a server foundation that makes the creation of basic dynamic Web sites and applications almost effortless. It scales to handle more complex server-side requirements while retaining its simplicity and the readability of code. Apple bundles Mongrel, an extremely lightweight HTTP framework for Ruby. Mongrel does not rely on Apache for communication with HTTP clients, so Mongrel integrates easily with any HTTP server. Mongrel has the ability to operate as a stand-alone Web server, which takes a Ruby on Rails application straight to the Web.
Throughout the four parts of this series, I’ve done my best to highlight the new and updated technologies that Leopard places in developers’ hands. There is no question that Mac developers should count on using Leopard for application development; the Xcode 3.0 toolset and its satellite components such as Xray elevate developer skills, productivity, and code quality.
Commercial software, custom solutions, and applications of scale that will run exclusively on Mac Pro workstations or Xserve servers are candidates for direct targeting of Leopard. For workstations, Leopard’s 64-bit presentation layers and optimized frameworks will have a huge impact on performance and capacity. OS X Leopard Server, to which I’ll devote separate coverage, marks a fresh start for Apple’s enterprise programs. Unix workstation and server solutions routinely cite the latest OS release as a system requirement. Keeping up with users’ expectations requires plying all of the advantages that the latest revision of the platform brings to the table. For workstation and server apps, “most recent release” is expected in RISC Unix, and it can safely be established as a standard on the Mac platform starting with Leopard.
The rule of thumb for all other Mac applications will be to hold off on building in dependencies on features unique to Leopard until it has reached critical mass. However, it is important that Mac developers avoid inventing features in their own style that overlap with facilities inherent in Leopard. This trap will result in applications that not only seem dated in Leopard, but will be viewed by users as incompatible with the platform. Even if you’re not targeting Leopard directly, it’s important that your designs and road maps take Leopard into account.