November 21, 2012 1 Comment
The must have gift for Christmas 2012, according to many sources, is a tablet. For the average consumer, there is no need to have a desktop or notebook to accomplish day to day computing. Microsoft is aware of the trend and created Windows 8 with a focus on tablets (obvious when examining the very touch friendly user interface). In addition, smart phone sales are expected to top 600 million this year, up from almost half a million in 2011.
Looking at various industries, there is a push to enable workers to accomplish work quicker without the need to be tied to a computer. Gartner sees both mobile device battles (who will win this war) and mobile applications as two of the top trends for 2013.
What does this mean for the developer (or IT manager or executive)? You cannot ignore mobile application development much longer. But where do you place your chips? This article runs through the choices for application development for the mobile space and the options available.
The Mobile Space
As of today, there is a plethora of vendors in the mobile space and one clear winner: Apple iOS. Apple currently controls about 65% of the mobile traffic, with Android in a distant second with about 20%. Other players who have at least a blip on the screen are Java ME, Symbian, Blackberry and Windows Phone. Of these distant runners, only Microsoft is on any type of uphill trend and this trend has been rather anemic thus far. But Microsoft has unified its OS look and feel across all platforms with Windows 8 and Windows Phone 8, so I would not count them out of the game.
Which should you spend time learning and developing for? It is hard to argue against iOS, as Apple has the largest share of the mobile market right now. Even if you are not aiming for mobile phones, there is a good reason to consider iPad for your line of business applications. But it is also hard to ignore Android, as the sales are definitely on the rise. I would definitely invest in both iOS and Android in a mobile strategy.
Then there is Windows Phone. While the jury is still out, and many have decided to ignore the platform for now, it is hard to bet against a giant that has already set up a store, is using Apple’s strategy of controlling hardware (fewer bugs due to fragmented hardware?) and is leveraging .NET as for development (.NET skills (esp. C#) are currently one of the most sought after skills in job ads). Christmas season 2012 will give a hint whether Microsoft is a good ship to tie anchor to, but considering the ability of leveraging code across multiple application types, it may be a cheaper road to travel, even if the numbers are not that big (more about this in a minute).
Application Development Strategies
Assuming you would like to write for more than one platform, there are numerous strategies to choose from. What you choose depends on your goals. The following sections cover the three strategies currently available for development for mobile.
- Write for Each Platform
- Write Once, Run Everywhere
- Write Once, Wrap Everywhere
- Use Native Wrappers for Connected Functionality
Write for Each Platform
This is the most tedious approach, but gives you the power to take advantage of features of each platform. You end up with truly native applications, which is a plus, but end up spending more money on development. Despite the cost, many companies have adopted this strategy, as it yields a better UI experience. Overall, this is the best strategy if you need the richest application on each platform and want it to run completely on the device.
With a good design (planning is not optional), you can reduce the time spent developing each platform, but you will still end up spending more with this option. On the positive, there are numerous applications, primarily games, that require a connection that have people giving them horrible ratings due to the always connected state. These apps are primarily on not always connected platforms, like the Nook, but phones do fall out of service from time to time.
Write Once, Run Everywhere
Just as Java promised in the 90s, there are some vendors who have embraced the idea of creating tools that allow you to write a single code base and compile it for many different platforms. An example of this approach is found in Antenna Software, which a client used last year.
The positive side of this type of paradigm is you only write code once and then deploy to the platforms available. You also end up with native applications, which is useful in a disconnected scenario (similar to the write for each platform strategy). The downside is you generally have to learn a new language and may have to work with a limited set of features (although the vendor will continue to add features to improve their platform). You will also have a limited set of platforms to choose from, as compilers have to be created for each platform.
I am a bit skeptical with this approach, having been burned by Java’s promise years ago. While Java touted “write once, run everywhere”, the reality was more likely to be “write once, debug everywhere”, due to the great differences in platforms. In all likelihood, this is a decent route for some, but consider the learning curve for the new language, and that you may have to tweak the application for each platform.
Write Once, Wrap Everywhere
While this sounds like the same approach as the last section, it is subtly different. The approach here is to use HTML5 and use the native browser on the device. Essentially, you are writing a web application that will run locally on the phone.
This means you can only create an application as rich as the HTML5 capabilities of the phone(s) you are targeting. This is not a major downside, as HTML5 is very rich. The app itself, wraps the browser, so you will have the ability to access the native features of the device.
This is the approach taken by PhoneGap, an open source project that was acquired by Adobe. As of the end of 2011, the following platforms were supported with PhoneGap: iOS, Android, Symbian, Blackberry, WebOS, WP7 and Samsung Bada. It also appears a few commercial vendors have gotten into the game.
Please note that while HTML5 shows a lot of promise, there are some inconsistencies in platforms, so you have to know the limitations of the platform to end up with the best looking application. As with the last option, you will likely have to tweak applications for each platform. To get past the inconsistencies, it is useful to have a development tool that helps you design once and deploy across all platforms. One tool that shows a lot of promise for this type of development is Telerik’s Kendo UI (realize you still have to package with something like PhoneGap to get the native wrappers).
Use Native Wrappers for Connected Functionality
This might be better labeled “write a web application in HTML5” and connect to it via a native wrapper. This is the approach taken by Orubase, by Syncfusion. Native wrappers are created for different platforms and the application itself runs on your servers. Orubase also leverages ASP.NET MVC for the backend, which should make it attractive to .NET shops.
One downside is the connected nature of the application, meaning you need to connect to the web application for full functionality. This is only a partial downside, however, as vendors are instituting local storage solutions. You also have to consider line of business applications, which benefit from an “always on” connection (not completely always on using the web paradigm, which is inherently stateless, but that is a topic for another day).
An Apple Caveat
You can only develop for iOS on Apple. Apple has decided not to make the SDK and development tools available on Windows. On the positive side, it gives Apple a lot of control. On the negative, it means you have to buy a Mac to develop for iPads and iPhones. This means you will need a Mac to develop for iOS. With some of the strategies above, you might be able to use an iPhone emulator instead.
Which Strategy to Choose?
It really depends on what you are developing. For games, I would recommend native on each platform, despite the costs. Gaming is a fickle market and a bad game dies rather quickly. The same is true for many consumer applications or any application that focuses solely on user data on a single device.
For internal applications and many line of business applications, the always connected scenario works well. The app looks native, due to the wrapper, but the functionality is maintained on the server. One potential caveat here is how different mobile platforms handle the sites. If you end up having to create separate sites for each platform, this could be a nightmare, but it is still a great option for reducing costs and still getting mobile applications out to your internal users and partners.
As a compromise position, if compromise is the right word, the creation of native applications in HTML5 shows a lot of promise. The standards are still in the infant stage, but the mobile space has adopted them faster than the desktop/notebook space, so there is a lot of promise in this space. If you are already leveraging HTML5 in your organization, this could be a good solution.
The write once, run everywhere option is also promising, especially if you would also like to offload some of the work to the vendor. I am not sure I can accept the downside of the learning curve to program on these tools, but vendors like Antenna also have other products, like mobile gateways, that still make them a good option for many business scenarios.
Peace and Grace,