The (Eventual) Return of Mobile Applications to the Web

I don’t think that I’m overstating things by saying that the web has changed the world. There is no doubt about it in my mind. The past 20 years or so have been a continuous stream of innovation. We’ve seen the web transform from a simple platform used by government agencies to share information into something whose capabilities seem limitless. Streaming media, e-commerce, full fledged office applications, real time news from more sources than you can imagine, and much more. It truly is amazing what we’ve been able to accomplish with a platform whose original purpose was to share static documents.

The Rise of the App

However, the web does have limitations. One such limitation has long been the ability to interact with the hardware you are using to browse the web. Over the years technologies have been developed to help with this limitation (Java, Flash, etc), but I see those technologies as extensions the web, and not part of the web itself. Those technologies have carried their own set of drawbacks as well, such as requiring the installation of client software, performance issues, and security vulnerabilities.

Nowhere is this limitation more obvious then in the mobile arena. Today’s smartphones are amazing. You have a camera, a GPS, a MP3 player, a web browser, oh…and a phone too, all wrapped up in one device. It’s like walking around with a tiny computer in your pocket. But currently, the web is only able to utilize a tiny fraction of this functionality. Its document centric design, which has been stretched, twisted, and pulled in directions that its creators never could have imagined, appears to have finally reached its limit.

In addition to hardware access limitations, may web applications were not designed to be viewed on a device with such a small screen and no mouse. It can be very difficult to view a 900 pixel wide web page on a screen that is only a couple of inches wide. And while you can zoom in over certain areas of the page, not being able to view and interact with the page in its entirety introduces some big usability issues. Also, many web applications rely on mouse over events to interact with the user. Drop down menus are a perfect example of this. There is no mouse on today’s touch screen smartphones, making these sites very difficult to navigate when viewed on a mobile device.

These limitations have given rise to “the app”. The app, a native application that runs on the smartphone itself, it not a new idea. Smartphones have been around for quite some time, and these phones have always had native applications. But only recently did Apple change the game by providing independent application developers with a way to easily sell and distribute their applications. As a result, there are now hundreds of thousands of applications out there for various platforms, many of which do incredible things with the hardware on the mobile device. Things that simply could not be done via a web application.

The rise of the app came on so quick and so strong that many began to ask if the app killed the web. This is certainly a reasonable question to ask. A native application has access to all that the device has to offer; the camera, the GPS, and yes, even the web. Apps are also designed to run on a mobile device. So, the text is easy to read, the controls are easy to use, and the user experience is generally much better than a web application.

Problems with Native Applications

While native applications have full access the the hardware and address many usability issues that web applications have on mobile devices, they introduce a new set of problems.

Some platforms charge program fees that must be paid to develop applications for the particular platform, even if you plan on creating a free app, or an app you never plan on releasing. While generally inexpensive, it is a new cost that web application developers have never had to deal with.

Deployment is more complicated for native applications than it is for web applications. Even though Apple’s App Store, Google’s Android Market, and other application marketplaces have made the distribution and installation of native applications much easier, it still does not compare to the ease of deployment of a web application. On the web, you have complete control over what you deploy, when you deploy it, and to whom you deploy it to. This is not the case with native applications, which can be subjected to drawn out, illogical review processes before being made available to the public. If you have a critical bug that needs fixing, or you’re trying to beat your closest competitor to market with some killer new feature, this process can be agonizing. And, even after publishing the latest version of your application to the marketplace, there is no way to force your users to upgrade. This could leave you supporting older, buggy versions of your application, or maintaining old services still in use by those old versions of the application.

If you charge for your application, distribution of that application is not free, or even cheap. Apple’s App Store, Google’s Android Market, and Palm’s App Store all take a 30% cut of the sale price of your application. Some may argue that this is a small price to pay for distribution to such a large audience. However, the audience is larger on the web, and distribution is piratically free.

The development of native applications is largely platform dependent. Programming languages and APIs vary significantly from platform to platform, making it practically impossible to develop a single application capable of running on multiple platforms. Cross platform development tools, such as PhoneGap and Rhomobile, address this issue by allowing you to develop native applications using HTML, Javascript, and CSS. However, these tools don’t address the other issues mentioned in this section. In addition, you also run the risk of some App stores outright banning applications not built using their tools (looking at you Apple). Though Apple has recently softened their stance on this issue, I would not rule out future restrictions.

