Whitepaper: Creating a smart mobile strategy

Creating a smart mobile strategy will require you to evaluate the current and future landscape of mobile application usage by your existing and future customers, and decide whether to create fully native applications or take another approach, such as PointAbout’s hybrid application approach.  This document examines trends in mobile adoption and the different ways to capitalize on these trends.

Reality Check: The iPhone changed everything.

Apple’s iTunes App Store has, by all measures, been an incredible success, with over 300,000,000 applications downloaded by an estimated 25 million iPhone users (some analysts say as many as 40 million iPhones have been sold worldwide, and others say Apple is planning on selling 40 million annually).

The number of applications in the iTunes Application Store have increased from 800 at the store’s opening in July, 2008 to over 10,000 as of December, 2008.

Many analysts believe that the concept of the application store will only continue to grow.  Other phone manufacturers, carriers and developers are planning application stores, or are planning on expanding and promoting their existing stores to be more accessible now that Apple has proved out the concept.

More importantly, many brands are looking to mobile applications as a new way to reach new and existing customers.  As MocoNews writes:

“What’s the next big thing in mobile advertising? Apparently, its not the oft-touted location-based ads, or mobile video, but mobile applications. Charles Henri Prevost, VP of Global Business Development at Phonevalley, the mobile arm of ad giant Publicis, told MobiAd, “Almost every request we get from a brand these days includes a mobile application.” Scott Seaborn, Ogilvy Group UK’s head of mobile, reported that three years ago, the ad firm was mostly doing WAP banners, while for the past several months, it has been doing applications.”

This whitepaper will explore the growth and trends in creating mobile applications as a way for brands to reach consumers, and more importantly, two different approaches to doing so.  The first is the traditional approach of creating a fully native application, which basically involves creating a piece of custom software for each phone platform (iPhone, BlackBerry, Android, etc.).   The second approach is one that’s being pioneered by PointAbout, and is much less understood, which is wrapping a micro website (we call it a “microsite”) with a thin-client springboard piece of native code, so that the bulk of the application is actually a website, not a native piece of code.  For the purpose of this whitepaper, we’ll take a hard look at the pro’s & con’s of each approach.

Executive Summary:

Creating a custom mobile application is currently an expensive proposition.  Few of the traditional software or web development companies have developers skilled in the programming techniques required to make mobile applications.  Currently, the cost of a fully-featured native application on the iPhone typically runs $50,000 on the low end to $150,000 on the high end, and the development cycle typically runs one to three months.  BlackBerry can be more expensive depending on how many BlackBerry models a company wants its application to run on.  Android is newer, so not as many applications have been created for it, but we would expect the costs to be similar.  A company can safely plan on spending at least $50,000 for each phone platform ($150,000 combined for iPhone, BlackBerry and Android) it creates a native application on.  We expect to see these costs come down as more developers rush to fill this demand; prices have already dropped by approximately 11% in the past 9 months.  One thing that won’t change is the need to create a separate application for each phone platform, as the phone handset and OS market is very fragmented.  The big advantage of native applications over websites is the ability for arcate style graphics & usability, offline usage (in the subway, etc.) and the speed of the application (both perceived and actual).

In contrast, using a hybrid approach, where the body of the application is web-based with a thin-client springboard wrapping it, is cheaper but has its own limitations.  The up-front cost can be as little as $1,000 plus the cost of developing a web application, which uses more widely available web developers.  A business could safely plan on spending $50,000 to create an application that runs across multiple phone platforms, which equates to 33% of the cost of creating a native application.  One of the main advantages of using the hybrid approach is “write once, run anywhere” functionality, lower maintenance costs over the long run, and less obsolescence of the mobile app vs. native app over time.

More details on the pro’s and con’s of both approaches are included in sections below.

Market Trends & Usage Statistics:

Application downloads have been increasing dramatically since the opening of the iPhone’s application store from zero in June of 2008 to 300 million by the end of 2008, as the number of iPhones in the world has increased from zero in June of 2007 to an estimated 25 million today (note: Apple holds phone sales close to the vest, but these numbers are based of statements made by Apple and growth estimated by industry experts.  Some experts peg the number of iPhones as high as 40 million) .

The second generation of the iPhone, commonly referred to as the “iPhone 3G” for its third generation broadband speed, sharply drove sales figures up.

