I dread backwards compatibility. I dread it because it means that for every product that I need to keep backwards compatible, the testing burden is at least twice as big. The math is simple: testing on two major OS versions and two processor types can be as much as 4 times of stuff I'd rather not be doing.
The last time I had to maintain a product with backwards compatibility, this is what I used to do:
- Build then copy application to test machine.
- Get it to fail. This is the one part where I don't have to work very hard.
- Try to fix while scratching head then proceed to littering print statements all over the code.
- Go back to step 1.
You can make this process a little less sucky by configuring Xcode to copy after each build, or by mounting a share so that there's no copying at all. But in the end, debugging with print statements alone is limiting and time consuming. There has to be a better way, right?
The better way turns out to be handsomely better and it's called remote debugging. A remote debugger is usually used for kernel hacking or for developing full-screen applications such as games, but it's quite handy for fixing backward compatibility problems—especially if your app no longer builds on Tiger.
With remote debugging, I can code in Xcode 3—my new favorite IDE—then just hit command-Y. It works as any great software should. Like magic. The application launches on the test machine and you're off debugging as if it were running locally. You can set breakpoints, examine variables and stack traces, fix and continue, or whatever else that gdb can do. There's no longer a cycle of doom, and as a result, I'm a much happier person.
There are just 3 things you need to do to get stress free debugging on older systems with Xcode:
- Set up password-less ssh for logging into your test machine.
- Share the build directory in a way that both machines can access it through the same path
- Configure a new executable in Xcode for remote debugging.
The Xcode User Guide does a fine job of explaining these steps succinctly.
Some additional tips:
1. If your test machine has a different kind of processor, duplicate your Debug build configuration and set it up to build a universal binary.
2. Use "DWARF with dSYM File" as your debug metadata format. With the other two options, breakpoints set through the Xcode UI didn't work for me.