A Mobile Web App in Native App’s Clothing

The sad part is, the majority of today’s apps don’t need to be native applications. They do nothing to utilize the features exclusive to native applications. Most of these apps simply fetch data from a web service and display it nicely to the user. Some take advantage of the GPS, or store data locally on the device. However, these apps could just as easily be mobile optimized web applications.

“Look and feel” is often cited as a reason to develop a native application instead of a mobile optimized web application. Though this argument certainly has its merits, there are plenty of options out there to help make a web application look and feel great on a mobile device. A bit of mobile optimized CSS (fluid layouts, properly sizing images, etc) can go a long way in terms of making a web application look awesome on a mobile device. And, there are projects out there, such as jQTouch, jQuery Mobile, and Sencha Touch that can help your web application look and feel more like a native application if that’s what you are looking for.

Web applications also have access to a few features that, just a short time ago, were only available to native applications. The device’s location is accessible via Javascript’s Geolocation API, eliminating the need to build a native application solely for access to the device’s GPS. Web applications also have access to persistent local storage on the mobile device via the HTML5 Web Storage API. While the Web Storage API falls short of a being a true database (it’s more like a hash, allowing you to store key/value pairs), it can go a long way in addressing the storage needs of most applications.

A good comparison between mobile apps and native apps can be found here.

Making the Web a Friendlier Place for Mobile Web Apps

The mobile web is growing by leaps and bounds, but much work is needed in order to make the web a friendlier place for mobile web applications. The W3C realizes this, and have started a Device APIs and Policy Working Group to create a specification that will allow web applications to access device hardware and services (contacts, calendar, camera, microphone, SMS, MMS, email, etc) in a standardized way. The specification is far from complete, and it will likely be quite some time before these APIs have been implemented by the various web browsers. But, the mere fact this is being worked on is a great sign for the future of mobile web applications.

There are non-technical hurdles preventing the web from being a more mobile friendly place as well.

First, browsing the web on a mobile device isn’t a very pleasant experience right now. Having “real” web browsers on mobile devices, such as WebKit, have gone a long way in fixing this. However, many sites are not optimized for mobile devices, making them difficult to use. I think this prevents the majority of people from browsing the web on their mobile device like they would on their desktop or laptop computer.

Second, we’ve been told for years that “There’s an app for that”. Personally, when I’m looking for a mobile application take care of some task, the first place I hit is the Android Market. Having one place, where apps are broken up into categories, and searchable, makes finding the right app for my needs incredibly easy. There is no such place for web applications. This used to be the case for desktop applications as well, but not anymore. The Ubuntu App Center, and now the Apple Mac Store, aim to serve the same purpose as the App Store or the Android Market, but for desktop computers instead of mobile devices. Perhaps it won’t be long before we see a categorized, searchable index for mobile web applications as well.


Opting to build a mobile optimized web application instead of a native application is not a new idea. However, the idea has been slow to catch on, due to some of the reasons I’ve outlined above.

Obviously, even after the Device APIs being worked on by the W3C have been implemented, there will always be a need for native applications. Games that need hardware accelerated graphics, or apps with complex user interaction will most likely stay native applications for the foreseeable future. But I hope that the other applications, especially the applications that are simply a front to a web service, are re-born as web applications at some point in the near future. For these apps, it’s time to come home.

Thoughts on Android Development

Now that Standup Timer has a few releases under its belt, I thought it would be a good time to reflect on my experience with the Android SDK, and Android development in general. But before I begin, I should mention a few points about my background, to help you understand my perspective.

First, Standup Timer was my first mobile app. Aside from a very small amount of time I’ve spent playing around with the Blackberry development kit (really too small to even mention), I have had no prior experience developing software for a mobile device. My background is largely web development and distributed applications development. Second, I have been doing Java development for quite some time, so I am very comfortable working in Java. Third, if you’re not familiar with Standup Timer, it is a very simple application. It only interacts with a few components of the Android platform, and only consists of a few screens. No GPS, no web, no multi-touch, etc. So, my tour of the Android SDK was far from complete.

Dealing with multiple devices

Supporting multiple screen sizes

The topic of supporting multiple screen sizes has been a popular one, especially when comparing Android development to iPhone development. Supporting multiple screen sizes in your application does add a little complexity to the development process, but for my app (and I’d imagine most apps), it is very manageable.

