(This was supposed to be a short post, but I got excited about all the cool speakers and wrote too much. So skip to the bottom to find out how to get a limited number of 15% discount codes for registration.)

I’ve attended a lot of conferences over the last few years. The conferences I’ve attended either have a broader focus and if I’m lucky, they have a mobile track. Some simply have have a session or two on mobile.

Other conferences that are focused on mobile tend to be of two different types. They are either focused on one platform exclusively (e.g., Apple’s WWDC) or are older conferences focused on telecoms (e.g., CTIA).

I’ve enjoyed the majority of the conferences I’ve attended so I can’t complain much about the format. But what has me excited about Design4Mobile is that it is the only conference I know of that is focus on mobile design and user experience. Four days of in depth conversations on these topics.

The conference is organized by Barbara Ballard and Little Springs Design who have been working on mobile design long before the iPhone. They are experts who I follow closely.

That alone would be enough, but come on, the speaker list is just insane. Here are just a few highlights:

• Josh Clark, Global Moxie and author of Tapworthy: Designing Great iPhone Apps — I saw Josh speak at SXSW long before I met him on Twitter or knew of his book. His session was the best one I saw. Phenomenal.
• Suzanne Ginsburg, Ginsburg Design and author of Designing the iPhone User Experience: A User-Centered Approach to Sketching and Prototyping iPhone Apps — I saw Suzanne speak earlier this year in Seattle before her book was published. She interviewed a lot of designers and developers in the process of developing her book so it’s great to hear the stories of how different people tackle problems.
• Scott Jenson, Mobile UX Designer at Google — Scott was on a panel with Barbara Ballard at SXSW. He has a practical approach to mobile, has a quick wit, and was talking about how phone can be used without taking them out of your pocket which I found fascinating.
• Corey Pressman, Exprima Media — It’s strange to look forward to seeing someone speak who works down the hall from you, but Corey spoke last week at Mobile Portland and I learned two things. 1. I learned just enough about his thoughts on mobile in education and the future of textbook publishing to want to know more. 2. That he is an excellent presenter and very funny.
• Katrin Verclas, MobileActive — I admire Katrin and her work at MobileActive so much. It is this sort of work that inspires me for what mobile technology can mean for society.
• Luke Wroblewski, Entrepreneur in Residence at Benchmark Capital — I saw Luke speak at Web Visions a few years ago before he got bitten by the mobile bug. His talk was full of both data and insights. Can’t wait to hear more of his thoughts on mobile and try to figure out what his is up to next (ssshhh… It’s a secret!)

And there are many more people I can’t wait to see. I’ve meant to write this for quite some time to say simply, if you are interested in mobile—particularly mobile design—this is the conference you should attend.

I have a limited number of 15% off registration codes for the conference. If you are interested in a code, please leave a comment or fill out the contact form and I’ll send it to you.

I hope to see you in Chicago!

Exactly. In fact, it’s the same debate with new participants.

Blast from the Past: One Web Debate in 2006

Four years ago, Barbara Ballard described the debate like this:

“There are two main camps in the mobile web:

1. One Web. The Internet is the Internet, and sites should run well on all devices. Optimization should be based on CSS and device detection, but should not change site function or content beyond the necessary.
2. Mobile Web. The mobile is a different platform with different capabilities and different user needs. Sites should be optimized for mobile in many (but not all) cases.”

One of the things that struck me about last week’s discussion of CSS media queries was that there was an assumption on the part of many that delivering a single html document no matter the device was a desirable goal.

Whether people realize it or not, they’ve subscribed to the One Web viewpoint.

By contrast, many of the people who I consider leaders in mobile thought—Brian Fling, Jeff Croft, Barbara Ballard, Cameron Moll, etc.—were quick to point out that delivering different HTML makes sense most of the time for a variety of reasons ranging from performance to user context.

A Contrasting Viewpoint from Opera

In a bit of fortunate timing, between last night when I finished the draft of this post and this morning, Daniel Davis from Opera wrote about his perspective on CSS media query and One Web.

