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.
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.