This issue did not take Google by surprise. They knew that if Android was to be successful, it would need support devices with a wide range of physical characteristics, including screen size. So, from the beginning, they made it possible for applications to support multiple screen sizes with little effort. The Android platform contains many features to help with this, including the ability to pre-scale images for phones with different resolutions, allowing you to specify your screen component sizes in density independent pixels (dips), and allowing you to easily center and stretch your components to fill the screen. These features, along with a set of best practices for supporting multiple screen sizes, are documented very well at

For applications that do not use the standard Android view components, or do custom graphics, it may be a different story. I have read blog posts from some Android game developers saying it is a larger issue, and some who say it is not. So, I’m not sure. However, for the vast majority of applications, the standard view components work just fine, making supporting multiple screen sizes a very manageable issue.

One thing that did bite me regarding multiple screen sizes is the fact that views will not scroll by default if they happen to flow off the screen. You need to anticipate this, and wrap any views that may flow off the screen with a ScrollView to enable scrolling behavior.

Supporting multiple devices

To me, this issue is much larger than the multiple screen size issue. Android is an open source project, which gives anybody the ability to modify the code however they wish. Google prevents carriers and cell phone manufacturers from abusing this by holding back a few key applications from the open source release, including the Android Market application. Without the Android Market application, phones would not have access to the 20,000 apps currently available for the Android platform.

However, phone manufacturers do tweak the platform to work for their specific hardware. Android 2.1 on one device is not necessarily the same as Android 2.1 on another device. For an example of this, compare 2.1 on the Motorola DROID with 2.1 on the Nexus One. These seemingly minor modifications can be very troublesome for application developers. The web has been flooded with reports of developers growing frustrated with the complexity matrix of Android versions and the exploding number of phones running them, all potentially containing their own tweaks to the platform. Browsing through the change logs of applications I have installed on my Motorola DROID, I can see that several apps have made changes to fix issues on specific devices.

This issue is forcing developers to not only test on every device they plan on supporting, but also to write device specific code to work around any known issues for a device. As Android continues to grow, this level of support will be unsustainable. Developing for a common platform should mean that your application will run fine on any device running that platform. But, because of these device specific tweaks, this is quickly turning out not to be the case for Android. I worry that if Google doesn’t find some way to control this, developers will continue to abandon the platform.

I have even run into what appear to be device related issues with Standup Timer, which is miniscule compared to the size and complexity some of the other apps available in the Android Market. Standup Timer uses an Android API that prevents the user’s screen from blacking out while a timer is in progress, letting you always see how much time is remaining for a meeting. Just the other day somebody left a comment in the Market indicating that this was not working on their device. So far, all of the other reviews have been positive, leading me to believe that this could be an issue with that user’s particular device. The commentator didn’t provide any information about the device they were using, or how they could be contacted. So, I’m not sure if I’ll ever be able to track down this issue. Even if I knew the device experiencing the issue, I’m not sure I would be able to help. Unless you have access the device in question, reproducing these issues is practically impossible. The Android simulator tool is great, but you cannot create a simulator for a specific Android device, running that device’s flavor of Android. You can only create simulators running the “generic” version of an Android release.


Application life cycle

The Android platform primarily communicates with an application through a series of life cycle events. The platform will let the application know when an activity (a screen) has been created, paused (lost focus), resumed (regained focus), etc. The life cycle events are easy to understand, and are specific enough so that I never need to examine the state of my application or the platform within one of these callbacks. The fact that a specific life cycle method was called tells you what state your application is in.

My largest complaint about how the platform manages an application is how it destroys and re-creates the activity (the object that backs the screen) when the phone rotates from portrait mode to landscape mode, or visa versa. It seems to me that this would best be handled by making the appropriate life cycle callbacks to the same activity instance, giving it a chance to redraw the screen. Instead, you are forced to save all of your activity’s state, and then reload it when the new activity instance takes over. Forgetting to save the state of a particular variable means that value will be lost when the phone is rotated. This was the source of several bugs when writing Standup Timer.

Android APIs

I have no major issues with the Android APIs. They seem complete (for what I needed), and most importantly, behaved as expected. The database API seems a bit archaic, especially in today’s age of sophisticated O/R mapping tools. But, at least I didn’t have to catch SQLException after each operation, like the JDBC API.

