On the eve of its 30th anniversary, Apple Computer is in the middle of a major transition—moving its Mac hardware and operating system over to the Intel chip. But Apple isnt alone: this transition affects every developer of Mac software, including Apple itself.
As Apple moves from IBMs and Freescales PowerPC RISC architecture to Intel processors, developers must rebuild their products to support both platforms, into what Apple calls a UB (Universal Binary). And while Apple lists over 1,000 UB applications currently available, this process is challenging developers, especially those of some of the largest and most critical applications for the platform.
Apple first revealed its plan to switch processor architectures at its June 2005 Worldwide Developers Conference in San Jose, Calif. At the time, Apple CEO Steve Jobs noted that some developers would have a relatively easy time of it—those who completely built their applications in Cocoa, the Mac OS X-native set of APIs that is closely related to the OpenStep operating system from which Mac OS X was created. These developers, using Apples own Xcode development tool, should be able to produce Intel-native versions of their applications with only “small tweaks” and a recompile, Jobs said.
In addition, developers who work in Java should find the transition an easy one, Jobs said. This seems to be the case with Zimbra, a maker of open-source server and client products for enterprise messaging and collaboration based in San Mateo, Calif.
“Because we went the Java route, porting has not been much of an issue,” said John Robb, the companys vice president of product management. He noted that Zimbra had an advantage in the porting race due to the “relatively OS neutral” design of the companys products.
There were a few issues, he said, but they were resolved within two days.
Robb said the company has tested its server-side software on PowerPC- and Intel-based Macs. “Were very happy with our initial testing,” he said. He added that Zimbras tests showed up to a fivefold performance increase on both client and server.
Other developers may use Xcode but rely on Carbon, another set of Mac OS X APIs derived from previous versions of the operating system. These developers, Jobs said at the time, would face more challenges.
Facing even greater challenges, Jobs said, would be companies that used other development tools, such as Metrowerks CodeWarrior. Developers using CodeWarrior would, Jobs said, first need to migrate their application code to Xcode.
One example of such a developer is Adobe Systems and its recent acquisition, Macromedia. In fact, Adobe CEO Bruce Chizen recently stated that Creative Suite CS3, the next version of the companys industry-standard graphics suite, will not be available before April 2007, pushing the limits of Adobes 18- to 24-month development cycle. Although an Adobe spokesperson declined to comment, directing all questions to a PDF policy statement posted on the companys Web site, Adobe engineer Scott Byer posted a blog entry expounding on the issue.
Byer explained that Adobe Photoshop in particular was tied to CodeWarrior, in part because of the way Adobe had to update the application during Apples last processor migration. That was in 1994, when Macs moved from the 68000 family from then-Motorola to the first PowerPC chips.
He said Apples Xcode environment wasnt up to the task of handling a large and complex project such as Photoshop.
“From having projects with large numbers of files that open quickly, to having compact debugging information, to having stable project formats that are text-merge-able in a source control system,” Byers wrote, “[t]hese are things Xcode is playing catch-up on.”
Although “Apple is doing an amazing job at catching up rapidly,” he added, “the truth is we dont yet have a shipping Xcode in hand that handles a large application well.”
In addition, Byer said that switching development environments “always involves more work than you would think in a codebase of this size.”
Similarly, Rick Schaut posted an entry on an MSDN blog about the Universal Binary transition. He noted that the work of porting from one development environment grows exponentially, not linearly, in relation to the size of the code base—and Microsoft Office runs multiple millions of lines of code.
Schaut also said that Microsoft had good reason to remain on CodeWarrior rather than move to Xcode in the period between Xcodes birth and the announcement of Intel-based Macs (which, sources said, came as a surprise to even Adobe and Microsoft). CodeWarrior provided a faster and cleaner compiler, he said. In any case, he said, moving from one development tool set to another requires a huge investment in manpower whenever it is done, and the company decided to spend the resources on developing features and fixing bugs—until Apples move to Intel forced the change.
In addition to an applications size and its development environment, other factors can also present a challenge when trying to create a UB version. Steve Gully, president of Atimi Software, described a few of them. His Vancouver, British Columbia, company contracts cross-platform development.
“If a product was built in Cocoa on Xcode, its relatively trivial” to make a UB version, he said. “A lot of the work comes in moving the application from CodeWarrior or PowerPlant to Xcode.”
Even if that is the case, he said, a developer may not choose just to generate a UB version and ship it out the door.
“In general, a pure UB port is rare,” Gully said. He noted that many of his companys clients see the move as an opportunity to fix bugs and add features. “With many of these applications, some of the code hasnt been touched in years,” Gully said, “so the transition to UB can act as a catalyst.”
Other potential challenges arise, Gully said, from the architectural differences between PowerPC and Intel processors.
For example, Gully said, the PowerPC chips in Macs have AltiVec (also called Velocity Engine). This consists of an instruction set and registers on the PowerPC G4 and G5 chips; though Intel has a similar SSE instruction set, the two are not directly compatible.
“The AltiVec code will port, and Apple has done a really good job,” Gully said, “but there may be speed improvements possible.”
He gave the example of a CAD application, where a screen redraw may refresh in a second and a half without the developer taking the time to optimize the code, versus a refresh in a second with optimizing. “For the applications where speed is a big deal, we do optimize,” Gully said.
“The solutions that Apple has provided do help,” he said, “but optimizing takes more time.”
A bigger challenge, Gully said, is when the original developers use assembly code. This is used for applications that demand every speed benefit, such as games or professional graphics applications, such as Photoshop plug-ins. This code needs to be either abstracted and then ported, or translated directly.
“This is exactly the kind of programming that just plain hurts peoples brains,” said Brent Simmons, creator of Ranchero Softwares NetNewsWire.
Simmons noted that such problems include endian issues—accounting for the reverse way Intel and PowerPC chips store certain data—which are manifold.
“Take something like Microsoft Entourage, which stores e-mail in a database,” he said. “If the database code doesnt take into account [endian issues], that could cause database corruption as bits are written to the wrong place.”
Adobes Photoshop could also have these issues, Simmons said. The application stores images as big sets of numbers, and then applies operations to those numbers. “The Photoshop folks have to go through and make sure theyve accounted for [endian issues] in every single place,” he said.
“Thats a big job,” Simmons said.
And this is the job facing all Mac developers as Apple moves toward an all-Intel product lineup. According to Gully, its not work that Mac developers are scoffing.
“We are doing UB porting work for multiple clients.” he said, “and work is picking up.”