Update 2010 April 21 :Change in Apple Developer EULA
I see a lot of traffic coming to this page (especially from forums.macrumors.com) so I decided to make one more update. Apple announced in their EULA for the 4.0 firmware that your iPhone executable must be written in objective-C and compiled with their compilers. The impact of this rule is some what ambiguous but it may mean that you cannot use any non-apple solution for development. This includes the Adobe Flash tools, Mono-Touch, and many others. From reading other pages that link to this page there seems to be an expectation that Apple should make a Windows Version of the iPhone SDK. I don't understand where such an expectation came from. Apple's always kept a pretty tight ecosystem and I can't see them making a change that would remove the requirement that any one wanting to make money off of their cash cow (the iPhone) not have to purchase Apple hardware.
Update 2009 Feb 15: More information on Dragonfire
I received a bit more information on the limitations of the SDK. From some one on the DragonFireSDK Team:
I wanted to let you know that the disadvantage you described in your article is strictly for our beta testers. Version 1.0 purchasers will have access to our Build Server where they can actually build their .app on one our our Mac servers. This will remove the "middle man".
More information on this can be found a
http://dragonfiresdk.com/buildserver.htm From looking at the page you can see that if you were to upload your program source an application deployment would be created and sent back to you.
A few days ago I made mention to the Dragon Fire SDK; an SDK said to allow one to develop for iPhone on their Windows Machine. I sent an e-mail requesting access to the SDK and promptly received a 571 Kb zip file said to contain the SDK. I thought it was unusually small. But I went through with following the instructions for compiling the sample application. After following all the instructions I ended up with a program running within an iPhone skin with a moving ball. I took a look at the output from Visual Studio and saw that it was an x86 formatted EXE. It made no sense to me, so I contacted DragonFire to ask how one was to get their application onto an iPhone.
The output was in fact a Windows executable. To produce an iPhone executable one would send their code to DragonFire and DragonFire would recompile it for the iPhone and send back the resulting file. If your iPhone is jail broken then you can install the application on your phone and run it. When you are ready to publish to the iPhone app store you would pay DragonFire a fee (I don't want to state the fee here other than saying it's lower than the cost to register for the iPhone app store) and DragonFire will compile the application and submit it on your behalf. The system is not as much a workaround as much as it is a workflow for those that don't have access to a Mac to do their own iPhone development.
Such a system has its merits and disadvantages. The obvious advantages are that one doesn't have to invest in a Macintosh if one doesn't already own one, the fees to be paid are lesser, and the registration process into the App store is taken care of. The disadvantage is now there is a middle-man that has access to your intelectual property and some one you must go through to for updates. Not to mention from Apple's perspective it is DragonFire and not you that is the publisher of the software. (updated. see text at top of page for explanation). A potential advantage or disadvantage is that instead of targetting the iPhone APIs directly you would be targeting a simplified API made by DragonFire. For those wanting to quickly put a program together this is good. But it also insulates you from many of the APIs available.
Tags: iPhone, Windows