Apples Intel Move Still Riling Mac Developers (
Page 1 of 2 )
Some smaller Apple vendors are having an easy time adding support for the Intel-based Macs. But others with larger projects are unhappy with the state of Apple's coding tools and a new, steeper learning curve.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.
How well do you know the history of Apple and the Mac? Take this quiz to find out.
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.
Next Page: Granular issues.
