A List Apart

Menu
Issue № 312

Apps vs. the Web

by Published in Application Development, CSS, HTML, JavaScript, Mobile/Multidevice · 31 Comments

Pull the iPhone out of your pocket and look at the home screen. Likely, you’re seeing some well known brands on the web: Facebook, Flickr, and Google to name just a few. You’ll also see companies like Amazon, Target, and Walmart which sell a lot of products via the web.

Article Continues Below

Like you, these sites and companies know how to build an effective website using the latest and greatest web technologies. The iPhone’s Safari browser also supports HTML5 markup with CSS3 styling and is powered by a fast JavaScript engine. So why is there a proliferation of apps instead of web pages that can do the same thing?

Longtime A List Apart readers may remember the Put Your Content in My Pocket articles I wrote soon after the iPhone launched. Recently, I published a book that explains how to create products for the iPhone App Store. With this article, I’d like to share my experiences with both mobile web and software development to guide your future developments on the iPhone platform.

Apple <3 standards

From Apple’s point of view, iPhone OS and web technologies share equal footing. When you visit their developer site, the Safari Dev Center is prominently displayed. The iPhone gets all the press, but when you click on Safari Dev Center, there’s a ton of great information that explains how to use HTML, CSS, and JavaScript on an iPhone.

When you look back on your first experiences with the iPhone, one app stands above the others: The Safari web browser. Suddenly you were free from a mobile internet full of crappy CSS support or dumbed down presentation-like WAP. The iPhone’s real browser and the fact that it was in your pocket changed how you used the web.

Apple continues to invest heavily in the development of the WebKit browser engine used in Safari on the iPhone, Mac, and Windows. The result is a browser that excels in HTML5 and CSS3 support.

Apple also views HTML5 support as an important part of its marketing message for both consumers and developers.

Because it’s open source, the WebKit rendering engine also powers browsers for many other mobile platforms. If you’re surfing the web with a Blackberry, Android, or Symbian phone, you’ll find that your content looks just as good as it does on the iPhone. The only holdout is Microsoft’s Windows mobile platform which uses a browser based on the IE rendering engine.

With great HTML, CSS, and JavaScript support, developers are doing amazing things with the iPhone. Here are a few notable examples:

Pie Guy by Neven Mrgan

Pie Guy uses HTML5’s offline application cache so that it works correctly when you’re not connected to the internet, as well as CSS animations and transforms for the game’s effects. Neven also keeps track of developments in this area via the HTML5 Watch website.

Showtime by Nial Giacomelli and Benjamin Gordon

Showtime is a simple app that allows you to keep track of when your favorite TV shows are on. It uses a jQuery plugin by David Kaneda that provides many of the controls and effects that you see in standard iPhone applications.

Every Time Zone by Amy Hoy and Thomas Fuchs

Every Time Zone is a very simple, but effective, view of times throughout the world. The slider that lets you pick the time works very well on a touch screen. This web application looks particularly good on an iPad display.

With such great tools available and talented developers that know how to exploit them, the iPhone should be overflowing with web applications, right? Actually, the opposite is true: there are over 100,000 titles on iTunes and only a handful of popular applications have been created with web standards.

Apple has promoted both the App Store and web browser as ways for developers to get their creations into the hands of customers. They even gave the web a year-long head start before beginning to sell apps in the store. Clearly there’s more at play here: what attracts developers to iTunes instead of the web?

Going native

Before looking at the motivations of the move toward iTunes, we need some definitions. Developers have come to categorize the two iPhone development technologies as “native” and “web.” Web apps use HTML, CSS, and JavaScript that loads in Safari. All the examples above are “web apps.”

“Native apps” are created using the Xcode development environment in a language called Objective-C. These are the same tools used to create Apple’s own built-in apps like Mail, iPod, and even Safari itself.

Creating native apps is much different than the process you use to build web apps. Luckily, many of the underlying concepts are the same. Many web developers find that making the switch isn’t that hard:

  • Like JavaScript, the Objective-C language is a descendent of C. In addition to sharing similar syntax, both languages are object oriented. If you’re comfortable with JavaScript, you’ll feel equally at ease with Objective-C.
  • Native and web apps share some familiar design elements. On the web, you’re used to breaking an application’s functionality into pages, creating a series of <div> elements to organize the content on that page, and using XMLHttpRequest to update that content. With Cocoa Touch, “view controllers” are used like pages, “views” provide the building blocks for your content, and NSURLConnection objects act as your link to the internet.
  • Frameworks handle much of the hard work. Just as you rely on jQuery or Prototype when working in JavaScript, you’ll find yourself doing the same thing with Cocoa Touch when you work in Objective-C. Both languages also benefit from a vibrant developer community that is happy to share development tricks and source code.
  • If you’re a Flash developer who’s frustrated because there’s no way to play your creations on the iPhone, you’ll be happy to learn that ActionScript, like its predecessor JavaScript, shares the same lineage with C. The mechanisms for creating animation and other visual effects are different on the iPhone, but the concepts are the same. The recently announced Sparrow framework can help ease this transition, especially if you’re using Flash to develop games. It’s also a great example of the kinds of contributions made by your fellow iPhone developers.

