This article will provide an overview of the process of developing Web-based applications that look and feel like iPhone apps when accessed via that marvel of technology but that are still attractive and usable to the unwashed masses who haven't been able to summon up the funds to buy their own little slice of the future.
The single biggest advantage to going the Web-app route is that you open your offering to run on many other mobile devices as well as regular browsers. Why limit your market when you don't have to? Despite its rapid adoption rate and current status as the second most popular "smartphone", there are many more people who don't have iPhones than do. With Web-based apps, you can have your cake and eat it, too.
Beyond the aforementioned "market-size" argument for shunning the iPhone SDK in favor of Web-based development, there is one more key reason to choose this route: ready availability of specific programming skills. If you're already developing applications, the odds are strong that your organization already has plenty of developers who know how to code for the Web, be it in JavaScript, Perl, Python, Ruby, or whatever your development environment of choice may be.
In the face of these two key points, though, there are some very real reasons to use the iPhone SDK. Foremost among these is the simple fact that the SDK will (likely) provide access to some base-level resources on the iPhone such as audio recording and playback. These are functions that certainly cannot be accessed via a Web-based application, so if your app needs to take advantage of these aspects of the iPhone, consider yourself SDK-bound.
The second critical issue that might make it more reasonable for you to embrace the SDK is simply a matter of talent and focus within your organization. If you are already firmly established as a developer of Apple-specific applications and you're well-staffed with Apple-based developers, there's little need for you to choose the Web-based route, at least not as a hedge against not having the appropriate talent on hand. Additionally, if the app(s) you're going to be developing are clearly targeted at an Apple-centric audience, writing a native iPhone application probably makes sense.
Just because you probably shouldn't chain yourself to the SDK doesn't mean there won't be anything useful contained within it. On the contrary, the good folks at Apple might just include some lovely graphical widgets that you can imitate (I mean "leverage") within your Web-based application. Further, since Apple's interface design skills are so far above what most companies can bring to the market, if it is possible for a given function of your application to be realized by emulating one of the interfaces Apple has provided on the iPhone, you'd be a fool not to use that interface as a model for your own development efforts.
Needless to say, there are limitations and hurdles that must be overcome when creating a Web-based application that emulates the iPhone interface. These are made all the more daunting by the fact that only a few may be addressed with truly viable workarounds. Included among these "gotchas" are:
Fortunately, the issues outlined above have not deterred the ambitious programmers of the world one tiny bit. In fact, a number of hard-working and innovative individuals have already produced a fair amount of content that's just out there waiting for you to learn from or, quite possibly, even reuse for your own projects. Among these are:
Regardless of whether you choose to use the official SDK -- in whole or part -- or to develop Web-based applications that users can access via Safari, the iPhone is definitely a wide-open frontier for development. So get out there and get coding. Just don't try to muscle in on any spaces that we're working on.
iPhone Development and End-User Hopes & Expectations
As an avid iPhone consumer having found myself utterly dependent upon this device and after having tasted the "jailbreak" functionality in an earlier revision of the code... as a UNIX systems administrator, it is my hopes that Apple will acquiesce and allow us to develop and utilize functionality that the jailbroken phones provided - such as SSH, console applications, etc.
There must be some "safe" way to accomplish this so that Apple's stuff doesn't suffer. Run it on a non-privileged port, etc.
Until we know the details of the SDK, we can only guess. But my "safe" guess is that their initial revision of the SDK will be severely limited to developing applications that run only on the iPhone and do not allow for networking. Let's hope I'm wrong ;-)
Web applications are code hoarding 2.0
You wrote: "Why not strike out on your own and build a Web-based application that looks as good as a native iPhone app but that isn't beholden to Apple?"
Answer: Because then my users can't fix my bugs or add their own features.
One of the joys of open source and free software is that I can build something that works for me and share it. If someone else wants to customize it or improve it to better suit their needs, they can. As a developer, it frees me from having to solve everyone's problems. As a user, it empowers me to make other people's code more useful to me.
Web applications lack this flexibility.
Definitely a lucrative career
With the surge of demand for iPhone apps, being able to create and market an innovative apps will make someone a millionaire.
I've already seen a few apps that are very successful. Another trend is facebook application programming. Thanks for pointing out some useful resources. Your help is appreciated.