However, the lack of decent documentation for some of the APIs is a problem. There were a few instances where I was forced into using trial and error to determine the purpose of a method parameter. I feel this level of unclarity is unacceptable for a public API.

UI Creation

The Android SDK offers developers two methods for creating UI screens: programatically using Java code or declaratively using XML. I did not attempt the programatic approach, as it brought back too many nightmares of building UIs for Java applets. The XML approach to creating screen layouts, which is the recommended approach, is very straight forward. Java developers, especially those working in the “enterprise”, have grown to hate XML over the past few years, due to its verbosity and proliferation. But, I think Android’s use of it is very tasteful. At no point did I consider myself to be in XML-hell. Looking back on the final XML that declares my user interface, it doesn’t seem overly verbose or complicated.

I did however struggle at times to figure out how to get the UI to look exactly the way I wanted it. Again, this seems to be the result of poor documentation of the XML elements and their corresponding attributes. Some more complex examples in the sample code included in the SDK would have also helped.

If you keep your screens simple, and don’t display too much information on any given screen, then you shouldn’t have much trouble dealing with how that screen looks in portrait or landscape mode. Screens with a list of items, for example, will usually look just fine when viewed in either portrait or landscape mode. When in landscape mode, the user will just see a little more blank space in the list. For more complicated screens, the Android platform allows you to specify an alternate UI layout for landscape mode. This allows you to completely restructure the elements on a screen to deal with the the wider, shorter screen size without affecting how the screen looks in portrait mode. Given how I struggled to get the views to look exactly the way I wanted, I tried my best to avoid the need to specify an alternate layout file for landscape views. Only two of the screens in Standup Timer actually needed a landscape specific layout file.


The Android Debug Bridge (adb) is a nifty little tool that allows you to interact with an Android device or simulator from the command line. You can install/uninstall applications, interact with files on the device, or run a shell on the device. It also provides a series of commands that allow you to more easily create scripts to run on the device. Not only is this tool useful by itself, but it also enables the creation of sophisticated tools for Android development. Learning how to use adb is a wise investment of your time.

The Eclipse plugin

The Eclipse plugin for Android development is great. It provides tight integration between Eclipse and the Android SDK. Code completion is available for the Android APIs as well as the different types of XML files used by the Android platform. It has great support for Android resource files. You can easily start your application on a simulator with the click of a button, and running your tests is a breeze. I would not attempt to write an Android application without this plugin, or a similar plugin for a different IDE.

However, I did run into a few issues regarding how Eclipse interacts with the Android simulators. On more than a few occasions, when starting the application or running the tests, the Eclipse plugin started a simulator running a version of the Android platform that did not match my project settings (although, I have not completely ruled out user error here :) ). Also, the Eclipse plugin seems to have a few bugs around interacting with multiple simulators. adb allows you to specify the target device or simulator when issuing a command, which is useful when you have more than one simulator running at a time (which is almost always the case given the current state of the Android platform). However, the Eclipse plugin doesn’t always utilize this capability. Sometimes it will detect multiple simulators running, and ask you which one you’d like to target. Other times it will not. In addition to the simulator interaction issues, there are a few areas that could benefit from a bit of polish. The UI builders, for example, are difficult to work with. It became obvious very quickly that I would be better hand coding the XML for the UI than attempting to use the builders.


Simulators are awesome

The Android simulators are awesome. Once you have the proper versions of the SDK installed, it is trivial to create simulators with different screen sizes, different amounts of available storage, running different versions of the Android platform. And, as previously mentioned, adb is great for interacting with the simulators. While not perfect (you should always test your app on a real device before publishing it), they are pretty darn close.

The only thing missing, and I’m not sure how feasible this is, is the ability to create a simulator for a specific device. For example, if I know that my app is crashing on the Nexus One for some reason, I’d love to be able to create a Nexus One simulator, so I can find and fix the issue. Currently, debugging and fixing device specific issues is not possible without access to the device in question. I know some large mobile shops purchase the devices they plan on supporting, for testing purposes. And, services like Device Anywhere allow you virtual access to a physical device, which would satisfy this need. But these options, especially the first one, are expensive. A developer trying to fix a device specific issue in their free, non ad subsidized application will not have the resources for either of these options.

Automated (unit and functional) Testing

