Mac OS X Intel transition special report: Many apps a simple re-compile, some not
Mac OS X Intel transition special report: Many apps a simple re-compile, some not
As Apple's move to Intel processors draws near, developers large and small are rallying their efforts in an attempt to deliver Universal Binary (able to execute on both PowerPC and Intel processors) applications before, or as the first x86-based Macs are brought to market.
We spoke with a number of small to mid-sized developers who have already made the transition, offering their applications in Universal Binary form. Most indicated an easier-than-expected re-compilation, though some problems cropped up along the way.
Many applications a simple re-compile Cocoa applications that lack Carbon hooks, legacy code from the 68K to PowerPC transition or PowerPC-specific optimization routines generally require minimal re-coding efforts.
In fact, for many developers the enabling of Intel-processor compatibility is matter of clicking the "Intel" checkbox found in the "Architecture" section of the Properties tab in Apple's Xcode.
David Sinclair, author of Time Out! (a break reminder application) writes:
"Time Out! was quite easy to build as a universal binary. It is written in Cocoa, and doesn't use any custom file formats or third-party frameworks, so it was simply a matter of following Apple's instructions on adding the Intel architecture build setting.
"I have not built my other products as universal binaries yet, as most of them depend on third-party frameworks, or have custom file formats that complicate the transition. I don't think those transitions will be too difficult, but will involve more work."
DJ MacIntosh, the author of iTattle (a tool that notifies the user of network, and general system events) corroborates:
"Change the target SDK to 10.4.0u and check the Intel box, recompiled and that's it. I haven't received any negative reports. Since iTattle is based on Applescript Studio the transition took only an hour. I had it up on VersionTracker the same day of the announcement. "
One-day jobs A step up from the "one-click" transitioned apps are a bevy of programs that took less than one day to enact Intel compatibility.
Potential trouble spots include networking routines that may have PowerPC dependencies.
Mason Mark, the Product Manager for iGet (a secure tool for file transfers and performing remote Spotlight searches) told us:
"Transitioning iGet to Intel was as straightforward as we expected. Not 'click the checkbox and you're done' kind of straightforward in our case, but it did make us believe that moving to Intel is every bit as easy as Apple claims, at least for many Cocoa apps.
"iGet has a couple aspects that we had to take special care with. It runs its own proprietary network protocol on top of SSH, so we had to make sure we weren't making any PPC assumptions with respect to reading from and writing to the network. We also have a couple of our own binary file formats, and we had to update the documentation for these formats (to add endian-specific info). It was all easy stuff, because Apple's new APIs made it simple to deal with these big-endian binary formats, regardless of the Mac's processor type.
"End-to-end, moving iGet to Intel involved only about ten man-hours of coding, and a whole lot of testing (which is already part of the development process, not an added burden).
"My personal feeling, as the product manager for iGet, is that Apple is handling this transition extremely well."
Multi-week jobs Some applications, even those written entirely in Cocoa, can require significantly longer development lead times due to interaction with specific system components; use of open-source, PowerPC frameworks; or most problematic, elements held over from Classic application iterations Continued....
Satoshi Matsumoto, author of Jedit X (a full-featured text editor) told us about some problems with retaining support for opening documents created in the Mac OS Classic version of his application:
"Generally, as you know, it is very easy for Cocoa applications to translate into Universal Binaries. If it were a normal Cocoa application, it would require just re-building the source code.
"Jedit X is a Cocoa application. But it took two weeks to make the universal binary one.
"The reason is that Jedit X using a 3rd party framework 'Ogrekit" for the regular expression search. Fortunately, as 'Ogrekit' is open source, we could make a universal binary 'Ogrekit' in one week. The next week we spent making and testing the Jedit X universal binary. I needed to modify source code for the custom resource fork handling to maintain the compatibility for Classic Jedit 4.0 documents. Also I needed to modify some byte stream codes that were used for the encryption and NSCoder subclasses.
"Our final universal binary Jedit X Rev.1.30 is already available.
"For Cocoa applications, it is very easy to make Universal Binaries. But for Carbon applications, especially applications made with PowerPlant framework, developers might need to rewrite them considerably or completely."
Compatibility problems Unfortunately, the story is not so sweet for some applications that perfunctorily appear to have been successfully re-compiled with a few clicks.
One of the more interesting issues involves a situation where re-compiled Universal Binary applications have problems running under some Mac OS X 10.3.x versions on PowerPC-based Macs.
Werner Freytag, the programmer behind Renamer4Mac (a tool that renames files in batches to a preset pattern) writes:
"The transition to Universal Binary was just some mouse clicks and recompiling of the code! Since Renamer4Mac is written in Cocoa it was really that simple, nothing more.
"However I got a complaint from a user who uses Mac OS X 10.3.7, that the application crashes: The Universal Binary seems to require at least 10.3.9."
Praise for Apple's development tools Apple has obviously learned from putting its developers through 2 major programming shifts in the past decade, delivering excellent support and making Xcode a robust yet straightforward development environment.
Wincent Colaiuta, the man behind Synergy (a tool for iTunes menubar control, hotkeys, and cover art downloads) praised Apple's documentation and development tools (Xcode) in making the transition a smooth process.
He writes:
"The truth is that the transition was very, very easy. Apple's development tools make cross development and making Universal Binaries very straight forward. They also provide excellent documentation on areas of concern when preparing Universal Binaries. In most cases the transition involved nothing more than setting up the build process correctly, eliminating new warnings and errors, and testing. Only a tiny fraction of the code base itself in most of my products needed to be changed in order to work under Intel, and the changes almost always revolved around endian-dependent portions of he code. At least in my case I don't think there were any major obstacles at all. Many of us have been trained to write platform independent code anyway, and if we stick to the API documentation then we're less likely to run into trouble.
"For me there was a large incentive to get Synergy ported to Intel before Apple released any new machines because it uses a preference pane and preference panes will not run under Rosetta, so I definitely needed native Intel code.
Performance considerations Applications that do not make use of the Velocity Engine (AltiVec) should see little to no performance hit (relative to overall processor speed, bus bandwidth, etc.) when being translated for Intel compatibility.
Wincent Colaiuta writes:
"None of my products make special use of the Velocity Engine, so performance should be very similar across both platforms. Troubleshooting is not too difficult if one has access to a Developer Transition Kit (and I do). I think that unit testing comes in very handy when developing for two platforms because it allows you to have a high degree of confidence that the code performs exactly the same way on both architectures."
Some developers building separate Intel and PowerPC binaries, then combining A portion of developers are finding it easier to build separate PowerPC and Intel binaries then combine them into a single application package using Xcode's tools.
This presents a potential debacle for end users as some developers may decide to code their applications specifically for Intel compatibility while ignoring or neglecting PowerPC development efforts (or vice versa).
Mat Caughron of the MacGIMP (an open-source image editing tool that rivals Photoshop in terms of functionality) Project writes:
"The MacGIMP universal compile is done.
"After playing around with libraries on both platforms and various attempts at getting the compiler to do cross-platform builds, I ultimately built on both platforms separately and then combined the binaries with lipo.
"It works great. We've got about 25 people testing on each platform right now in preparation for the next big release. So far there are no platform-specific bugs that we've seen. Being an X windows app makes some things a bit easier."
Expense of transition kits Some developers have denounced the cost of Apple's Developer transition kits.
Craig, the developer of AddressWeb (a tool that converts Address Book entries to HTML), writes:
"AddressWeb for x86 is simply a direct recompile of the PPC version. There was absolutely no coding required.
"However, to my knowledge, it has never been tested on Mac OS X x86 and I see this as the biggest problem. I'm 99% certain it will work but there is still a chance, however slight, that it won't.
"I believe this is the biggest mistake in Apple's strategy. The development kits are simply to expensive for shareware and open source developers. Couldn't they have made the developer release available to run on standard x86 hardware just as the hackers have managed? Even an emulator would have done to test software. This is the reason that I have yet to bring over my largest Mac application (called "Stock") to x86. I am simply unsure if the compiled binary will work."
Future Outlook We asked developers to paint us a picture of how the Intel transition will affect the Mac market in general -- not only in terms of bringing new developers to the fold, but general perception from their constituency.
Mason Mark writes:
"My real analysis: it won't make a difference, to developers or users.
"OK, it does give Apple one more point in that they've shown they can move their OS to a new architecture with minimal negative impact. But moving to Intel is not a big deal. Apple will keep on making cool computers to showcase their OS. Who cares what processor it's all happening on, as long as it's a good one?
"So Intel won't scare off developers, nor particularly attract them. (I do think that Mac developers will continue to increase, as a percentage of developers doing OS-specific application development, but that's a function of the Mac platform's attributes rather than anything specific to the move to Intel.)"
Wincent Colaiuta writes:
"I wasn't programming for the Mac back in the days of the 68K to PowerPC transition but I get the impression that the current transition is going very smoothly indeed. Apple has had plenty of practice at this kind of thing and they've made it very easy for developers to make the switch. Their development tools are excellent and free and getting better all the time with each new version. Their documentation is top notch. The only downside of the whole process was the financial outlay required to obtain a Developer Transition Kit, but it's probably worth it in the end because it gives you the ability to test your product on the new platform before getting it into the hands of customers. I think that customers expect free, native Intel versions of the apps they've already bought prior to the transition; they don't want to pay for that kind of upgrade, so the question of how to recoup the outlay on the Developer Transition Kit remains to be answered. Perhaps it's just one of the costs that a developer has to absorb."
"As for how this compares to the Mac OS 9 to Mac OS X transition, I think this one has been much, much easier. The move to Mac OS X involved lots of API changes and a whole new environment and way of working; the move to Intel is really just a case minor technical tweak in comparison.
"I don't think the transition in itself will bring new developers, because most developers work at the level of C code and don't ever delve deeper down towards the hardware. What will bring more developers is the fact that Apple's getting more and more attractive all the time thanks to the success of the iPod, the iTunes Music Store, and some great products (which will hopefully only get even greater with Intel powering them). I don't know of too many developers who have been scared off by this transition, because like I said above, it really isn't too much of a big deal."
Some developers expressed concern about the possibility of Windows running on the Intel-based Macs, essentially making Windows applications universally marketable and Universal Binaries only marketable to Macs.
Satoshi Matsumoto echoes these sentiments, adding speculation about a "Yellow Box" environment that would allow Cocoa applications to run under Windows:
"When Intel-based Mac are shipped, Microsoft will probably release 'Virtual PC for Intel-based Macs" With Virtual PC, Windows applications will run with native speed on Intel-based Macs. As such, the Intel-based Mac will be the dream multi-OS machine for users. That means Mac developers must compete face to face with Windows developers.
"Universal Binary applications will run only on the Mac, while Windows applications can run both on Windows and Macintosh computers. It will be a handicap for Mac developers.
"I hope Apple releases 'Cocoa for Windows' that generates binary codes for Windows OS so that Mac developers can compete equally with Windows developers. I think this is not impossible because the OPENSTEP, that is ancestor of Cocoa, had produced binary codes both for Windows and Solaris."
David Sinclair adds "As I recall, the 68k to PowerPC transition wasn't too much different. It had different issues, like getting used to the novel concept of fat binaries, but for the most part was fairly smooth. I distributed fat binary versions of my products at the time, and didn't have too many hassles from the whole process. Mac OS 9 to Mac OS X was a bit different for me, since I mostly wrote new products instead of upgrading old ones, though I am currently working through Carbonizing an ancient Classic application for a client. I think moving from Classic to Carbon code has been the biggest transition of all, since it requires lots of API changes. The PowerPC to Intel transition seems much smaller, at least for the kind of applications I write. I can see that it could be a headache for some apps, though.
"As for the developer base, I'm not sure what effect it may have. Programming is all about APIs, so I don't think too many Windows programmers will start writing for Macs, unless they see the light and want to switch platforms. On the other hand, I don't think many Mac developers will leave, since the transition seems relatively minor. Some developers may use this as an excuse to retire out-of-date products, though."
Feedback? late-breakers@macfixit.com.
Resources