At the beginning of June 2005 Apple shocked the Mac part of the universe: they announced that they plan to transition from currently PowerPC-based Macs to Intel-based Macs in two years. What does that mean to you as a user, and how will it impact us, as a developer?

From The User's Perspective
The user perspective is rather indifferent. Apple has an impressive track record when it comes to switching architectures, and they have the required (if not unique) know-how to make a user's transition almost painless. Surely there will be some hick-ups. A few applications may not work any more, or work but appear a bit sluggish, or exhibit the occasional unexpected behavior. On the whole, however, we expect that the problems associated with running a new Intel-based Mac won't be more troublesome to you than, for example, a switch from OS X 10.3 "Panther" to 10.4 "Tiger". It will most likely be less troublesome than what those people went through who switched from Windows NT to Windows 2000 Pro. Apple has demonstrated that it has the technology, the tools, and the know-how in place. As a user, the transition will (hopefully) be a smooth one.

From A Developer's Perspective
From a developer's standpoint, a switch to a new processor, no matter how great the tools, the know-how, and the reality-distortion-field, is always an earth-shaking event. Let's put this into perspective: imagine that you are running a business (for example a graphics workshop). Everyone in your shop works according to written instructions, and these instructions are followed by the letter. You have invested a lot of time into fine-tuning the instructions so everyone not only understands them correctly, but is also able to execute them. Now imagine you try to open the same workshop in a country that has a different culture, and that speaks a different language. Not only will you have to translate the instructions (this can be done rather quickly). The biggest problem is that different cultures simply behave differently, and instructions that make sense, and work flawlessly in one country may simply fail in another.

With processors it is similar. While it is relatively easy to simply translate the instructions from one processor (country) to another, it doesn't necessarily mean that the result will work. The surrounding architecture (culture) may be so different that the translated code fails. Fitting the translation to the new culture is the challenge that every developer faces.

cf/x's Perspective
Apple has invested quite a lot into making the transition less painful for developer. Note that no matter how well it was presented at the WWDC 05 (this was the event where Apple's CEO, Steven Jobs, announced the switch), or what some publications claim, a transition is never 'easy'. This is simply because even if the transition was a quick and efficient process, it would still take time and resources to turn a working program into the same working program for the other architecture. There is no added value for an investment of effort. And this hurts a small developer. For example, look at our products: iMovie plug-ins. We have over a hundred plug-ins that need to be transitioned. Even if we were able to update one plug-in per day, we'd still be facing an investment of 100 days - without any immediate benefit. Those are 100 days we would have preferred to invest into new products. We fear, however, that the investment is going to be much higher.

Where we are now
cf/x develops plug-ins for iMovie. These plug-ins are developed using an environment called 'Code Warrior'. This was the preferred development environment when we transitioned from OS 9 to OSX. It is also still regarded as being superior in many ways to Apple's (very good) own development system called 'XCode'.

When the Mac was originally developed, it used a a programming language called 'Pascal', a language that was invented by Swiss professor Nikolaus Wirth. Since our engineers are educated by the Swiss Federal Institute of Technology (ETH), our programming language of choice is still Pascal. Even though this choice brings it's own problems (see later), it has protected us from the traps of writing processor-specific programming. Had we, for example, programmed specifically for PowerPC's AltiVec (which doesn't exist on the Intel processor), we would have faced another, very difficult hurdle.

Do we have to transition our code?
The simplest approach would of course be to do nothing. Apple has demonstrated a brilliant piece of software called 'Rosetta' that enables the Intel processor to run the original PowerPC code. However, we expect that this will not work for our products for two reasons:

  • iMovie, the hosting application, is most likely fully ported to Intel, and we do not know if it's plug-in architecture will support a switch to Rosetta on-the-fly. [Update: Preliminary documentation provided by Apple states that an application cannot mix Intel with Rosetta code when using a plug-in architecture. Since iMovie will be Intel native this means our plug-ins have to be as well]
  • more important, however, is that Rosetta inflicts a heavy performance toll. Initial findings on the net indicate that Rosetta performs at roughly 25% to 50% of normal processor performance (which, nevertheless is an impressive achievement). Our plug-ins are processor-intensive video processing programs. A user would find it unacceptable if their new, high-performance Mac performed at one quarter of their capability.

So, yes, we must transition our code. There is no way around it.

The Road ahead
The required development system for transitioning to OS X Intel is Apple's XCode. XCode, however, does not support Pascal. This means that in order to transition a plug-in to OS X Intel, we'll have to complete the following steps:

  • re-write the whole plug-in in C (this will probably be done on CodeWarrior)
  • port the code from CodeWarrior to XCode
  • port from Carbon (an Apple technology) to Cocoa (a different Apple technology)
  • port the Code from PowerPC to Intel
  • test, correct, and publish

This translates into the following: for each of our over 100 plug-ins we will have to complete five separate steps. And each step requires some effort, just to keep the status quo. Our initial estimates are that we will require 50 to 100 days alone to transition the first plug-in (which will include porting our effect core), and from that moment on two to three days for each plug-in. That amounts to 300 days of investment which won't be easy to recapture. A big company may perhaps write off such an investment, and turn this task over to a dedicated programmer. For us that figure represents more than our complete development budget for the next year. To this we'll have to add the $1000 required to rent a test machine from Apple. This means that cf/x will face an uncertain, and perhaps difficult future. If anything, the next two years will see a significant decrease in new plug-ins while we transition our existing ones.

To sum it up:
So, in a nutshell, what does the new direction Apple is taking mean for us?
While the new processor may mean more performance, and hopefully a larger market, it definitely demands a heavy burden, and up-front investment that can easily break a small developer like us. We are cautiously optimistic that we can - but not thrilled that we have to do it.

After all, we're betting the farm on it.

 

Copyright 2005 by Christian Franz. Used with permission