Daniel points out that Opera has “championed media queries for several years now” and points to a dedicated page detailing Opera’s full support of One Web.

Daniel outlines several positives of the One Web approach including “the obvious benefit of having only one codebase, albeit possibly more complex, to update and maintain,” and points out some potential pitfalls of content adaptation including the “there’s always likely to be an off–the–wall or cutting–edge device that falls between the cracks” of device detection databases like WURFL.

Daniel’s article is well-articulated and worth a read.

I don’t disagree with the points he makes about appeal of delivering a single HTML document, but I have yet to see anyone do it on anything other than small sites and personal blogs. And even then, the ones I’ve seen suffer from the performance items I mentioned last week.

Opera has been promoting CSS media query for mobile for several years and has a stated position on One Web, yet it doesn’t use these techniques for it’s own site.

Daniel writes that if his team “had more control over the company-wide CMS.” I wish that they did as well so we could see how they would build it.

So here we are several years after the One Web debate started and it’s easy to find sites that are based on the content adaptation and provide different html and assets based on the device class.

But outside of personal blogs and demo sites, it is difficult to find examples of pages based on delivering the same HTML to every device and using Javascript and CSS to progressively enhance the content.

Translation: We Don’t Deliver Single HTML Documents Now

Anyone who has worked on a site that supports multiple languages knows that we don’t have One Web on the desktop web. We don’t have any problem delivering different html documents and assets to someone who speaks a different language.

I have yet to see a single article arguing that we should deliver a baseline English version of web page and then use javascript to progressively enhance the page with Spanish or Chinese.

Why is it ok for us to deliver different HTML documents because the user uses a different language, but it isn’t ok for us to deliver different HTML documents because the user is using a different device?

W3C’s Definition of the One Web Does Not Mean One HTML Document

The W3C’s Mobile Best Practices Working Group tackled the issue of One Web long ago. They came to a conclusion that matches up well to my view of the mobile web.

The W3C’s Mobile Best Practices Working Group defines the One Web Principle as:

One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However, it does not mean that exactly the same information is available in exactly the same representation across all devices. The context of mobile use, device capability variations, bandwidth issues and mobile network capabilities all affect the representation.

They go on further to define “Thematic Consistency of Resource Identified by a URI“:

Content should be accessible on a range of devices irrespective of differences in presentation capabilities and access mechanism…

A bookmark captured on one device should be usable on another, different type of device even if it does not yield exactly the same experience. If the page that was bookmarked is not appropriate for the device that is now using it, an alternative that is suitable should be provided.

To summarize:

• Mobile devices should receive content that is thematically consistent with the content that someone would see at a given URI in a desktop browser.
• The content, functionality, and appearance of the information delivered to mobile devices may vary significantly from that which is delivered to the desktop web.

This is a definition of One Web that I can get behind.

One Web Means Access to Optimized Content

As more web developers start thinking about and developing for mobile, we can expect to see this debate about the One Web reemerge again and again.

You may not agree with the conclusions I’ve come to about the One Web. That’s fine.

But at minimum, make sure that you’re not simply adopting the idea of a single HTML document as being inherently better without questioning where that assumption comes from.

Is a single HTML document the best solution for your users? Or is it simply the best solution for you?

To me, One Web is about universal access to information, not delivering the exact same code, assets or even content.

In my vision, I can send a url to someone and know that no matter where they are in the world, no matter what device they are using, that they will be able see that information in a way that is optimized for them.

In 2006, two mobile operating systems controlled 81 percent of the market. This year there are 10 different smartphone operating systems.

Over that same period of time, mobile browsers have gone from many different proprietary rendering engines to the point where WebKit alone will power browsers in more than 85 percent of the smartphones sold.

Read the more of Mobile operating systems and browsers are headed in opposite directions at O’Reilly Radar.