iPhone users tend to be active content creators.  Studies have shown a marked difference between BlackBerry and iPhone users. Whereas BlackBerry users tend to be heavy email users, and will often pick their BlackBerry up, check email, and set it back down, iPhone users, by contrast, tend to “surf” the web on their phones and actively create content such as comments on websites, blog posts, and rich media creation, in addition to email usage.  The BlackBerry’s physical keyboard gives it a major edge in email use, but the iPhone’s touch interface, ability to pinch & zoom, and ease of filling online forms out gives it an edge in content creation other than email.

Additionally, iPhone users typically download many applications onto their phones.  The average number of application downloads per iPhone user has surpassed ten applications.  This, coupled with the increasing number of iPhones, is what is leading to the high number of downloads in the iTunes App Store.

Other phones are rushing to capitalize on the success seen by the iPhone, including the Google Android phone (called the “G1,” the handset is made by HTC) and the Palm Pre phone, among others.  We expect to see an explosion of app stores by the different phone manufacturers and carriers.  PointAbout has a “write once, run anywhere” philosophy that will enable our clients to maximize the reach and ROI of their mobile investment.   Our approach also allows users to make mobile applications in minutes instead of months using our AppMakr.com mobile application automator.  This is described in more detail below.

While the mobile smartphone audience may only comprise 5% to 10% of a company’s user base today, there are two very important aspects to consider:  1) The number of mobile users will only be increasing, not decreasing, so planning a smart strategy for your current users to interface with your business from their mobile device, and ways to gain new users through mobile applications, is just good business.  2) Even at a low adoption level like 5% to 10%, having a mobile component will allow a business to enhance the experience that its entire customer base has.  As an example, if even just 1 out of every 100 of a business’ customers have a smart phone such as the iPhone, they can create content on their phones, and upload it to the company’s PC website, which the other 99 non-mobile users can then consume.  Think of the journalism paradigm – one reporter can create news that millions of people consume.  It only takes a very small adoption of a mobile strategy by the user base to change the experience of the entire user base.

Pro’s & con’s of fully native application building vs. PointAbout’s hybrid approach:

Creating native mobile applications is a “must have” for many companies right now, and for many others, it’s on the wish list.  Many companies and individuals are seeing the effect that smartphones, and the Apple iPhone in particular, are having on their industries, or if they’re not seeing the effects yet, they know the effects will become apparent soon.

This has led to a mad rush to find native application developers.  For iPhones, all native applications are developed in Objective C.  By “native,” we mean software – native applications are self-contained pieces of software, just like software you would put on your computer.  In fact the analogy is very apt – imagine that installing a native application on a phone is just like installing Microsoft Office on a computer.  You are paying for a piece of software that you install.  It can’t be changed later without an update, so what you pay for is what you get.  Just like Microsoft Office, a native iPhone application usually connects to the Internet to get data or updates, so it still requires an Internet connection.

In contrast, PointAbout’s hybrid approach is more like a container, sometimes referred to as a wrapper.  Our technical term for it is a “thin-client springboard.”  What we mean by that, is that the native application is only a shell of the true content.  The actual content is served from the web.  So you can think of PointAbout’s thin-client springboard as being a very specialized, white labeled browser client.  It can do everything that the Safari browser can do, while in addition providing the user with many more options that are not accessible from the Safari browser.

For example, Safari cannot pull GPS information off the phone.  It cannot pull camera, address book, accelerometer, or any other information off the phone.  However, PointAbout’s springboard can.

In fact, not only do we pull the information off the phone, but we also abstract the information up to the Javascript level so it’s accessible to web developers.  So for example, to use a picture using the iPhone’s camera or camera roll, a web developer using PointAbout can reference the following javascript command in his code: 

device.Image.getFromPhotoLibrary(); .  

It’s that simple – any web developer who’s familiar with javascript will immediately understand how to use these simple javascript commands.

Applications created using the PointAbout springboard can be made to look & feel very native.  For example, the application Are You Safe, which utilizes the PointAbout platform, looks, feels & acts very much like a native application.  In fact, the PointAbout springboard is completely invisible in the Are You Save application – the user can’t even see the container that’s serving up the Are You Save web application within it.

The big upside of creating native software for the phone vs. using a hybrid approach is that “arcade style” graphics will render much better in a native application.  So if you’re considering a car racing game, for example, PointAbout will not be a good solution for you, because HTML on the iPhone cannot replicate these arcade style graphics (note: if the iPhone could play Flash, it would be able to replicate arcade style graphics, but Flash is not currently available on the iPhone, and may never be).