Automated testing on the Android platform is PAINFUL. It’s hard to decide where to even begin. First off, the tests provided with the sample applications in the SDK are very bare bones. Most of them simply assert that an activity has been created, and that’s it. If there was sufficient documentation describing how to write tests for you application, this wouldn’t be that big of a deal. But, there isn’t. Luckily, guys like Diego Torres Milano are writing blog posts and giving presentations in an attempt to fill this gaping hole in documentation. The slides from Diego’s presentation at Droidcon 2009 are a great place to start. Standup Timer, which is open source, also has a complete set of unit and functional tests for you to check out if you so desire.

Another pain point regarding automated tests for Android applications is that the tests cannot be run inside a standard Java Virtual Machine. The implementation of the APIs in the android.jar file provided with the SDK simply throw exceptions. That jar file is only meant for building your application, not running it. So, all tests must be run on the device (or in a simulator). This dramatically slows down the execution of the tests. One alternative proposed by a non-Android group inside of Google is to mock out all of the Android components using a mocking library, enabling the execution of the tests in a standard virtual machine. Although this would speed up the test execution, it comes with its own drawbacks. Mainly, you end up having to mock out a TON of stuff. I think that mocking out too many components significantly reduces the value of your tests. If you mock out everything, what are you really testing?

The SDK contains a few base classes that you can extend for certain types of tests. In particular, the SDK provides support for functional tests (the testing of a particular activity, or screen) and unit tests (the testing of some underlying support code). Writing unit tests is pretty straight forward. With a little bit of investigation and some trial and error, I was able to create a set of tests for my database layer, which will execute against a test version of the application’s database.

Functional tests were much more problematic. In addition to executing much slower than unit tests, they are also more difficult to write. For functional tests, you write code to perform the operations a user would be performing on their phone (entering text, pressing buttons, etc). The problem is that it is not very straight forward to perform these operations via code. It took me quite some time to figure out how to simply enter some text in a text area and press a button via code. Even when I thought I had functional testing figured out, there was still a use case I was unable to write a test for. Most of the issues revolve around gaining access to the components you wish to interact with. For a simple text box or button, it is very easy. You can simply fetch the view by its id, the same way you do in your application. However, once you start nesting components, it becomes much more complicated. I tried several different ways to invoke the context menu (the long press menu) of a list item, inside of a list, which is inside of a tab. None of them worked.

Instead of writing functional tests for activities, I found it much easier to test activities using the ActivityUnitTestCase class with a mocked out instance of the activity. Test classes that extend ActivityUnitTestCase don’t have as much as access to the platform as functional tests. Several API methods will throw exceptions if called from within a ActivityUnitTestCase, and other API methods simply do nothing. However, this can be addressed with some simple tools that should be in every developers toolbox: mocking and stubbing. It is trivial to contain a method call that would throw an exception during testing within a method of its own. This method can then be overridden by a mock implementation of the activity. The mock can then optionally set a flag when the method is called, so the test can verify that some action was performed. One place I do this is where the activity under test tries to start another activity. Calling startActivity from within a ActivityUnitTestCase does nothing. So, I placed the call to startActivity by itself in a protected method, overrode that method in the mock activity class, set a flag in the mock method implementation, and checked to see if that flag was set in the test case to verify that the activity was started.


Publishing to the Android Market

Publishing an application to the Android market could not be any easier. The process is very well documented on the Android developers website, and the Eclipse plugin makes creating and signing an installation package a point and click operation.

A fee of $25 is required to create a Android Developers account. This account gives you the ability to upload your application to the Android Market using the Android Developers website. Once published, the application can immediately be found in the Android Market. There is no approval process. Updating your application is just as easy. Simply upload the new version of your application, and it is available in the Android Market immediately.

It should be noted that there is no fee to install the application on your phone.


Android is a great platform. It is feature rich, and developer friendly. The devices that run it are powerful and easy to use. I also love the fact that it is built on open source technology, and that Google, for the most part, has continued this tradition of openness.

But, the platform is not without problems. Most of my complaints here are minor, and are very addressable. Android is still a young platform, so there is plenty of room to improve. What worries me most about the future of the Android platform is the complexity matrix I talk about in the Supporting Multiple Devices section.