I’m looking forward to talking about the iPad. We had a great panel last month at Mobile Portland on the iPad that I moderated. I tried my best not to jump in and offer my opinion (sometimes succeeding better than other times). It will be fun to be able to talk iPad without trying to be a neutral moderator.

In addition, I’m going to be on a panel moderated by Carlo Longino of MobHappy at Mobile Monday Austin on Monday evening.

Immediately preceding the panel, Barbara Ballard of Little Springs Design will give a presentation on Mobile User Experience Design. Barbara is one of the leaders in mobile design. Her book and blog are must reads.

The Mobile Monday event is only a couple of blocks from the center of SXSW so you have no excuse not to be there!

Finally, if you’re also going to be in Austin for SXSW, I’d love to meet you. Either connect with me via the SXSW site, Twitter, or contact me directly.

While on our blog we mostly talk about mobile, we also do a fair amount of traditional web site development work.

In particular, we’ve helped many standards-setting organizations and associations like JEDEC with their public web sites.

JEDEC came to us with substantial issues that needed to be addressed. The current site had long outgrown its information architecture and had three different navigation systems and site maps.

We performed a full content audit and combined web analytics with information architecture analysis to create a new site structure that focused on helping people find information more quickly.

In particular, web analytics showed that the majority of people coming to the site wanted to download standards. The new design brings the search interface right onto the newly designed home page.

The search interface was reworked to provide people with the ability to narrow their searches. When documents are uploaded to the site, they automatically show up on the related committee pages and other sections of the site where the documents are relevant.

We worked with JEDEC to define technology focus areas that help people new to the organization understand the current hot topics for the organization and get a quick sense about what JEDEC does. These technology focus pages are all dynamic are constantly updating with new information as documents, press releases, and events are added.

We also collaborated with other vendors to integrate event data coming from another system and to provide a single-sign on strategy with a membership management system.

Perhaps most importantly, we had a great time working with JEDEC and its staff. In particular, Emily Desjardins and Arnaud Lebegue became part of our extended team over the last few months. We’re grateful for the opportunity to work with them and to see their vision come to finally come to life.

The name comes from the fact that you can only have 20 applications on the iPhone’s Home (or first) screen.

To date, the site showcases 35 home screens from various luminaries. The site also lists the most popular applications as:

• Tweetie – 21 home screens
• Things – 11 home screens
• Facebook – 10 home screens
• Birdfeed – 9 home screens
• Instapaper – 8 home screens

Unfortunately, First and 20 was wrong. These are not the most common applications on these 35 home screens.

Here is my count based on reviewing the 35 home screens. I gave extra credit for applications that were listed in the dock because they remain visible on every screen—not just the home screen.

The most popular applications are Phone, Mail and Safari. These are the only three applications that are on all 35 home screens.

Looking at the table now, it seems obvious that these applications would be the most popular applications. Of course people want to make phone calls, send email, and browse the web.

But as I mentioned in a previous post, because of the focus on the the iPhone and the iPhone App Store, massive changes are happening right in front of everyone’s noses and most people are missing them.

The number of articles talking about App Stores and strike-it-rich application stories vastly outnumber those talking about the explosive growth of the mobile web.

Consequently, many businesses are focused on how their going to build an iPhone application and missing the fact that those same iPhone owners are already probably trying to access their web site on their mobile phone and failing.

Should it be surprising that the most popular applications on the iPhone are Phone, Mail and Safari? No, but if you believe what you read in the media these days, these applications are underdogs when competing against the explosion of apps.

Making calls. Sending email. Browsing the web. There are apps for that too.

The application in question, iSinglePayer, appears to be mostly informative from the screenshots the developer posted. It contains bar graphs and charts with information on the cost of health care. It uses GPS to find local representatives and encourages you to call them.

Frankly, there is nothing in this application that wasn’t in the Obama ‘08 official iPhone application that we helped develop.

Obama ‘08 had the following features:

