Articles / iPhone Development: Go Web,…

iPhone Development: Go Web, Young Programmer

Sometime this month -- according to the latest rumors, anyway -- we'll find out why 2008 won't be like 2007. That's when Apple plans to release the Software Development Kit (SDK) for their runaway hit Gadget of the Century, the iPhone. As of this writing, no one outside of Cupertino can really say what the SDK will include. It might well be the keys to the kingdom. Then again, it might just prove to be the shackles that bind your development future to Apple's fortunes. You see, if you as a developer build your applications using the official iPhone SDK, then those apps are bound to the platform, and being bound to the platform, of necessity, limits your audience. That's seldom a good thing. Rather than going down that path, why not consider something bolder? 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?

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.

Pros and Cons of Web-Based iPhone Applications

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.

Using The SDK Without Using The SDK

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.

Limitations And Hurdles That You May Face

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:

  • Safari on the iPhone does not support the "position:fixed" CSS attribute. This makes it a challenge to keep elements properly positioned. JavaScript can address this.
  • If you intend to provide a main menu for your app that emulates the main iPhone screen, you may find yourself struggling to find a good way for subsequent pages to "return to top" since the iPhone's single physical button cannot be assigned new functionality.
  • As alluded to previously, access to some iPhone resources is incomplete (such as its native audio functionality) or non-existent (drag-and-drop). Some features, though, such as the ability to create a URL that initiates a phone call, are accessible and may well allow you to work around these issues.
  • Finally, since the odds are that your application will utilize DHTML and AJAX, you inherit all of the issues that are associated with that approach to development.

Resources To Help The iPhone Web Developer

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:

  • JPint, a framework for iPhone Web development (a product of the authors' company). This framework makes it easy to generate pages that emulate several different types of iPhone screens. Applications created using JPint can also function as Google Gadgets and degrade gracefully to all major browsers.
  • iPhoneWebDev.com, an excellent aggregator of resources for iPhone development.
  • The "scal" project, which provides an easy-to-use calendaring widget. One of the default styles shipped with the most recent version was designed to be as close to the iPhone calendar appearance as possible.
  • And, last but not least, the iPhone development portion of Apple's Web site. You can't get much more canonical than the big boys themselves.

In Conclusion

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.

Recent comments

30 Sep 2008 15:47 Avatar hdlee

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.

23 Feb 2008 22:41 Avatar paulproteus

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.

23 Feb 2008 07:53 Avatar forrie

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 ;-)

Screenshot

Project Spotlight

Kigo Video Converter Ultimate for Mac

A tool for converting and editing videos.

Screenshot

Project Spotlight

Kid3

An efficient tagger for MP3, Ogg/Vorbis, and FLAC files.