In the week preceding July 4, Microsoft killed the Kin and T-Mobile killed the Sidekick. And sometime soon, other well-known smartphones will fade away, such as the iPhone 3GS and the original Motorola Droid.
This in itself isn’t surprising. After all, smartphones have stepped onto a treadmill of constant change as a way to keep sales up and customers interested. Meanwhile, technology is evolving at a breathtaking pace, and that is also helping to drive the rapid turnover of smartphone models.
You can already see those changes taking place. Palm, now that it’s owned by HP, is clearing out its inventory of smartphones by simply giving them away for the price of a two-year contract. Apple has reduced the price of the iPhone 3GS to $99. You can get a Droid on a two-for-one deal from Verizon Wireless. Again, no surprises here. All of these devices have had their time in the sun, and that time is past.
But the risk to an enterprise comes when this constant churn doesn’t enter into your planning. If you base your enterprise smartphone use around a specific platform, for example by developing applications for a specific version of a device or even a specific level of operating system, your mobile application strategy will go down in flames in months, if not weeks. Even deciding on a single class of smartphone, such as the iPhone or an Android device, is fraught with danger. It only takes some mandatory upgrade to break your application and put you out of business.
This means that while it might be tempting to take advantage of the iPhone 4’s new multitasking operating environment and create a custom application for your company, you should think twice. The same is true before you build something for Android 2.2 or Palm’s WebOS. The future of devices running all these operating systems is unclear and, one way or the other, these platforms will certainly change. You need to be ready to deal with that change.
Of course, this doesn’t mean that you have to steer clear of applications that work for your business and also run on smartphones. What you need to do is avoid depending on any one single platform.
Build Web Apps, Not Smartphone Apps
If you built an application for the iPhone 4, for example, and you needed constant access to a data source, how would you handle the iPhone’s reception problems? Or how would you handle the demise of the many Android platforms that will take place in the next few months as new versions are launched?
In reality, there are two approaches you can take to stay out of trouble. The first is to support more than one smartphone environment. Sure, it’s kind of a pain to develop for both the iPhone and for Android devices, and it’s more of a pain if you also have to develop for WebOS and for BlackBerry devices. But the goal is to make sure that you can use your smartphone for the benefit of your enterprise. That means making sure that your important mobile business applications will always run, even if it requires supporting multiple models.
Perhaps a better approach, however, is to support your enterprise’s needs with Web-based applications. You’ll still have to deal with issues such as reliable reception, but at least you won’t have to write a new application every time a hardware platform gets upgraded.
Most smartphones support fairly decent Web browsers these days, and as long as you can detect what browser you’re serving, you can make a point of avoiding things that don’t work, such as Flash for users with iPhones. The only real limitations then are the small screen size of some devices and delays in delivering multimedia information in areas with poor reception, and those issues can be handled with proper design.
But it’s important to note that the best plan is not to decide that you’re going to support a single platform, and work from there. Single platforms have a way of going away with little warning. While some smartphone companies are better than others when it comes to helping you with a transition, your real goal is to make application transitions on your own schedule, not on Apple’s, Motorola’s or Palm’s.
To ensure application stability and continuity, you have to start with the assumption that the smartphone you’re currently designing your applications for will probably not exist by the time you’ve finished. So instead of locking yourself into a single set of features, plan for a steady and rapid pace of change so you can be ready when it happens.