To give you an idea of how similar things are, take a look at this snippet of Javascript code:

var beAwesome = true;
var myString = "chocklock";
if (beAwesome) {
 myString = myString.toUpperCase();
}

Now, compare it to the same thing in Objective-C:

BOOL beAwesome = YES;
NSString *myString = @"chocklock";
if (beAwesome) {
 myString = [myString uppercaseString];
}

In Objective-C, the variable definitions are different and function calls are replaced with stuff in square brackets. In a larger context, these are minor details. You can still see the logic that to be awesome, you just convert your string to uppercase letters.

One of the goals for my book about iPhone app development was to make this new environment accessible to people coming from other backgrounds. I dedicated an entire chapter of the book to explaining those square brackets in familiar terms.

The motivation

Learning how to use new development tools will take some effort. So why should developers go through this hassle when they could just bank on the web skills they already have?

Some of the motivation is purely selfish: Native applications give the developer more control over the mobile environment. The other incentive is altruistic: a native app is generally easier for the rest of us to use.

  • Speed: JavaScript performance has increased dramatically in the past few years, but as an interpreted language, it will never be as fast as compiled code that runs directly on the processor. In a mobile environment where processors run slower to conserve power, every clock cycle counts.
  • Data Management: Cocoa Touch has several mechanisms that make it easy to store your application’s data. This is important because caching information retrieved from a network can greatly improve a mobile application’s ease of use. The persistent data storage in HTML5 provides simple key/value access or raw database access using SQL. Core Data on the iPhone provides a much more sophisticated system where relationships between your data objects are managed automatically.
  • Animation: One of the hallmarks of both web and native iPhone applications is animation that reinforces a user’s actions. CSS3 provides ways to animate page elements, but much more sophisticated effects are possible when you access the underlying Core Animation framework with native code.
  • Resources: Mobile developers never have enough memory, network speed, or CPU power. These limited resources are much harder to control when they’re being managed by JavaScript or the browser. It’s easier for native applications to detect these situations and adapt the user experience accordingly.
  • Usability: iPhone users feel most comfortable when they’re using the standard controls they’ve become accustomed to in Apple’s built-in apps. HTML abstracts controls like <input> and <textarea> so they can work in many different environments. JavaScript frameworks, like jQTouch mentioned above, do a fantastic job extending these basic control mechanisms, but an iPhone user will still notice that they feel a bit different than platform-native controls.
  • Productivity: From the developer’s point of view, it’s typically easier to build complex user interfaces using Cocoa Touch: The frameworks do much of the heavy lifting and allow you to focus on the problem rather than its implementation. With the limited amount of screen real estate on a mobile device, a simple form on the desktop often turns into multiple views whose state needs to be managed by your application. Apple developed Cocoa Touch specifically to deal with this situation.
  • Integration: An iPhone has many capabilities that are beyond the reach of the web browser. Some simple examples are the user’s contacts, the photo library, voice recording, and device movement. Cocoa Touch frameworks are the only way to access this information.

As the web has matured, its applications have naturally split into two parts: The front end and the back end. Back end services manage the user’s data and are typically powered by racks of powerful servers. The front end of a web app takes this information and presents it in the browser: HTML, CSS, and JavaScript are all about user experience. In most cases, this front end is a fairly thin layer on top of the much larger back end.

With iPhone apps, this thin presentation layer is replaced. The access to REST-based APIs implemented by the back end is exactly the same. Yes, you’re duplicating the efforts of any front end development you’ve already done for the browser, but this extra effort comes with the benefits mentioned above.

In practice