Android was created to be a common platform for mobile application development. A platform where application developers could write a single application capable of running on numerous devices. However, this dream is at risk of becoming just that, a dream. Unless Google can find a way to minimize the impact of device specific issues, it risks losing more and more Android developers. Last year it was already known that 2010 was going to be a big year for Android. With several new devices slated to hit the market, industry analysts are expecting its market share to jump considerably. However, if each new device that hits the market brings with it its own set of device specific quirks, this could also cause the Android development community to quickly erode. Applications are a very large part of the mobile experience today, and they will continue to be in the future. But, without a development community, there will be no applications.

I really hope Google finds a way to address this very serious issue.

Standup Timer 1.1 Released

Version 1.1 of Standup Timer has just been released. This new version stores statistics for your stand-up meetings on a per-team basis. Simply create one or more teams using the new Teams menu option, then specify the team holding the meeting when starting the timer. To view statistics for a given team, use the Teams menu option to pull up the list of teams, and select the team you would like to see statistics for. The Stats tab will display the average statistics for that team across all of its meetings. For a list of the meetings that team has held, click on the Meetings tab. Finally, to see statistics for a specific meeting, simply select the meeting from the list of meetings.

Standup Timer is free and open source. The source code can be found at Standup Timer can be found in the Android Market.

My First Android App – Standup Timer

iconPutting my brand new Motorola DROID to work, I just completed my first Android application, which I’m calling Standup Timer.

Standup Timer is a very simple application that helps keep your stand-up meetings focused, and on track. I’ve been participating in stand-up meetings of one form or another for a few years now. One thing that is constantly an issue with stand-up meetings is that they often run longer than they are supposed to. Instead of simply stating their status and moving on, participants will often start to ramble, or engage in conversations with other members of the team. Those who practice any form of the Agile software development methodology know that the value of stand-up meetings drops considerably if the meeting is constantly allowed to overflow its time constraints.

So, I created an app for that :) Standup Timer helps to keep your stand-up meetings on track by allotting each participant an equal share of time, and letting participants know when they are about to exceed, or have exceeded their time. The notification comes in the form of a bell ring for the warning, and an air horn when the time has run out. If any time is left after all participants have presented their status, then Standup Timer will keep the clock ticking, so the remaining meeting time can be used for an open discussion.

Standup Timer is easy to use. Simply provide the number of participants in the meeting, the length of the meeting, and press Start to start the timer. On the timer screen, press Next when a participant is finished presenting their status to reset the timer for the next participant. When the meeting is over, press Finished. Standup Timer will remember the number of participants and meeting length from the last time you used it. It also allows you to enable/disable sounds, and to specify when (how many seconds left in their share of time) to warn participants that they are about to exceed their share of time.

Standup Timer is free and open source. You can find the application in the Android Market, and the source code on GitHub at

What Will It Take To Dethrone The iPhone?

The mobile industry is exploding. In just a few short years, everybody will have a smart phone. A tiny, internet connected, mini computer right in their pocket. As each month passes, we learn more and more about what the future of this industry holds, and what the mobile handset landscape will look like. If one thing is for certain, it’s that nothing is for certain.


As it stands right now, Apple is king with consumers. Though not the first ones to market with an internet connected mobile device (the Blackberry has been around for a long time, and still holds the majority of the smartphone market share), Apple appears to be the first to really understand what the average, non-corporate consumer wants. A true mini computer. An open device that can play music, run applications, take photos, and provide a pleasant web browsing experience. And they did it in true Apple fashion, making the device extremely easy to use. As a result, the iPhone has become extremely popular with consumers, and is widely considered “the device to have”.

With the majority of people still without a smartphone, much of the market remains up for grabs. Apple’s competitors are scrambling to catch up, trying to ensure that they they get a piece of the pie. But, one very important question lingers. What can Apple’s competitors offer that would give the average consumer a reason to buy their device instead of buying an iPhone? To me, the reasons are few, and becoming fewer.

(I’d love to hear your reasons in the comments. So please, chime in.)

A comparable feature set

This pretty much goes without saying. Any challenger to the iPhone crown must offer similar features to that of the iPhone. It is very unlikely that a competing device will lure anybody away from the iPhone if it is missing a feature that is now expected to be there. The device must be capable of running apps, taking photos, playing music, etc, for it even to be considered.

A better network

AT&T’s network leaves much to be desired. Having never been an AT&T customer, I can only relay the opinions of my friends and family who are AT&T customers. However, their opinions are one in the same. I’ve not heard a single word of praise when it comes to AT&T’s network. All of my friends and family with iPhones have expressed frustration that the device they love is frequently crippled by a network that is spotty and congested.

