So you want to get your software in the hands of the hundreds of millions of smartphone users around the world. Perhaps your boss said "mobile" is the new buzzword. Perhaps you're worried that some are saying the PC's time in the sun will be over soon.
It doesn't matter why you want to develop mobile apps. The problem is that following through is still pretty tricky. The iPhone and iPad want code written in Objective-C, and that language remains a bit obscure. Plus, once you're done coding, there's a distinct possibility that Apple will slam the door to the App Store right in your face for some unknowable reason.
[ Get your websites up to speed with HTML5 today using the techniques in InfoWorld's HTML5 Deep Dive PDF how-to report. ]
The Android smartphones speak the more popular Java, and there's no controlled app store to hinder distribution, but they're still a distant second, at least in the world's mind share. BlackBerrys speak Java, but they use an entirely different Java API, so you need new routines for them. And Microsoft recently introduced Windows Phone 7, which uses Silverlight and .Net.
To make matters worse, smartphones don't have much memory, and they're constantly shutting down services to save battery life. Coding for them often involves tricks not often used in desktop apps.
The end result is that mobile app development is a pain -- but there's another path than using each mobile platform's specific language and development tools: HTML applications that run in smartphones' Web browsers. The iPhone and the Android smartphones both come with browsers based on the open source WebKit project, as do Nokia's Symbian and Palm's WebOS. BlackBerry OS 6, found in the Torch model, also uses a WebKit-based browser. Thus, a website designed for any of these devices will look and behave pretty similarly on the others. (The exceptions: Windows Phone 7 and older BlackBerry OS versions, whose browers are based on more limited, proprietary technologies.)
Creating an HTML Web app tuned for smartphones instead of creating a full, native app has several advantages:
- It is naturally cross-platform.
- Although the small screen is a challenge for designers, it is usually possible to borrow code from desktop websites.
- Updates happen on your schedule, not an app store's, and there are no arbitrary rules that might keep your Web page from reaching its audience.
- It's often relatively easy to recode the presentation layer of your website to produce the optimized HTML code for the mobile platforms. In some cases, it just takes a new CSS file.
The HTML code can arrive at the smartphone through two paths. The simplest is to store it at a Web server that detects the browser and delivers a special smartphone version to any visitor. In that path, it's a website and an app at the same time, a move encouraged by the operating systems.
But there also are ways to bundle the HTML code into a stand-alone app that resides on the mobile device by wrapping a thin layer of native code around it. Whichever path you choose, the logic and artwork are the same. (And with portions of the draft HTML5 specification finding their way into mobile browsers, your HTML-based mobile apps can act more like traditional apps, such as by taking advantage of HTML5's offline storage and canvas capabilities.)
There are, however, several big classes of applications that don't work well as HTML apps. In addition, parts of the smartphone hardware such as the camera are hard to access, and at times, the access is completely blocked. Game programmers will notice immediately that the response time is slower, often dramatically so. Even publishers looking to package a book as an app will find that some behavior can be sluggish for content that's supposed to flip and zip around like game sprites.
Still, many applications can be written in HTML successfully, such as sites that display information from databases. For example, apps such as those from Facebook and Yelp format data for easier viewing, which doesn't require zippy sprites or instantaneous responses. Although many of the top-selling apps are games such as Angry Birds, many of them -- including apps for the Weather Channel, Netflix, and books -- are easy to deliver in pure HTML.
Here are the four paths to bringing an HTML Web app to smartphones everywhere. No matter what you choose, though, you'll also have to think about how to deliver the app to your users, as I later explain.
Path 1: Open source libraries for websites Some of the first people to understand the effectiveness of the HTML model were open source programmers who demonstrated the power of the mobile browsers by quickly mocking up the right CSS files to make the HTML look just like the stock applications from Apple. With the right CSS, a list of data marked up with <li> tags would look like an Objective-C ListView built with several files of basic Objective-C. Good instances of this approach include iUi, jQTouch, jQueryMobile, and iWebKit.
Working with these libraries is easy if all you want to display are basic lists and blocks of information on your phone, such as lists that slide back and forth. Each package comes with several styles, and you can always tweak the user interfaces by adjusting the CSS files.
If the foundations matter, both jQueryMobile and jQTouch are integrated with jQuery, which makes it a bit easier to work with many of the other jQuery plug-ins. iWebKit and iUi stand alone and rely more on CSS.
All four libraries, given their open source nature, are closer to hobbies than full-on development toolkits, even though they're polished enough to be used on many basic commercial projects. iUi, for example, hasn't seen a new bundle of code since version 0.40 in December 2009. iWebKit rolled from version 5.0.3 to 5.0.4 in March 2010 and has been quiet since. At the moment, jQueryMobile seems to have the most momentum. jQTouch receives plenty of attention, with recently added themes and maintenance work to improve the sensitivity of touch events.
The bottom line is that these open source libraries are just beginnings, not fully formed packages. If you're building a sophisticated app, you'll need to be ready to do some hacking yourself.
Path 2: Mobile repackagers There are a surprisingly large number of websites that repackage information for mobile platforms. Some are thin veneers that scrape the data off of your main website, and others offer more sophisticated tools for editing the content, but all are effectively a well-tuned collection of templates that repackage the information in a way that's easier to read on a phone.
Mobify, for example, takes the URL of your regular website and lets you select the crucial DIVs with a neat visual editor. Then you can test the result in several different sized screens and, if you're satisfied, push the button and go live in several minutes. The tool scrapes your site and republishes the information from the selected DIVs.
Similar repackaging services include Mippin's Mobilizer, which is is integrated with AdMob's ad network; Onbile and Wirenode, which have some mod templates; Winksite, which integrates a basic community network next to your content; Mofuse, which has QR 2D bar codes integrated with a URL shortener; and Yahoo's Blueprint, which is tuned for "thousands of mobile devices," including the iPad.
All these sites are regularly adding new features and will undoubtably imitate the best innovations of their competitors. Using tools like these simplifies the process of creating a website dramatically. The downside is that all the websites from one service have the same flavor, and there's little opportunity to move too far afield. Although the structure can provide a fair amount of flexibility, especially if you supply your mobile site with an RSS feed from your main site, there's still the potential for being locked into a plan.
Path 3: Plug-ins If the screen-scraping repackaging sites just pour the data into a different template built out of HTML and CSS, there's no reason why you can't integrate such mobile-optimized HTML and CSS into the main website to begin with. Doing it is not as simple as delegating all of the repackaging to another website, but it does bring more control.
In many cases, it's often relatively easy. Some Drupal plug-ins, for example, automatically detect the browser sending the request, then automatically chooses the right template, which may be a simplified one designed for mobile phones. The iUi plug-in uses the iUi interface library to format the content for the iPhone and others WebKit browsers. Others such as the iDrupal UI, Mobile Tools, and Mobile Plugin follow a similar plan.
There are several related plug-ins for all the major CMSes. WPtouch is popular and has a proprietary version that costs $39. Joomla users can turn to TapTheme for similar skins that work with iPads as well.
All these approaches offer more control than any mobile repackaging site. The code is generally open source, and modifications are both often possible and usually feasible. When the modules are well-maintained, this approach can offer most of the advantages of a hosted mobile repackaging site with the control of owning the server. But if the module developers get called onto other projects, the work falls onto your shoulders.
Sencha's professional touch is apparent. There are more features, more panels, more widgets, and more design options than in open source options. The documentation is also much better than many of the open source projects, but it is still not as deep as I would like; on several occasions, I found it was missing or just based on an earlier version of the code.
The simplest approach is to place the package on a Web server and let the Internet do what it does best. If the HTML and CSS code is well-designed, the result will be almost indistinguishable from an installed app.
Apple's iOS has a nice ability to bookmark websites by turning them into icons on the home screen. The user just needs to tap the Action button when viewing a page in Safari, then choose Add to Home Screen from the menu that appears. (The Action button's icon used to be a plus sign but was recently changed to an arrow emerging from a rectangle.) You can have an app icon appear for this app on the home screen (rather than a thumbnail image of the website's page) by creating a 48-by-48-pixel or larger PNG icon file and referring to it in the Web page's header using the <link rel="apple-touch-icon" href="/iphone-icon.png" /> statement.
Likewise, Android 2.1 and later can put a bookmark on its home screen and attach what it calls a launcher icon using the same header code as iOS uses. (A sustained tap on the bookmark opens up a menu that offers the chance to add a shortcut to the home screen.)
Handling performance issues through hybrid apps Having the entire app on the Web server means the performance depends heavily on the quality of the device's Internet connection. Thus, a Web app won't usually work well if all the parts are kept on the server.
One solution to the performance issue is to include a cache manifest, an HTML5 enhancement that specifies which parts to keep on hand. A well-designed architecture can keep all the useful parts within reach and still erase the dynamic data that's not in use.
The manifest can also be combined with local databases to store local information. This technique works with modern HTML5 browsers as well.
However, bundling the HTML with a native wrapper means that the wrapper must be developed in each device's native development enviroment (not a horrible burden) and the resulting app must be delivered through the traditional app store channels, with all of the pleasures and pains that they bring for developers. In the past, Apple fretted about hybrid apps like this and often blocked them, but recently it's been much more open to this development model.