<i>Valgrind</i><p>Works with OS X nowadays. Plus, Xcode has the benefit of Clang's Static Analysis being <i>built right in</i>. You really can't beat checking one box and having it automatically scan over your code when you build to point out a lot of mistakes (like leaks or logic that's never hit). True, different purposes. But, you can install Valgrind. And in the meantime, Clang will catch some things for you, before you have to find them with Valgrind.<p>// edit: Whoops, I was wrong: Valgrind doesn't work on Snow Leopard yet, like I initially thought.<p><i>Apt-get</i><p>If you're targeting another Mac system, do you <i>really</i> want to ship your own version of Tck/Tk? Do you really want to use a custom library for your own development and another for shipping? Or do you want to use the one the system provides? Hint: The latter allows for much smaller downloads. Lets the user start using your software much quicker.<p><i>API stability</i><p>Theres applications out there that work on PPC and 32/64bit Intel, on any OS from Jaguar on. 7 year old applications that still work perfectly fine, across OS's that have had major changes, seems to be pretty stable API-wise to me. Not to mention, there are API's that have been deprecated since 10.3, but can still be used (even though you really shouldn't use them) in 10.6.<p><i>/proc filesystem</i><p>See the `sysctl` command instead. Bonus: You can access all this information with a sysctl() call in code too!<p><i>Compiler</i><p>Given Xcode ships with gprof, I'd be highly surprised if it doesn't actually work. And theres always Shark, that can be run without having to add special profiling flags when compiling. Or Instruments (ie: DTrace).<p>As for -arch i386 not working? Thats just not true.<p><pre><code> bash:~ Zach$ gcc -arch i386 foo.c -o foo
bash:~ Zach$ file foo
foo: Mach-O executable i386</code></pre>