This article appeared in the Jan/Feb 2012 issue of Better Software magazine
Developing software for mobile apps requires a different mindset from developing for computers. Some concepts transfer directly, but there are many device-related challenges managers must overcome. In part one of this two-part series on mobile challenges, Jonathan Kohl addresses some of the project factors managers should take into account during mobile application development.
If you are new to developing mobile apps and you are in a project management or leadership role, you might be in for some surprises. If you are used to developing software for computers, you probably are tempted to take the same approach that you have with other projects. Some concepts transfer directly, but mobile projects have some unique challenges of which you need to be aware.
While device support may not be the decision of a project manager, it affects you, and you’ll want to be aware that there is a combinatorial explosion of mobile devices out there. It is vital to have a strategy to manage this, so you don’t end up in a situation where it will be impossible to meet your public claims.
Take popular smartphone application platforms, for example: Apple iOS, Android, Blackberry, Windows Phone 7, Symbian, Meego, and Bada, just to name a few. Within each of those platforms, there are several models of hardware. For each hardware offering, there are multiple firmware versions. Also, since a smartphone is a communication device, there are contracts with different carriers and data plans with different options. If yours is a client-server application—i.e., it needs to communicate to a remote server to operate—then you also need to consider if you need to use secure or insecure communication protocols. Now, imagine a blanket product strategy like we use for computers: “We’ll support iOS version 3 and up” or “We’ll support all Windows Phone 7 devices.” This may sound reasonable, but if you map out all the versions of everything listed above—platform, hardware, firmware, carrier, network, and security—you are looking at dozens or hundreds of combinations with which to test, rather than the handful you consider with a non-mobile platform.
With computer software, there are a few operating systems and OS upgrades to consider, and we don’t really pay attention to hardware that much. But in mobile, the devices are smaller and less powerful than computers, which can have an impact on how your software works. A less-powerful device with less memory than another can have a big impact on how your app operates, particularly if you aren’t paying attention to memory and other resource management.
In some cases, different hardware versions are different products that provide similar functionality, as is the case with Apple iOS products. There are different hardware versions for iPod Touch, iPhone, and iPad. All of these are incredibly popular, and if you support one, it makes a lot of sense to support the others. In other cases, such as the Android and Windows Phone 7 worlds, different manufacturers supply the hardware that supports the OS. When Windows Phone 7 was released on November 8, there were around ten hardware devices that supported it. Sometimes hardware is rushed to market, and some versions are more reliable than others.
Firmware and carrier settings often get pushed down to devices, so backward compatibility is difficult to maintain without a way to store and update multiple versions in the test lab. There are a lot of updates to keep track of if you want to use a blanket statement on device support. It’s a good idea to mitigate this by being cautious about what you say you will support. For example, if you already have a web application, you may choose to target web browser support for most popular smart phone platforms and limit application development to one or two smart phone platforms.