• An issues section containing position papers and data similar to the bar graphs and pie charts in iSinglePayer.
• GPS location used to determine where you can contribute to the campaign similar to iSinglePayer’s use of GPS to figure out your representatives.
• A system to encourage you to call your friends to encourage them to vote for Obama similar to iSinglePayer’s feature encouraging you to call your representative.

And in case anyone thinks that Health Care Reform is substantially more controversial than last year’s Presidential election, Gallop showed Obama at 48% when the Obama ‘08 application was released. That is only seven percentage points ahead of where Rasmussen polls put public opinion on health care reform as of today.

I find rejections of applications like iSinglePayer to be more offensive than I do the rejection of Google Voice. And while I don’t expect mobile gatekeepers to change their policies, I strongly believe it is in our best interest to make sure we have viable alternatives to the app stores as soon as possible.

In case you missed it, the FCC sent letters to Apple, Google, and AT&T asking them about Apple’s rejection of the Google Voice for iPhone application and what role each company played.

Apple and AT&T released the full content of their responses to the FCC. Google asked for portions of its response to be redacted. However, a Freedom of Information Act request prompted Google to divulge the full content of their response.

And yet despite this latest revelation, the he said, she said nature of the follow ups, and word that Google may even have a screenshot proving that Apple is lying, Google Voice is nowhere near the most important App Store rejection.

That distinction belongs to Freedom Time.

Why Freedom Time Matters More than Google Voice

Like many iPhone applications, Freedom Time was a frivolous application. The application displayed a cartoon character of George Bush with arms like a Mickey Mouse watch. But instead of telling time, the application counted down the days until Inauguration Day.

Freedom Time wasn’t one of the more high-profile iPhone App Store rejections. Unlike Google Voice, people barely noticed when the application was rejected.

What is important is the reason why Freedom Time was rejected. Apple’s response to the developer was:

Upon review of your application, Freedom Time cannot be posted to the App Store because it contains content that does not comply with Community Standards. Usage of such materials, as outlined in the iPhone SDK Agreement section 3.3.12, is prohibited:

“Applications must not contain any obscene, pornographic, offensive or defamatory content or materials of any kind (text, graphics, images, photographs, etc.), or other content or materials that in Apple’s reasonable judgement may be found objectionable by iPhone or iPod touch users.”

Defaming, demeaning, or attacking political figures is not considered appropriate content for the App Store.

Can you imagine political discourse of any significance that doesn’t include demeaning or attacking political figures? Like it or not, that’s part of the exchange of ideas that form a democracy.

This policy essentially bans any editorial cartoons—cartoons that have been part of America’s history since its inception.

The idea that political discourse might be rejected from the App Store as a matter of policy surely must be a mistake, right?

Think Different? What’s the Point?

Unfortunately, it isn’t a mistake. The developer of Freedom Time emailed Steve Jobs, and he actually got a reply. Steve wrote:

Even though my personal political leanings are democratic, I think this app will be offensive to roughly half our customers. What’s the point?

Steve

I’ve often wondered what the Steve Jobs who attended Reed College during the early days of the Watergate scandal would think of that quote.

Steve Jobs, George Bush, Richard Nixon, and Scott Ritter

These four people—two that I admire and two that broke our trust—have become linked in my mind because of the Freedom Time rejection.

Freedom of speech is easy to defend when the speech is popular, but the real test comes when you have to defend unpopular speech or things that you don’t agree with.

In Fall 2008, George Bush had the worst approval ratings since Nixon. At a time in which we had one of the most unpopular Presidents in American history, Apple didn’t have the courage to approve a simple, stupid application like Freedom Time.

What is the likelihood that Apple would approve a truly controversial and unpopular application during a time when popular opinion makes it difficult to stand up for what’s right?

I find myself wondering what would have happened if former marine and U.N. Weapons Inspector Scott Ritter had tried to release an application in 2002 talking about how there were no weapons of mass destruction in Iraq.

