Hudson is really not hard to set up; it's what we use internally. We don't just run iphone builds from it -- in fact, there's only only one lone mac mini set up for iphone builds, and it's a relatively recent addition. We've had a half-dozen other slaves on it for other different platforms for some time.
You can play with it through the "Test Drive" link on the Meet Hudson page to get a feel for how easy it is to set up. (This is one of the things that sold me on it; it was really easy to get started with, but still configurable, extensible, and powerful enough to keep us expanding over the last few years. It replaced a really kludgy pile of hand-rolled scripts and programs that, despite being the author of, I was very happy to see laid to rest.)
We have the hudson backend running on a beefy Mac OSX server, but there's no reason you couldn't run it pretty much anywhere (linux, windows, mac).
As for configuring it for building -- it's about 6 lines of shell script in the project configuration, mostly calling xcodebuild and passing it -project and -configuration arguments.
Example:
cd ${WORKSPACE}/Engineering/
set -e
set -v
xcodebuild -project foo.xcodeproj -alltargets -configuration Distribution clean
xcodebuild -project foo.xcodeproj -alltargets -configuration Release clean
xcodebuild -project foo.xcodeproj -alltargets -configuration Debug clean
xcodebuild -project foo.xcodeproj -alltargets -configuration Distribution
xcodebuild -project foo.xcodeproj -alltargets -configuration Release
xcodebuild -project foo.xcodeproj -alltargets -configuration Debug
We haven't set up the slave to run as a service yet -- this is on the TODO list. For now we just launch it via JNLP whenever we reboot the mini it's on.
Repository is SVN, and the hudson master takes care of remembering the https auth info for us.
We actively use the Email-ext plugin, and have a build timeout plugin and an audit trail plugin since there are a lot of other people using the system and some of the builds are not well-behaved. We've experimented briefly with the Warnings plugin and Static Code Analysis plugins as well, need to get those used on more projects (we usually have warnings as errors in builds, but we do use PC-Lint and other tools on some projects; having output aggregated and tracked here is very nice). Finally the all-important Chuck Norris and Emotional Hudson plugins.
We're currently not running unit tests (shame!) on any of the iphone builds, and we just use the ordinary "Archive the Artifacts" functionality built into hudson for storing builds. These can be accessed via authorized users via the hudson web interface. I've no doubt that it would not be hard for you to run your unit tests within the framework.
</fanboy>
Our only real issues have had to do with AFP and SMB on the mac mini -- nothing to do with hudson at all, more just our internal network infrastructure. And the mini is a bit slow for my tastes -- we usually run pretty beefy build slaves on the theory that quick autobuild turnaround is a good thing. The mini may be gifted an SSD for this reason at some point.