However, barring this limitation, the advantages to coding to the web are numerous, not the least of which is the vastly lower cost and increased flexibility of using PointAbout’s platform vs. native application development.

For example, when you make a fully native application, it cannot be changed once it’s distributed to the user.  Just like in the Microsoft Office analogy, if you want to change the functionality of the application, you’ll have to send out an update to all the users, which they may or may not install immediately.

However, when you’re serving all the actual content up as a web page inside PointAbout’s thin client springboard, you do not have this limitation.  In fact, since you’re just working with a microsite web page, you can change the user’s experience as often as you want.  You can also tie the microsite application into your PC version website, meaning you can use the same database backend, the same 128 bit https encryption, etc., that you’re using for your regular website.

The implications of this are staggering.  Most businesses focus the majority of their attention on the PC version of their website/web application.  Most of their resources go to innovating on this PC site.  So just imagine 2 years down the road, if you make a native application, there is simply no way that the native application can keep up with the innovation your business will be doing on your PC website.  

In fact, we would argue that, by definition, the native application can never be as good as your main website – a disparity that will increase over time.  For most companies, this fact will not become apparent for several years, because when the native application is first released, it’ll mimic the business goals of the company and the functionality of the main website.  However, over time, that business will add features to its website, get into new lines of business, new pricing structures, etc., and the native application will fall behind, because the resources that are being devoted to 80% to 95% of the PC users to change their PC-based internet experience will dwarf the much more expensive resources required to change the experience that 5% to 20% of the mobile users are having.  

Just imagine this scenario:  You’re in a business meeting with the marketing department, and they want to try a new messaging campaign for the company.  You agree that you’re going to roll this out in 30 days.  You task your web developers to position the site for this new message, and they get on it.  However, now you have to figure out how to roll this message out to your mobile users.  Native application developers are more expensive, and more in demand, than web developers.  So first you have to go about procuring these developers, then you have to task them with making a “version 1.1″ of the application.  Once that heavy lift is done, you have to send it out to all the mobile users.  This requires you to re-submit the entire application to Apple and have it approved.  That process will take several days, assuming its not rejected for any reason.  But what if you want to make a last-minute change?  You’re out of luck – the entire process (probably 15 to 60 days) would have to be repeated.  And this is even assuming that your user base installs the update.  Many phone users don’t install updates immediately, if at all.

Now contrast the fully native approach with PointAbout’s hybrid approach.  As your web team is updating the message on your corporate PC based site, they also make changes to the web microsite that sits inside the PointAbout container.  Any data changes are automatically propagated to both the PC site and the mobile microsite, since they use a common database.  You can use the same web programmers for the mobile microsite as you’re using for the PC site.  And any changes are automatically served up to the user inside the native, private labeled PointAbout springboard that the user has installed on his phone.  No fuss and no updates required.  Everything is immediate and transparent.  The mobile development cycle is integrated and performed in conjunction with the PC website development cycle.  Additionally, this microsite will be served across multiple mobile devices, so the painful native process described above doesn’t have to be replicated across each type of device.

One perceived advantage of native applications is their ability to store data locally on the phone so the user does not need to have an internet connection to use the application, for example, when they are in the subway.  The reality is that often, applications will still have to ping the internet to pull data down, so this is not quite the advantage to native that it may seem at first blush.  However, PointAbout is currently working on a release of its native thin client springboard that will include a local storage component.  This will also be available as a javascript call to web programmers.  Look for this to be available during the 2nd quarter of 2009.

Lastly, using PointAbout’s approach and a tool we’ve released called AppMakr, which is an automation engine for the creation of mobile apps, where mobile applications can be created in minutes instead of months, and at a cost that is several orders of magnitude less, allows businesses to completely change the way they think about making mobile applications.  For example, instead of making one application that’s branded for your business, why not make an application for each of your customers that interfaces with your business process?  Imagine being able to private-label a customized mobile application that is individualized for each client, customer or user.  PointAbout enables this type of thought process – something that just isn’t possible using a native approach.  Mobile applications can turn into revenue generators instead of cost centers. 

Written by Daniel R. Odio, co-founder, PointAbout, Inc.

1.800.976.3703 (w) 202.250.3846 (m) or Daniel.Odio@PointAbout.com