When Ritter did speak up in 2002 and told the world that he had been in Iraq and that there were no weapons of mass destruction, popular opinion was so high in favor of Bush policies that despite being known as a patriot, conservative, and a hawk, Ritter was called a traitor by some.

What if the only means Scott Ritter had to share what he knew with the rest of the world had been through an App Store?

Flickr Censorship Pales in Comparison

Recently Flickr received a lot of scrutiny and pressure because of perceived censorship of a political image. The image showed a modified version of Obama on the cover of Time Magazine where Obama was made to look like the Joker from the most recent Batman movie.

Yahoo, the parent company for Flickr, later explained that they removed the image from Flickr because they had received a copyright infringement claim.

I don’t care to debate the Flickr censorship case. Instead, I want to ask simply why Flickr got a lot of grief for censoring a single image that they say they removed because of a copyright claim, but Apple has thus far escaped scrutiny for a standing policy that rejects any applications that attack political figures.

The image that Flickr removed would have never made it through the iPhone app review process in the first place.

The Mobile Proposition: Trade Liberty for Security

Apple has good reasons for why it has an App Store review process. It told the FCC that:

We created an approval process that reviews every application submitted to Apple for the App Store in order to protect consumer privacy, safeguard children from inappropriate content, and avoid applications that degrade the core experience of the iPhone.

This is a very similar argument that carriers and handset manufacturers have been making for years now. The argument is that mobile phones contain so much personal, sensitive information that applications need to be vetted to ensure that consumers are protected.

This is the same argument that Ben Franklin famously warned us about when he said:

Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety.

And despite the fact that we would not accept similar arguments from our government, we seem willing to give up our freedoms to mobile companies for the sake of our own security.

It’s Not About Apple. It’s About Gatekeepers

While I’ve spent most of my time focusing on Apple, please don’t mistake this as a tirade against Apple. Apple just happens to be leading the way in this area of mobile as well.

The reality is that if mobile is going to live up to its promise, we need a future without gatekeepers.

It isn’t hard to conceive of a future where more people have smartphones than have PCs. In some countries, people get more news from their mobile phones than they do from their desktop computers.

Before we get to the point where mobile phones have become the primary way that people get their news and information, we need to ensure that we have the freedom to publish what we want without restrictions.

For these reasons, I’m encouraged by the work of organizations like the Open Mobile Consortium. They are tackling the difficult work of providing truly open mobile solutions that allow people in repressive regimes to communicate freely.

The Moral Imperative of the Mobile Web

In addition to the Open Mobile Consortium, we need to make sure that there are alternatives to app stores and their gatekeepers. The best alternative is web technology.

This is why I’ve gone from thinking about mobile web technology as a smart business decision for some applications to thinking of it as a moral imperative.

Even if you are an Objective-C programmer who has had a lot of success on the iPhone App Store, it is in your best interest that the mobile web develop into a viable alternative to app stores. It is in society’s best interest.

To get to that point, we need to solve the short-coming of the mobile web. We need the technology to stabilize. We need real browsers on all phones. And we need a reliable and easy way to accept payment for our mobile web applications and services.

I cannot state this strongly enough: we need an open and free mobile web to be a viable alternative to the mobile gatekeepers to ensure that we have the freedom to say what must be said and the ability to have our voices heard by others.

Chanel was one of the early innovators in using the iPhone App Store as a marketing vehicle. They launched their iPhone application in August 2008.

The application provides the following a decent set of features. Nothing earth shattering, but they make sense for what Chanel would like to accomplish.

So what’s to complain about? Try finding the application on your phone.

Assume for a second that you don’t know that the application exists. So you’re really not looking for an application. You’re simply trying to find a local store.

You open Google in Mobile Safari and search for “Chanel.”

None of the results mention the iPhone App, but that’s ok because the top result is Chanel.com. Surely you can find what you are looking for there.

On your iPhone, Chanel.com is an empty page with a icon indicating a broken media file. The whole page is written in Flash which doesn’t work on the iPhone.

