From the moment Apple announced the transition of the Macintosh line from PowerPC to Intel processors, application developers have been busy working with Xcode 2.2 to create universal binaries that allow their applications to run on both platforms. With Intel-based Macintosh computers now shipping, it's more urgent than ever that testing and QA engineers thoroughly test their applications on both the PowerPC and Intel architectures.
This document provides an introduction to setting up your transition testing, and offers basic guidance on how you can ensure that your transition project is a success, so that your application will meet or exceed your customers' expectations when run on an Intel-based Macintosh.
Sending feedback and bug reports to Apple is also critical. Please test your application on an Intel-based Macintosh and file bugs on every issue your team finds. This will help ensure that your application receives all the system support it needs.
Universal Binary Programming Guidelines, Second Edition
The Universal Binary Programming Guidelines, Second Edition document is the central resource for both development and testing teams. It contains information that will help you understand universal binaries and other transition issues, shape your test plan, and identify the specific areas in your applications where subtle bugs might occur.
The troubleshooting section of the Guidelines is especially valuable for test engineers. You'll find it helpful when planning your test matrix on an Intel-based Macintosh. Each application has its unique testing requirements, and the troubleshooting section will help you identify the key testing requirements for your code. This section will also be very useful as a reference to help you identify and classify bugs found by your test team. This lets you guide your development engineers to a solution more quickly, and will provide you with some context for the bugs you file with Apple.
Creating a Testing Plan
There are two areas for testing that will be relevant for almost all applications: file format compatibility and Rosetta compatibility. Understanding these should be the first steps in developing a universal binary test plan.
File Format Compatibility
Developing a universal binary application that produces data files requires careful testing to ensure byte-swapping issues have not been introduced. Each processor architecture handles data in memory differently; if an application writes in-memory data to a file, and that file is moved to a different machine architecture, there is a potential for the data to be read in incorrectly. Your development engineers have operating system resources at hand to help them avoid those problems, but your test team needs to ensure that everything has been done correctly. Therefore, it's important that you test to ensure that all cases have been addressed.
If you currently have a cross-platform application that allows users to create files for use on Mac OS X as well as for Windows or Linux, then you probably already have this in your test matrix, and your engineering team has addressed those issues. What remains is to ensure that your cross-platform file format tests are extended to include Intel-based Macintoshes.
If you do not have cross-platform file compatibility testing, then it's critical that you test data files appropriately. A solution is to write files on PowerPC-based Macintoshes, then transfer them to Intel-based Macintoshes, and test to ensure they read as expected. Then perform the same procedure in reverse. For completeness you should copy preference files and test that they are also dealt with correctly when copied between different machines. Data fidelity is easy to achieve with the helper routines in Mac OS X, but insuring that it exists in critical.
Rosetta, the translator that enables PowerPC-based applications to run on Intel-based Macintoshes, also has to be factored into your test plan. Most applications should run in Rosetta, and perform correctly at an acceptable, though not optimum, speed.
Your customers who purchase an Intel-based Macintosh will run your existing application using Rosetta at least once, and perhaps for an extended period of time, especially if your release schedule does not deliver an Intel-native version of your application at Apple's product launch. Apple needs your feedback on Rosetta-related issues so they can be addressed to ensure that customers have a reasonably good experience with your application when running translated. It's therefore critical that you test your currently shipping applications using a Developer Transition System, and file any bugs you discover with Apple. Your development engineering team should not divert their attention to coding workarounds for PowerPC application issues with Rosetta; instead, filing bugs will ensure that Apple is able to enhance Rosetta so your PowerPC applications run correctly as is.
Another option you should consider is testing your universal binary with Rosetta. When your development team produces a universal binary of your application, it will contain both PowerPC and Intel executable code. When the application is launched, Mac OS X chooses the appropriate native version to run your application at maximum performance. However, on Intel-based Macintoshes, if an application includes PowerPC code, users can force the Finder to launch the application using Rosetta instead of executing the native code (see the chapter Forcing an Application to Run Translated in the Universal Binary Programming Guidelines, Second Edition). You should devote some testing resources to this scenario. Extensive testing with your full test suite should of course be done on the native side, but a quick-look test, at a minimum, should be done with a forced launch using Rosetta to validate that it does not show any issues. And be sure to file any bugs you find against Rosetta in this instance.
If your application hosts plug-ins or connects with external code modules, testing a forced-launch using Rosetta is mandatory. If your users rely on plug-ins or external code modules that don't transition to universal binaries, or do so later than your application, your users will force your application to use Rosetta in order to use those non-native plug-ins. The tests for this scenario should not vary from your standard testing on PowerPC-based Macintoshes; you simply need to ensure that this testing happens.
Adding an Intel-based Developer Transition System to your test lab and test matrix is crucial. If you review the Universal Binary Programming Guidelines, Second Edition, double-check file formats, test your application using Rosetta, and submit clear and specific bugs, you can be sure that your customers will have a smooth transition to Intel-based Macintoshes with your product.