The Dell Mini 9 (which is Atom based) wouldn't be fast enough for the iPhone emulator (which you would use most of the time even if you own an iPhone). Moreover, Xcode on OSX86 kernels is unstable and buggy (first hand experience).
Afaik the iPhone is simulated not emulated, the binary is built for x86. So I doubt it would be too slow -- certainly not slower than the device itself.
Now that I think of it, I've tried it on a machine with an AMD processor which was 2Ghz (don't remember the exact model) but it hadn't SSE3 support. SSE3 instructions are emulated on OSX86 which makes it inherently slower. And on my 2Ghz machine with 2Gb of ram the emulator was in fact slower than the device itself.
The Intel Atom has support for SSE3 instructions so it should work better but I believe the stability problems are still there.
Intriguing you would find it slower, I guess it is possible that the binaries are built to the baseline Mac architecture requiring some instructions to be emulated via invalid instruction exception on lower instr sets, which may also explain some of your other stability issues.
But looking at your other comments I'm surmising your main contention is that one might just as well get a real Mac (eg Mini). I agree fully with this, imho the price difference is hardly worth the time to deal with all the various issues around install, upgrading etc.
I've also found the Mac mini to be completely adequate; and it still seems to me that even buying an iMac at $1k+ is still a pittance for a toolchain for this type of platform, considering one also gets a general-purpose computer to boot.
This might not affect the dell mini 9 since it uses an unpatched copy of mac os x. The changes are localized in the EFI (extensible firmware interface) I believe.
Still, I wouldn't risk losing time on possible issues.
Keep also in mind that you have to keep OSX updated to the latest version to work with the latest SDK releases. And some OSX updates update the EFI as well so there's the risk that you should have to wait for the patched EFI.
I wrote a very simple (but nice, in my obviously biased opinion) game which is on the App Store since november. It sold relatively well (at least in the first month) with zero marketing and without being featured.
Nonetheless, since then I've lost much of the initial motivation. So I know what you're talking about. Even though for me the reasons are more personal (and difficult to explain). I haven't had many problems with the whole publishing process though.
With Android, you can actually develop directly on the device (with android-scripting).
For big apps, you can download the SDK for free onto any computer that can run Java 1.5.
(At this point, Android is the only real competitor to the iPhone. Since the iPhone is the more expensive SDK of the two, I am confused as to how you can use the word "pittance".)
I was specifically referring to proprietary (closed) platforms and to SDKs with the relative level of scope/clarity/consistency we're seeing on iPhone.
Note that people mention iPhone/iPod, Nintendo DS, Sony PSP in the same breath, and on this list clearly the former has the lowest barrier to entry.
For me, somehow Android just doesn't quite fit in this categorization. (Neither does BlackBerry or the Palm SDKs of yore which also have low price tags).
But even if you want to just compare directly "phone to phone", it seems to me there is a cost that exceeds the "free" price tag on these other SDKs.
For example, I happen to be quite familiar with the openembedded toolset used to build eg the OpenMoko phones; and I have little doubt that the value of the additional time that must go into the learning curve to get going, and the effort required to produce something comparable, will easily exceed $1k for many people.
Basically, if I ask the question: to leverage $1k + time1 into $x; vs to leverage $0 + time2 into the same $x, it just always seems the $1k is a really minor barrier to entry here compared to the additional time in dealing with things like device variations.
I am inclined to think Android might change that equation somewhere down the line, but at the moment I'm just not quite seeing that picture.