There are as many approaches to development as there are apps in iTunes. Every product and the people who created it are different. That being said, the evolution of a product from the web to the iPhone typically goes something like this:

  1. Design the product. No matter what platform you’re targeting: Be it the web or a smartphone, your first step is always to think about the problem you’re trying to solve. Figure out what your users want before you get anywhere near implementation specifics.
  2. Implement the product using web standards. Use the tools that you’re most familiar with. This way, you also end up with a solution that has the widest reach and can be viewed on any platform with a standards-compliant browser. Think about using CSS and Javascript that optimizes the experience for users on mobile devices (including the iPhone, Android, and BlackBerry).

    As a starting point, check out Put Your Content in my Pocket and Put Your Content in my Pocket, Part II.

    As you implement this product, pay close attention to how the front end user interface communicates with the back end services. Try to use a REST API that third parties and eventually your own more platform-specific solutions can use.

  3. Launch the product. Get your work into the hands of users as soon as possible. As people begin to use your creation, they’ll start giving you feedback. This starts the virtuous cycle of iteration and refinement.
  4. Run into problems. Eventually, you’ll encounter situations that can’t be solved with web standards. Maybe it’s something like feature requests from users who want to upload photos or access their list of contacts. Some users will explicitly ask for an iPhone app because so many of their other favorite sites have customized solutions.

    There can also be internal pressures from your own designers and developers. They’ll find that navigation and data management are more difficult as the scope of the application increases. When you start to feel like you’re reinventing the wheel, sometimes it’s best just to use the wheel that Apple’s already built.

  5. Translate product design into an iPhone app. You’ll find that many of the decisions you made while implementing web pages were done in the name of platform neutrality. As you enter the iPhone’s platform-specific world, you’ll want to re-evaluate some decisions. Layouts and user interaction should be tailored to make them feel at home in a native app.
  6. Launch product on iTunes. After developing the app for the iPhone, you’ll now have an important new way for users to find your content or service. Which leads to the next section…

Takin’ care of business

The other attraction for developers looking at native apps is simple: There are over 100 million customers in iTunes who can buy your app with a single button tap. They can also pay for your content with the same ease. If you’re running a business, there are some distinct advantages to building apps in addition to your website.

Brand marketing

For brand marketers, the App Store is another important channel to get a product or service in front of millions of eyeballs. The big brands mentioned at the beginning of this article continue to have a strong web presence: their iPhone app supplements their position.

Many of these companies look at a native iPhone app as a cheap form of advertising: 30 seconds during primetime can cost upwards of half a million dollars. An iPhone app will cost much less and when a marketer sees their icon appear in iTunes, it’s better than Christmas morning.

Smaller developers can also use the App Store to find new audiences and fine tune the experience for current users. You’ve already done the hard work with your back end, so the effort and expenses to build a new front end are usually minimal.

Media matters

Many websites have found it difficult to charge for access to content. The root of this problem is a lack of a convenient payment mechanism for the end user. There’s also a history of free access to information on the web. As a result, many sites rely on advertising to pay the bills.

iTunes offers you a simple way to charge users for content. It can be a one-time payment via app purchase, or a recurring payment (such as a subscription) with in-app purchases. In either case, a customer only has to tap on a buy button and enter their password. Apple handles all the payment processing and accounting. You just wait for bank deposits from around the world at the end of each month.

With the recent release and popularity of the iPad, publishers both large and small are finding it profitable to repurpose content for the iPhone OS. Wired magazine’s recent debut on the App Store generated 24,000 sales in the first 24 hours. At five dollars a copy, it doesn’t take a financial genius to realize that there is some serious consumer demand for innovative content delivered via iTunes.

If you think about it a little further, it makes complete sense from a customer’s point of view. You’re used to buying music and video from iTunes. Now with iBookstore, you can get mainstream titles delivered electronically. Adding your own content to this mix makes sense for you and your customers.

Proceed with caution

Getting your content into the App Store also includes a step that you’re probably not used to in the wilds of the web: Third-party review. Anything you submit to iTunes will be checked and can be rejected at Apple’s discretion. Every app you see in iTunes has gone through this process.

The iTunes review tends to err on the side of caution: At one point political cartoons were not allowed because they ridiculed a public figure. Apple has since eased that restriction, but there are still limits that you need to be aware of. These conditions, and other nuances of iTunes, are explored further in my book.

If your content contains nudity or any of the other areas that are disallowed, you’ve just wasted your time reading this article. Things aren’t all bad though, because you can still use Safari to circumvent the entire curatorial process.

Wrap up

So there you have it: A quick summary of what iPhone apps mean to today’s web content producers. Hopefully the information in this article is enough to determine if a dedicated mobile application is right for your site. If you decide to head down this development path, I hope you’ll find that my book is a helpful guide that explains the process from start
to finish.

31 Reader Comments

Load Comments