It’s no secret that Apple has an exclusive agreement with AT&T, and that agreement has an expiration date. Rumors have been circulating about a jump to another carrier, possibly Verizon, sometime next year. The more wireless carriers offering the iPhone, the less valid of a reason this will become for not purchasing one.

A comparable application ecosystem

Competing devices will need to have an application ecosystem that is at least comparable to the iPhone’s. This is no small task. There are over 100,000 applications in the App Store. Sure, several offer the same functionality, and many are of very poor quality. However, nobody can argue with Apple’s tag line of “There’s a app for that”. There really is an application, in most cases many, for everything you could possibly want to do with your iPhone.


Given their head start, beating Apple at this game will not be easy. Google’s Android OS currently stands the best chance of challenging Apple on this front, with over 10,000 applications already available. The Android OS is open, and capable of running on hardware from any manufacturer. In addition, applications written for Android are capable of running on any device that runs the OS (for the most part). Next year is going to be a big one for Android, with several new devices coming to market from many different manufacturers. Some analysts are even predicting that the number of Android devices in the hands of consumers will surpass the number of iPhones by 2012. This will no doubt attract more application developers to the platform.

However, Android has its own set of challenges awaiting. The fact that manufacturers are free to run Android on devices with very different hardware specifications (screen size, input controls, etc) poses a major challenge for application developers. Perhaps the risk of rendering thousands of existing Android applications useless by releasing a device with dramatically different hardware specs will be enough to convince manufacturers not to do it. Perhaps Google will provide a set of Android APIs that can help application developers deal with this issue. Perhaps a set of best practices will emerge as a guide for developers looking to tackle this issue. Perhaps we’ll see something similar to the PC application market in the mid-late 90’s (and the Blackberry application market today), where only certain devices will be capable of running certain applications. Only time will tell if these issues will prevent the development of the Android application ecosystem.

A killer feature

One wild card that is always in play is the killer feature. Apple’s competitors are only one, innovative, killer feature away from stealing the spotlight for themselves. By “killer feature”, I mean a feature so awesome that when you see it in action, you say to yourself, “I need one of those!”.


Version 2.0 of the Android OS took a stab at this with the introduction of Google Maps Navigation. A fantastic feature, Google Maps Navigation morphs your mobile device into a fully functional GPS unit, complete with a synthesized voice telling you where to go, real time traffic information, and several map overlays showing you the location of everything from ATMs to gas stations. But, is this a killer feature? Frankly, I’m not sure. But, its announcement was enough to cause a significant drop in the stock price of traditional GPS manufacturers, and it certainly has potential.

An incredibly easy to use device

Making devices that are intuitive and easy to use has always been one of Apple’s strengths. Look no further than the iPod for an example of this. Competing devices will need to be as easy to use as the iPhone is to appeal to the average consumer.

How do I get my music onto the device? How to I get the photos I take off? These operations should be simple and intuitive. Motorola’s new Android 2.0 device, the DROID, is seriously lacking in this area. Several steps are required to store data on or pull data off of the device:

  • Attach the device to your computer
  • Use the device’s menu system to instruct it to mount itself as an external drive
  • Locate the files on your hard drive that you would like to store on the device
  • Copy and paste the files from your hard drive onto the device
  • Unmount the device

For the iPhone, the list of steps is much smaller.

  • Attach the device to your computer, and let iTunes do the rest

Are the steps required to store data on the DROID too much to handle for an experienced computer user. No, of course not. But, there is still a large percentage of people out there who would struggle with completing those tasks. Believe me, I know. Many are family and friends of mine who I help complete “simple” tasks on their computers all of the time. These people make up a significant portion of the market. If you want them to buy your device, then you have to make it stupid simple to use.


Apple has set the bar high with the iPhone, very high. While I can think of several reasons why developers and techies would prefer a different device, I can’t think of many reasons why the average consumer would. And, there are a lot more average consumers than there are geeks.

But make no mistake, Apple’s competitors have the iPhone in their sights. The tide can shift very quickly in this market, especially since most people get a new phone every couple of years. Will the iPhone challengers be able make a dent in the iPhone’s market share? Or, will the iPhone be the de-facto standard for smart phones? Only time will tell.