It's certainly possible to develop on a Windows machine, in fact, my first application was exclusively developed on the old Dell Precision I had at the time :)
There are three routes;
- Install OSx86 (aka iATKOS / Kalyway) on a second partition/disk and dual boot.
- Run Mac OS X Server under VMWare (Mac OS X 10.7 (Lion) onwards, read the update below).
- Use Delphi XE4 and the macincloud service. This is a commercial toolset, but the component and lib support is growing.
The first route requires modifying (or using a pre-modified) image of Leopard that can be installed on a regular PC. This is not as hard as you would think, although your success/effort ratio will depend upon how closely the hardware in your PC matches that in Mac hardware - e.g. if you're running a Core 2 Duo on an Intel Motherboard, with an NVidia graphics card you are laughing. If you're running an AMD machine or something without SSE3 it gets a little more involved.
If you purchase (or already own) a version of Leopard then this is a gray area since the Leopard EULA states you may only run it on an "Apple Labeled" machine. As many point out if you stick an Apple sticker on your PC you're probably covered.
The second option is more costly. The EULA for the workstation version of Leopard prevents it from being run under emulation and as a result, there's no support in VMWare for this. Leopard server, however, CAN be run under emulation and can be used for desktop purposes. Leopard server and VMWare are expensive, however.
If you're interested in option 1) I would suggest starting at Insanelymac and reading the OSx86 sections.
I do think you should consider whether the time you will invest is going to be worth the money you will save though. It was for me because I enjoy tinkering with this type of stuff and I started during the early iPhone betas, months before their App Store became available.
Alternatively, you could pick up a low-spec Mac Mini from eBay. You don't need much horsepower to run the SDK and you can always sell it on later if you decide to stop development or buy a better Mac.
Update: You cannot create a Mac OS X Client virtual machine for OS X 10.6 and earlier. Apple does not allow these Client OSes to be virtualized. With Mac OS X 10.7 (Lion) onwards, Apple has changed its licensing agreement in regards to virtualization. Source: VMWare KnowledgeBase
status: this has been seen as recently as Mac OS 10.8 and Xcode 4.4.
tl;dr: This can occur in two contexts: when running on the device and when running on the simulator. When running on the device, disconnecting and reconnecting the device seems to fix things.
Mike Ash suggested
launchctl list|grep UIKitApplication|awk '{print $3}'|xargs launchctl remove
This doesn't work all the time. In fact, it's never worked for me but it clearly works in some cases. Just don't know which cases. So it's worth trying.
Otherwise, the only known way to fix this is to restart the user launchd. Rebooting will do that but there is a less drastic/faster way. You'll need to create another admin user, but you only have to do that once. When things wedge, log out as yourself, log in as that user, and kill the launchd that belongs to your main user, e.g.,
sudo kill -9 `ps aux | egrep 'user_id .*[0-9] /sbin/launchd' | awk '{print $2}'`
substituting your main user name for user_id. Logging in again as your normal user gets you back to a sane state. Kinda painful, but less so than a full reboot.
details:
This has started happening more often with Lion/Xcode 4.2. (Personally, I never saw it before that combination.)
The bug seems to be in launchd, which inherits the app process as a child when the debugger stops debugging it without killing it. This is usually signaled by the app becoming a zombie, having a process status of Z in ps.
The core issue appears to be in the bootstrap name server which is implemented in launchd. This (to the extent I understand it) maps app ids to mach ports. When the bug is triggered, the app dies but doesn't get cleaned out of the bootstrap server's name server map and as result, the bootstrap server refuses to allow another instance of the app to be registered under the same name.
It was hoped (see the comments) that forcing launchd to wait() for the zombie would fix things but it doesn't. It's not the zombie status that's the core problem (which is why some zombies are benign) but the bootstrap name server and there's no known way to clear this short of killing launchd.
It looks like the bug is triggered by something bad between Xcode, gdb, and the user launchd. I just repeated the wedge by running an app in the iphone simulator, having it stopped within gdb, and then doing a build and run to the ipad simulator. It seems to be sensitive to switching simulators (iOS 4.3/iOS 5, iPad/iPhone). It doesn't happen all the time but fairly frequently when I'm switching simulators a lot.
Killing launchd while you're logged in will screw up your session. Logging out and logging back in doesn't kill the user launchd; OS X keeps the existing process around. A reboot will fix things, but that's painful. The instructions above are faster.
I've submitted a bug to Apple, FWIW. rdar://10330930
Best Answer
Download and install Xcode 4.5 (or newer), open your project in it, run in iPhone 6.0 Simulator and then: