After a year and a day since the launch of the iPhone, Apple finally said, "Let there be SDK" and released the
Software Development Kit for the iPhone. The SDK allows you to develop iPhone-native applications that take advantage
of all the yummy goodness of the iPhone. On the other hand, developing exclusively with the iPhone SDK binds your
applications exclusively to that platform. And being bound to a particular platform, even one as successful as the
iPhone, limits your audience. And that is seldom a good thing. So, 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
is not beholden to Apple?
This article provides an overview of the process of developing web-based applications that look and feel like iPhone
apps but that are still attractive and useable without an iPhone.
Cons to Using the iPhone SDK
The single biggest advantage to going the web-app route is that you open your offering up to many other mobile devices
as well as regular browsers and not just iPhone users. Despite its rapid adoption rate and current status as the
second most popular "smartphone" there are many more people who do not have iPhones than do. With web-based apps you can cover the majority of the market and not just one specific audience.
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 already
develop 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, etc.
Pros to Using the iPhone SDK
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 provides 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 are well-staffed with Apple-based developers who are comfortable doing Objective C coding,
there is little need for you to choose the web-based route. Additionally, if the app(s) you develop are clearly
targeted at an Apple-centric audience, writing a native iPhone application probably makes sense. It will still cost
you market share amongst those who have not purchased an iPhone.
The final issue you must confront when choosing between SDK-based and web-based development is that of connectivity.
A native-built application will run on your audiences' iPhones regardless of whether they have a signal or not.
Web-based apps, by their very nature, require at least cellular access and are likely to run much better with a full
wifi connection. This is a very real concern, but one that lessens daily as every last dry cleaner, barber shop, cafe
and hotel lobby turns on free, public wireless networks.
Using the SDK Without Using the SDK
Even if you decide not to work exclusively with the iPhone SDK you might still find it has some useful aspects.
For example, Apple included some graphical widgets that you can leverage within a web-based application. Emulating
one of the interfaces Apple provided for the iPhone allows you to focus on your own development efforts rather than
designing a new interface.
Limitations to Emulating the iPhone Interface
There are limitations and hurdles when creating a web-based application that emulates the iPhone interface.
Only a few of these limitations can be addressed with viable workarounds. Limitations to emulating the iPhone
interface include:
- 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, if your application utilizes DHTML and AJAX, you inherit all of the issues that are associated with that
approach to development.
Resources to Help the iPhone Web Developer
The following content is available for you to learn from or re-use:
- JPint (http://journyx.com/jpint/), a complete framework for iPhone web development. This framework makes it easy to
generate pages that emulate several different types of iPhone screens. Applications created using this framework can
also function as Google Gadgets and degrade gracefully to Firefox.
- iPhoneWebDev.com, which is 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 website.
In Conclusion
Regardless of whether you choose to use the official iPhone SDK in whole or in 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.
