Defining Your Mobile Strategy: A Guide to Developing Apps
Download PDF (212 KB).
WebKit: An Emerging Standard
What do the iPhone, Android, Nokia, Torch and upcoming BlackBerry 61 mobile browsers have in common? They all make use of an open source rendering engine called WebKit.2
This software started out as part of the Konqueror desktop browser, and was adopted by Apple for its Safari browser. Google was so enamored with it that it also uses WebKit for its own desktop browser, Chrome. Palm’s webOS is an interesting anomaly in that the operating system itself incorporates the WebKit browser rendering engine. This allows native applications to be written directly in high-level Web languages, saving valuable development time.
All this means WebKit is emerging as the de facto standard for the mobile Web. The fact that it is speedy, lightweight and handles the latest standards such as HTML5 means mobile developers can now easily access technologies that their desktop brethren, who are forced to support legacy browsers, such as IE 6, can only dream of.
1. “BlackBerry 6 coming in third quarter of this year.” http://www.engadget.com/2010/04/26/blackberry-6-coming-in-third-quarterof- this-year/?icid=engadget-iphone-url
2. WebKit, http://en.wikipedia.org/wiki/WebKit
CSC’s Mobility Practice
Our Mobility Practice dates back to 2004. Since then, we’ve introduced numerous wireless and ‘mobile’ capability areas, including wireless-capable handheld device management, cell and various wireless network services, plus the ability to develop and support both corporate and line of business applications that can operate in a wireless, anytime, anywhere context. We’ve concentrated our mobility expertise and capabilities into offerings that include Mobile Executive, Mobile Unified Communications, Mobile Worker, and related Mobility Strategy Services. In addition, many of our verticals have created mobile apps, for example our Financial Services Group recently released a mobile first-notice-of-loss application.
According to CSC’s Global Mobility lead Leonard Simmons, our Global Mobility Program has shown linear growth of 70 percent annually since introducing our Mobile Product catalog of solutions and services. He adds that we will see significant growth over the next few years.
Learn more about our mobility practice.
by Christopher Marin
Every day brings news of yet another development in the mobile world — new platforms, new capabilities and new ways to conduct business. eMarketer1 estimated that mobile will constitute 40 percent of all Internet traffic by 2013. In short, mobile is no longer something you can ignore.
If you are fortunate, you’ve already taken the time and effort to define your mobile strategy. If you’re just getting started, this guide will help you sort through the myriad of choices you will need to make to have a chance at success.
Define your objectives
Forget about networks, frameworks or any other tactical minutiae that can bog you down before you even begin. As simply as possible, define goals such as “reduce customer support costs by enabling mobile users to access our portal instead of calling our hotline.” After explicitly defining the objectives, figure out what metrics will enable you to determine the success of the project. Only after the objectives and the key metrics have been written down and accepted by all of the key stakeholders should you begin to address the tactical questions, such as the devices to target.
Pick a phone, any phone
Trying to target all of the mobile platforms is a recipe for disaster. Get as accurate a picture as possible about the devices your intended audience actually uses. If it is an internal project, and your company has standardized on a particular platform, you are in luck. But sample some users to verify that they indeed have the device and carry it with them, as there can be discrepancies. If the app is for external users, or customers that have not standardized on a single platform, you’ll need to do some research. Start with server logs or the data in your analytics services. Tools like Omniture and Google Analytics have dedicated mobile reports, and supplement this data with information obtained from surveys and analysts.
If your target users have a dominant platform, you are fortunate. If not, don’t despair. Take a hard look at your top two or three devices. Do they share similar characteristics, such as are they all Android devices, even if they are made by different manufacturers? If not, classify them by category. For example, are the majority high-end smart-phones or older devices with more limited feature sets?
Choose your app type
Ideally, you should pick one platform for a prototype, and then make the choice between building a Web, native or hybrid app
Web apps are mobile applications you can deploy on your own Web servers. Because they don’t require an external approval process, you can get this type of app up and running quickly. Additionally, new features or bug fixes can be added on the fly. A Web app is also more portable because it is possible to write it once and have it work across multiple devices, often with only minor tweaks. For example, if you are targeting high-end smart-phones like the iPhone or Android, the app can be crafted so that it works on both platforms.
Web apps are written in HTML, CSS and JavaScript, along with any number of server side technologies. Since these are the same languages used for desktop Web development, there is a large talent pool available. Taptu2, a mobile search company, conducts large-scale audits of mobile and native apps, and they contend that in the future, mobile is likely to be dominated by Web apps, as the growth rate is much higher than native apps, your other choice.
Native apps are written for specific platforms, and since they are typically written in a lower level language, they take longer to produce. Forrester estimates the average native app takes about six months to develop and costs between $20,000 and $150,000.
The advantage of a native app is that developers can access all of the functionality of the device, including features such as the accelerometer, camera and low-level graphics. Once the application is developed, it needs to be submitted to the online store, and often go through an approval process for that particular platform. For example, iPhone apps must be submitted to the iTunes store and Android apps can be distributed through the Android Market. GetJar3, the second largest native app store (with 68,000+ apps, versus the 150,000+ apps on Apple’s store and 50,000+ on the Android Marketplace4), handles native apps for BlackBerry, Nokia and Android devices.
A hybrid approach
Tools such as Appcelerator’s Titanium or PhoneGap enable a hybrid approach to mobile development. Applications can be created relatively quickly using high-level Web development languages and then compiled and delivered as native apps. While not suitable for applications that require low-level access to the hardware, such as games, the typical information management application can work with this method. The iTunes app on the iPhone uses this hybrid approach5. Another benefit is these frameworks typically enable output for multiple platforms, further reducing development costs.
Key in context
After choosing the platform and the approach (Web, native or hybrid), you need to start developing the application itself. Before a single line of code is written however, you need to determine what you are trying to accomplish.
Mobile apps are not simply desktop apps with less screen real estate. There are unique benefits and drawbacks to the medium that must be taken into account for the project to be successful. Where will this app be used? Can location or other data be used to optimize the experience? What’s the ideal session length? Given the small display, what absolutely must be displayed and what can be jettisoned? Answering these and other questions before creating the application can make for a much improved end product. A good source book is Mobile Design and Development.6
Ready for launch
If you developed a native app, it will probably need to be submitted to an online app store for your users to access it. The wait time for Apple’s iTunes marketplace has improved, but you should build time into your schedule for this process.
The Android Market, BlackBerry App World and others tend to have similar, albeit less restrictive setups. If you developed a Web app, the launch will mirror whatever process you normally use for desktop Web sites or applications. The final step in either case is to keep a close eye on the key metrics you initially defined to make sure your goals are being met and to update the app accordingly.
Christopher Marin is the site architect of www.csc.com.
1. eMarketer June 2009. http://www.emarketer.com
2. “The State of the Mobile Touch Web.” http://www.taptu.com/metrics/TaptuMobileTouchWebReportJan2010.pdf (1.2MB)
3. “Multiplatform app stores reach beyond smart phones.” http://www.reuters.com/article/idUSTRE63N1AE20100424
4. “Android Market clears the 50,000 app mark, says AndroLib.” http://www.engadget.com/2010/04/23/android-marketclears- the-50-000-app-mark-says-androlib/?icid=engadget-iphone-url
5. Allan, Alasdair, Learning iPhone Programming, O’Reilly Media, 2010. Also available online at http://oreilly.com/catalog/9780596806446
6. Fling, Brian, Mobile Design and Development, O’Reilly Media, 2009. Also available online at http://oreilly.com/catalog/9780596155452