Since the summer of 2005, Mac developers have been working hard to convert their applications to universal binaries that run on both PowerPC and Intel-based Macs. If you haven't already made the transition to the universal binary (UB) format, you don't need a crystal ball to see your future. You've got to make the change—if you want to stay in the Mac market. To help understand what you stand to gain and what problems you might encounter, ADC recently interviewed several key developers in the music and sound industry about their experience going universal. The responses make some valuable points for any Mac developer, whether you can code a tune or not.
The music and sound industry is a busy, thriving market where hundreds of Mac developers prosper by providing a wide range of hardware and software tools to pros and dedicated amateurs alike-everything from hardware or software instruments, controllers and interfaces, to recording, sequencing, and sound processing applications, to hundreds if not thousands of plug-ins.
In this vibrant market, performance is at a premium and the high-performance Intel-based Macs are in high demand, leading developers to promptly revamp their products into the universal binary format. When your application is in the UB format, your customers can install your application in native code from a single package on either a PowerPC-based Mac or on a Mac sporting an Intel processor.
In short, the UB wave is cresting, and you don't want it to leave you stranded.
To get a sense of what it's like to make this transition, ADC talked with five developers, including host application developer Abelton and one driver developer. The other three are creators of Audio Unit plug-ins that can be used in host applications that support Audio Units, such as Ableton Live, BIAS Peak, GarageBand and Logic Pro.
Developers Interviewed for This Survey
Here are the companies interviewed, their products and spokespersons who are quoted in the sections below
What Developers Are Finding
Here is a summary of the key points the developers mentioned:
Let's take a look at some of the topics these developers discussed and the issues they dealt with.
The UB Advantage
There are plenty of advantages of moving to the universal binary format, some obvious, some not.
Better performance is an one evident plus, especially if your software can take advantage the increased speed of the hardware. As B.J. Buchalter at Metric Halo puts it:
"The Intel-based Macs are simply better performing machines; we build products that use all the performance available, so the faster the machine, the better off our customers are. Having an Intel-native version really allows our customers to leverage the power of the new platform."
Less obvious, Buchalter notes, is the fact that better performance opens the door to new features. "It allows us to add features that we may have considered to be unfeasible with earlier machines." So an alert developer moving to the universal binary format might think about new features as well as increased performance-features that could open up a little daylight with the competition. Another way to find a competitive advantage is to get to market first. As Buchalter says:
"Metric Halo has one of the few product lines in its category that is native to the Intel platform. This is an opportunity for customers to take a look at us while they are waiting for other vendors to catch up, and it allows us to demonstrate our commitment to the Mac to our current and potential customers."
At Native Instruments, Michael Hirsch comments:
"Since professional music production is an area where demand for performance is very high, our customers are among the first to switch over to Intel-based Macs. It's absolutely necessary to offer universal versions of our products."
The Intel-based machines also get a thumbs up from Stefan Haller at Ableton:
"We are quite pleased with the performance of the Intel-based Macs, compared to their PowerPC counterparts. Even though the current version of Live only uses one processor core for audio rendering, the next version, due in Q3 of 2006, will distribute audio processing among both cores. This will give our users a huge performance boost."
In Stefan's opinion, though, that's not the only win. The development process itself benefits:
"The new machines give us a nice increase in productivity because they simply compile so much faster. A full clean build of our software with GCC used to take over 50 minutes on my 17" PowerBook; on the new MacBook, it takes ten minutes, which is more than a five-fold increase. That's very nice."
Advice from the Experts
What advice do developers who've made the transition have to offer? Here's what Stefan Haller at Ableton says:
"For the average software product there is really not much to go wrong. If you are already using Xcode, producing a universal binary is dead simple. The only problem that you may have to deal with is the endian issue, but this is not really difficult, just a bit of work."
Of course, if you are currently developing with CodeWarrior you'll need to port your code to Xcode in order to create a universal binary version. "If you are on CodeWarrior," comments B.J. Buchalter at Metric Halo, "bite the bullet and move your code to Xcode ASAP. This is going to be your biggest issue." (One payoff from this effort: since CodeWarrior only builds in a single-thread, compiling under Xcode on a dual-core Mac gives you a nice productivity boost.) Buchalter also has these comments about Xcode:
"If you haven't been using Xcode up until now, spend a bit of time reading the docs and familiarizing yourself with the environment and build system. It is very powerful-but different from CodeWarrior and not 100% discoverable. A couple of hours reading will save you way more than two hours time down the road. Certain aspects of an Xcode project are per-user not per-project-source trees, debugging executables, breakpoints, and so on. So things may appear to be missing when you transfer a project from one user to another. The solution is to copy these within the project bundle."
Some other suggestions from Buchalter:
"If you use custom resources and need to install flippers, make sure that you don't have the preload bit set on the resources. Also make sure that no static-init code loads the resource before you get the flipper installed-that was one definite gotcha that we encountered.
If you are in the kernel, read over the headers in the 10.4u SDK (NOTE: found at: Developer>SDKs>MacOSX 10.4u.sdk) for your family and provider. Some things have changed between PPC and i386 and they are not necessarily documented in the UB Porting Guide. You may need conditional compiles to have source code compatibility between the 10.4.0 SDK (for PPC) and the 10.4u SDK for i386.
If you are doing two-machine debugging between a PPC and an Intel box, make sure that you disable the GDB Macsbug plugin on the PPC box. It will keep you from debugging the i386 machine if it is installed."
Steve Berkley at Bias makes the case for getting started right away and tapping into the available resources:
"To get started, I strongly recommend watching the WWDC sessions from 2005 about working with Xcode and creating universal binaries. Also, joining the Xcode-users mailing list is a good idea. There is a lot of information and tips there that are helpful for anyone getting familiar with a new IDE.
Don't wait to do a universal version. Customers want UB solutions now. It requires some planning. Your QA testing, for example, will double since you have to support two processors. But it is well worth the effort."
At Native Instruments, Michael Hirsch mentions the utility of a public beta:
"With such a brand-new platform and the corresponding lack of a sufficiently large closed beta testing community, releasing a public beta version as part of the final development phase is something that should be worth considering for many developers."
Developing a Universal Version
The developers we spoke with also described the specific steps they went through to create a universal version of their application.
At Bias, Steve Berkley summarized the benefits of already being on Xcode:
"The development effort required to transition our plug-ins was minimal, since we were already using Xcode. It has basically been a matter of flipping a few settings in Xcode and recompiling. i386 Audio Units and i386 VST 2.4 plug-ins have some specific new requirements that will require some coding to address, such as implementing our plug-in GUIs as HIViews. The development effort making the transition for Peak has been more involved, since it has many endian issues to cope with, several external dependencies, and it is a large application. In addition, Peak was previously a CodeWarrior project that needed to be brought into Xcode."
And here's how Bias moved to Xcode:
"We used Xcode's 'Import CodeWarrior Project' feature, which worked very well to give us a starting point. From there, it probably took about two days of work to get the application to compile, working out differences between the compiler in Xcode and the compiler in CodeWarrior."
Getting a universal version of the Peak application to beta was about eight weeks of solid work. The areas that needed code changes were:
Berkley continues, "We required new universal libraries for our pitch and time changing features using Elastiqué from Zplane and new universal libraries to support the Aladdin HASP HL key support. We also had to recompile universal versions of the LAME MP3 encoder, our Sqweez compressor, and the Vbox plug-in. Ninety five per cent of all this work involved moving projects to Xcode, peppering the code with CFSwap routines where appropriate, and fixing references to picFrames in resource-based graphics."
Finally, he adds, "Some of our DSP features that used Altivec were using the Accelerate Framework, which is available on i386 so we were able to take advantage of SSE in those cases."
Stefan Haller at Ableton provides this account of the change to the UB format:
"We are doing cross-platform development for Windows and Mac; the Windows version is built with Microsoft Visual Studio, the PowerPC Mac version with CodeWarrior. We don't use the CodeWarrior IDE for building though; we have a custom Makefile-based build system that drives the CodeWarrior command-line compilers, so switching from CodeWarrior to Xcode was not an issue for us. Some two years ago we started extending this build system so that it can drive GCC instead of MWCC. We had several reasons for doing this: there were rumors that CodeWarrior for Mac would be discontinued (which have proven true), so long-term we knew we would have to switch; we wanted to be prepared for that when the time comes. Also, GCC has a couple of useful compiler warnings that CodeWarrior doesn't have (and vice versa, unfortunately), which helped us improve our code base.
Porting to GCC required a lot of work though, both as far as the build system is concerned-precompiled headers work in a completely different way, for instance- and for the source code itself."
Mike Kent says this about the development work at Roland:
"Xcode and the 10.4u SDK and DTK were used in our driver development. We started from existing Xcode-based driver source code for the PowerPC platform. At first, we had to adjust some code to the peculiarities of the GCC 4 compiler. However, these were small modifications. Next we changed endianness in code for audio data conversion. Finally, we went through the build and debug cycles. Since there were some issues in the core USB functionality of the OS, we worked closely with the Apple USB team and were able to solve the problems."
Michael Hirsch at Native Instruments reports on the transition work there:
"Our starting point was Metrowerks Codewarrior 8, C++ and Quickdraw. We ported the source code and the projects from CodeWarrior to Xcode. We changed checks on platform defines into checks for platform, processor and endianess defines. In some cases, modifications to the file format were necessary to cover the new case 'Little Endian on Mac.' We also made several code fixes and optimizations.
"We encountered some differences in the way C++ templates are treated by Metrowerks and GCC-basically C++ standard change issues-and some issues with Xcode related to the GDB debugger. There were some incompatibilities with plist processing, and some problems in the way that GCC deals with inline assembler and SSE/Altivec intrinsics."
Finally, B.J. Buchalter offers an in-depth look at the process at Metric Halo:
"The first step we took was to prioritize the development process. Because of the characteristics of Rosetta, some software products required an immediate port to Intel in order to be useful to the customer (KEXT and AU) whereas other products function quite well under Rosetta (SpectraFoo) and others required minor tweaks to the PPC code to function properly under Rosetta (MIO Console). Since we wanted to provide our customers with an 'out-of-the-box' experience with their Intel-based Macs, our priority was to port the components that required native support, and then move on to the components that simply benefit from native support, but function properly with Rosetta.
"Interestingly, the Rosetta translated versions of our apps actually run faster under Rosetta than natively on our primary target platform (e.g., SpectraFoo runs faster under Rosetta on a MacBook Pro than it does native on a PowerBook G4 1.67GHz).
"Our KEXT driver has always been developed in Xcode, so the porting process for this software was quite straightforward. Since the driver talks to hardware, there was some time spent identifying what data required endian swapping, a few routines that relied on Altivec for performance needed to be ported to Intel (which, in fact, was done by Apple), and then a small set of problems that needed to be resolved due to changes made to the IOAudioFamily to support Rosetta that were, shall we say, under documented. But this was a very straightforward process, even given the additional complexity imposed by being in the kernel."
In this case, developing the driver was relatively easy. Things got more challenging when it came time to transition their legacy code from CodeWarrior to Xcode:
"This codebase has been developed in CodeWarrior. As a result, the first step in turning into a universal binary involved moving it to Xcode. The process of moving it to Xcode, unfortunately, was not a smooth one for us. We had been taking stabs at it for a number of years, but something about the structures of our projects caused the import process to fail miserably. So, when UB was imminent, we stepped back and simply recreated the projects in Xcode by hand-not a simple process with literally thousands of source files. This is one of the reasons that the applications have taken longer to port—simply changing tools has been a large effort.
On the the other hand, the port for the ChannelStrip product was much less bumpy:
"The transition to Xcode for ChannelStrip went very smoothly; after dealing with a few minor changes to the code base required by GCC4 (which is more picky than CodeWarrior), all that was left was dealing with some minor endian issues in some custom resources and file formats. Again, we were able to complete this port during the Audio UB Kitchen, which was a great resource. While the project configuration features of Xcode took a little while to get used to and to understand, we have come to see that they are-and will continue to be-very helpful to us in managing our projects, which have many different targets with a common code base. All we really would like to have now is the ability to build multiple configurations in one step."
Along the way, we have also ported a large number of small internal tools and projects; these all imported into Xcode easily, quickly and smoothly. Based on this experience, the single largest issue in the UB port is getting to Xcode from CodeWarrior. So for anyone who is holding off on that step-don't; get started ASAP."
Catching the Wave
Depending on your situation, the amount of work required to move to the UB format can be minimal or significant. In any case, you've got to make the change if you want to stay in the game. The wave of additional sales and increasing market share for the Intel-based Macs is not going to subside. In fact, it is growing and gathering strength as more and more people are attracted to the power, flexibility , and security of this revolutionary combination of a great processor architecture and the world's easiest-to-use operating system.