Not only can you not find any information about Chanel including where the local store might be, but you won’t even find a link to the iPhone application that they spent thousands of dollars developing.

I wish I could say this was uncommon. Unfortunately, this is typical of the mindset of American businesses when it comes to mobile. Everyone wants an iPhone application. Business logic be damned.

What good is it to have an iPhone application if no one can find it? Shouldn’t anyone be able to find your store from their mobile web browser regardless of whether they have your app or even have an iPhone?

I love my iPhone, but an iPhone app does not constitute a mobile strategy.

The five most common arguments for native app development are:

1. Offline Mode — The ability to continue to use an application when you are not connected to the Internet.
2. Findability — If you’re not in the App Store, people won’t be able to find your application.
3. Performance — Javascript on mobile is too slow to use for application development.
4. Device Attributes — The need to access things like the camera, gps and the accelerometer.
5. Monetization — The ease with which people can and will buy your application.

These five reasons are also provided to argue for native app development on other platforms like Android and Blackberry as well.

Let’s take a look at each argument in more detail and evaluate their accuracy.

Five photo courtesy Flickr user boklm published under Creative Commons.

Offline Mode

False

The Offline Mode argument is that when you build an application using web technology that you must be connected to the Internet in order to use the application.

This makes native applications more useful in a mobile context where people may lose connectivity periodically as they move from place to place.

However, this argument is simply false as far as the iPhone is concerned.

On July 11, 2008, the iPhone OS 2.0 was released. With the 2.0 release, we saw not only the creation of the App Store and the first native applications, but also a new version of Mobile Safari that supported the HTML5 Web Storage and Offline Application Cache.

To summarize, there has never been a point in time when you could build native iPhone applications when you couldn’t build web applications that supported offline usage..

Findability

Unintentionally Misleading

The basic premise of the findability argument is that if you aren’t in the iPhone App Store, that no one will find you.

In the early days of the App Store, this was true. Simply having an decent application in the App Store often enough to move units.

However, the App Store now contains 65,000 applications. Developers find it difficult to stand out in the App Store, and consumers find it difficult to find applications that match their needs.

App Store wall display at WWDC courtesy Flickr user liquidx published under Creative Commons

When it comes down to it, Apple isn’t a search engine company. It is facing challenges that Google solved years ago, but without the tools and data that Google and Amazon have at their disposal. For example:

• Google’s Page Rank innovation made it possible for network effects to be used to determine what web pages have the most value based on the number and quality of inbound links. Because the App Store is sequestered in iTunes and not on the web, inbound links cannot be used to determine value.
• Without Page Rank or similar mechanisms, Apple has been using keyword tools to provide search results. This has led to a revival of black hat search engine spamming techniques in the App Store. Apple’s attempts to address this spamming have been hamfisted and resulted in the good being punished with the bad.
• If you compare the App Store to other store fronts like Amazon, the App Store lacks the ability to narrow your search results by other metadata associated with a product.

The App Store market has many parallels to the early days of the web. We used to browse the web looking for cool things, but at some point the number of options became overwhelming and search became the dominant paradigm. We’ve moved into the search phase for the App Store, but the tools aren’t sufficient to the task.

The reality is that findability alone is not enough reason to build a native application. No matter what technology you use, you need a marketing plan.

Performance

Depends on the type of application

No one can argue that web technology is as fast as native application. What we can argue is that for certain types of applications, web performance is more than sufficient.

Here are some things to keep in mind when it comes to performance:

• Javascript performance keeps getting faster — Browser manufacturers have been competing to see who can make the fastest browser. Browsers have seen significant improvements in the last two years. This emphasis on speed has made it into the iPhone. The most recent version of the iPhone OS processes javascript 3 times faster than the previous version.
• Web developers can build faster applications — Most web developers are still not aware of the research done by Yahoo and Google on what makes web pages load more quickly. Web developers need to test their mobile code using tools like Yahoo’s YSlow and Google’s Page Speed plugins for Firefox. If developers can’t optimize for desktop browsers, they won’t succeed on mobile.
• Use hardware accelerated css — The iPhone also offers hardware accelerated css transformations, animation and 3D. Using these css tools, you can build smooth flowing effects that rival native applications as shown by the cover flow example built in Safari shown in the video below.

