A new processor architecture has massively boosted Mac power and capabilities, but what does it mean for developers? Stephen Withers investigates how to port your Mac apps.
Switching to a different CPU can be a painful process, but Apple has been through it before when it dropped Motorola's 680x0 family in favour of the PowerPC. From the user's perspective, that change was simplified thanks to the operating system's provision of an emulator for 680x0 code and a scheme for parcelling 680x0 and PowerPC code into a single application ('fat binaries').
This time around, the names have changed but the ideas stay the same: The Rosetta emulator provides a way of running PowerPC code on an Intel-based Mac, while 'universal binaries' package PowerPC and x86 code within one application.
Apple's Xcode development system ships with Mac OS X, and the latest version with support for universal binaries is available for free download from the company's Web site along with information to assist with the migration process. Importantly, Xcode can generate code for PowerPC, x86 or both. The best-case scenario is that a developer ticks the box for x86 code, rebuilds the project and gets a universal binary with no further effort.
For some developers, the process was as straightforward as Apple promised. Marc Edwards, one half of widget developer iSlayer, says that because Dashboard is itself a universal binary, widgets that use plug-ins have to be recompiled, but "all you need to do is recompile and check the 'compiler for Intel' box."
"Unless you have inline assembler code, it's quite an easy job," because there's no reason to have written the code using anything other than Cocoa, and Everything else happens automatically at runtime through WebKit, explains Edwards.
iSlayer had to rebuild ten of its 12 widgets, but the job was done in one night: "it was pretty painless."
iSlayer has also released iStat, a self-contained universal binary application built on the same code base as its series of system-monitoring widgets.
Similarly, applications created using FileMaker generally work unchanged as FileMaker itself runs under Rosetta. Ray Cologon, lead developer at NightWing Enterprises and winner of the 2005 FileMaker Excellence Award for Leadership and Technical Excellence in FileMaker Pro says "Our testing at this stage indicates that [our] applications will run without modification in Rosetta. They will run non-optimally in that environment, but will nevertheless be fully functional."
"Our information at this stage suggests that whilst there are no specific techniques which are not supported in the new hardware environment, any non-optimal or inefficient coding practices will suffer more dramatic performance hits running in the Rosetta emulation mode," he adds, but notes that performance "is adequate for moderate requirements with stand-alone applications." Cologon points out that FileMaker Server does not run under Rosetta, so server-based applications won't run on the new Macs.
"We believe that market demand for a universal binary version of FileMaker will increase as other configurations of Intel Macs become available, especially the power user workstations. By that time we anticipate that FileMaker will have responded with a public release of [a] universal binary client application."
"Even though some of our components interface with the operating system at a low level, we already supported Mac OS X 10.4 so only needed minor modifications to make them work on Intel. We did have to ensure that data was endian proof in environments where our software on Intel Macs and PowerPC Macs communicated with each other." Sutherland is referring to the way x86 and PowerPC CPUs store multi-byte values in opposite order.
Problems arose when the team tried to convert the Project Builder projects into Xcode, so it spent two months recreating then from scratch. Changes to the code itself only took half that time, though several person-months of testing was carried out to ensure correct operation in mixed networks -- Sophos' cross-platform product suite can be managed from a single console.
"We were fortunate to get hold of three of the Developer Kits from Apple early on -- this included three Intel machines which were essential in allowing us to complete the development work and perform all the testing required in good time for the anticipated release date of Intel Macs by Apple," says Sutherland.
For developers using development systems other than Apple's, the move to Intel "is a bit of a shake up," says Edwards. While changing frameworks and development systems is a pain, "it brings everyone up to speed with the latest efforts."
One developer in that position is Peter N Lewis of Stairways Software, the creator of the legendary Interarchy FTP client (formerly Anarchie). "Since Interarchy is written in Pascal, we faced a fair number more wrinkles than most developers," he says.
Stairways has been working with other developers for a year or so to create Mac versions of GNU Pascal and Free Pascal, plus Pascal versions of Apple's interface files.
"That work is fully functional now, and Interarchy 8... has been ported from Metrowerks Pascal to GNU Pascal, says Lewis. "GNU Pascal uses the same back end as GNU C, so GNU Pascal has no trouble running on either PPC or X86 and compiling to either PowerPC or x86."
As for getting Interarchy itself working on Intel, he says the main issue was byte ordering: "There were about half a dozen pieces of code in Interarchy that needed to deal with byte orders, such as processing SFTP packets and processing network packets while sniffing network traffic."
"Typically, you need to deal with byte order only when accessing files or network, so encapsulate code that reads or writes to files or the network, or alternatively use a text file format or network protocol to avoid the issue entirely," suggests Lewis.
Interarchy 8 is in beta testing, and should ship as a universal binary around late March or early April.
Hughes is one of the developers and maintainers of AGTK (Annotation Graph Toolkit), a suite of software components for building tools for annotating linguistic signals -- time-series data including audio and video that documents any kind of linguistic behaviour. It consists of about 40,000 lines of C/C++ source code plus more in Java, Tcl/Tk and Python.
When Hughes ported the core library and applications to Mac OS X in 2004, he initially stayed with the Eclipse IDE and gcc compiler. "At the 2005 Worldwide Developers Conference, I was able to port AGTK to Xcode between the Xcode Lab and the Universal Binary Lab. From there I could build cross-architecture binaries," he says. "In around 100,000 lines of code, there were literally three changes required to allow compilation." The task would be harder for code using Altivec instructions, as there is a mismatch between Altivec and Intel's SSE.
"If you already have gcc toolchain based code that is outside of Xcode, then experimenting with cross-compilation as a precursor to migration is probably a good idea," he advises other developers. "Fundamentally, Xcode's option to build universal binaries is based on the gcc cross-compiler options (-arch etc), so you can get a feel for any issues simply by using the cross-compiler even outside an OS X environment."
Some developers of larger applications face similar problems, but on a larger scale. Like Stairways, they are generally looking to release the next version as a universal binary rather than pushing out an update of the current code.
MYOB is in the process of porting AccountEdge from CodeWarrior to Xcode. According to company spokesperson Greg Smith, this is a challenging project for three reasons: the sheer size of the program ("many millions of lines of C and C++ code"), its complexity and the need to separate the business logic from the user interface code, and the use of in-house cross-platform libraries for user interface elements ("some can be simply recompiled, others need to be rewritten from scratch in Xcode").
"File and network I/O are proving more challenging than other aspects of the transition. There are also some issues with low level routines using points and rects which may mean we need to re-write elements of our libraries from scratch versus simply re-engineering and cross-compiling code. At this stage we're still discovering what comes across easily and what is going to take more work," says Smith.
The move to Xcode "will enable us long term to more easily keep pace with Apple and leverage their OS innovations where appropriate," he adds.
Adobe has announced it is moving its Mac OS X development to Xcode as this will allow it to support PowerPC and Intel Macs from one set of code, but a spokesperson was unable to answer specific questions about the process and any problems encountered.
"By incorporating the effort to support Intel-based Macs into our normal development process -- in which we continue to evolve our product features and support for creative workflows in the ways that our creative customers expect from us -- we can deliver optimal value for those customers," says an Adobe statement.
The second beta release of Lightroom, Adobe's new application for photographers, is already a universal binary: "Because this is a beta and not yet a certified, shipping product, we have more freedom to release it quickly without the exhaustive testing required of production software."
The company remains vague about its timetable, pointing to its "consistent track record of releasing significant upgrades to our creative professional applications every 18-24 months." Since Adobe Creative Suite 2 shipped in April 2005, that would imply the universal binaries for major applications such as Photoshop, InDesign and Illustrator could appear anywhere between this October and April 2007. It seems likely that well within that timeframe Apple will ship an Intel-based replacement for the Power Macintosh G5 favoured by many users of Adobe's applications.