The final thing thing to keep in mind is that web technology isn’t perfect for all applications. Most immersive games should be built using native code.

However for numerous applications, web technology performance is more than sufficient.

Device Attributes

Real issue

GPS access was provided in the latest iPhone OS release, but the other device attributes like camera, accelerometer and compass are still not accessible in the browser.

iPhone self portrait courtesy Flickr user davemmett published under Creative Commons

The good news is that mobile phone manufacturers seem to be taking seriously the need to provide access to these attributes. The Palm Web OS is great example of exposing all of these attributes in javascript.

In July, the W3C chartered the new Device APIs and Policy Working Group to work on defining standard ways to access these device attributes.

In the meantime, usage of hybrid applications (which I will talk about later) provide a workaround for web access to device attributes.

Monetization

The Major Problem for the Mobile Web

The ability for people to play for your web application on their mobile device easily is the biggest problem facing the mobile web.

The App Store solves the payment problem elegantly. Consumers can quickly buy applications and have the purchase put on their credit card stored by iTunes. Developers know that they will get paid, how frequently, and what percentage of the transaction that Apple will take.

Innerfence iPhone Credit Card Terminal as featured in Apple iPhone ad.

Solutions like Bango have tried to solve this problem for the mobile web by brokering deals with all of the various carriers. Unfortunately, the end result is a inconsistent transaction fees per carrier and country and major gaps in service (e.g., no Verizon support).

Given the alternative, solutions like Bango are a tremendous step forward, but it still isn’t simple enough for developers and consumers.

Finding a good solution for mobile payments is the number one thing holding up the mobile web right now.

That said, there is cause for hope. Nokia recently launched Nokia Money. Apple is rumored to be “considering creating a service that would allow iTunes Store account holders to use those accounts to make purchases on participating third-party sites.”

And nearly every carrier seems to be looking for ways to allow people to pay for their groceries using their mobile phone.

If we reach the point where we can buy a bottle of water using our mobile phone, I’m certain we’ll be able to pay for products and services on the Internet.

Hybrid Frameworks Address Shortcomings

Out of the five original arguments for native applications, the two that pose the biggest challenge for web technology are Device Attributes and Monetization. Both of these shortcomings are addressed by hybrid applications.

Hybrid applications take a web rendering engine and wrap it in a native code framework. This allows developers to access device attributes via javascript in their web applications.

And because the application is wrapped in native code, the application can be sold and distributed via the iPhone App Store.

In fact, the same core code can be reused on multiple smart phone platforms like iPhone, Android, Blackberry, Windows Mobile, and Nokia.

Some of the hybrid application frameworks are:

• PhoneGap
• RhoMobile
• Titanium Mobile
• Big5
• QuickConnect

People are doing amazing things with these frameworks and are currently selling their applications in the various app stores. The following video shows a game built using Phone Gap that is currently available for purchase in the iPhone App Store:

Native vs. Web Applications

Over the last year I’ve heard a lot of people argue that building anything using web technology, particularly for the iPhone, isn’t a viable option. These five reasons are the main arguments I hear over and over again.

However, three of these arguments don’t apply in all situations and the other two can be addressed with a hybrid application strategy.

There are tremendous benefits to building an application using web technology from a platform portability perspective. Not to mention that you can draw on a larger talent pool using web technology than you can if you build using Objective C.

So in the short term if you want to use web technology to build applications, hybrid frameworks will allow you to do so. In the long run, I hope the mobile web advances to the point that they are no longer needed.

The key is to evaluate each product that you want to develop, the markets you want to serve, and determining which combination of technology will accomplish your goals.

There is no “right answer” between native and mobile web applications other than the right answer for a particular application based on its design, functionality and business plan.