For example, 48 percent of U.S. smartphones run Android. So unless an enterprise is comfortable alienating 1 out of every 2employees or customers, its developers have to create apps for at least iOS, BlackBerry or Windows Mobile. If that enterprise is multinational, then its developers can add Symbian to their to-do list.
“We have European customers that say: ‘We know Symbian is going to die. It might take five years, but in the meantime, a large percentage of our workers have Symbian phones,’” says Adam Blum, CEO of Rhomobile, which provides development tools.
If that weren’t enough work for developers, there’s also fragmentation within some operating systems. For example, each Android smartphone vendor often has a unique implementation of the OS, while differences in screen size and resolution create additional variables that affect an app’s user experience.
Web or Native?
Some developers sidestep fragmentation by using “Web services” or “Web apps,” which consists of taking the phone’s browser and stripping off the user interface so it appears to be an app. One drawback is that the browser isn’t always able to access phone hardware, such as the GPS radio or accelerometer, thus limiting what this pseudo app can do.
“This is a very valid approach if you do not need to do anything fancy,” says Vince Chavy, product management director at RADVISION, a videoconferencing vendor whose portfolio includes endpoint apps that run on Android and iOS devices. “It is easy, and it is quite amazing what you can do with HTML5 and CSS nowadays.”
Some enterprises like Web apps because they leverage their developers’ existing skills. “What we always hear is, ‘Because my developers have Web skills, you get all that productivity and affordability across all phones,’” says Blum.
The alternative is a “native app,” whose benefits include better performance because the software doesn’t have to pull everything from the Web. If the target audience is made up of customers rather than employees, then another benefit is that native apps can be distributed through app stores.
“You will be closer to the look and feel of the device,” says Chavy. “You are only limited by your imagination and the OS SDK APIs.”
Write Once, Run Many
The big downside to native apps is that code for one OS version can’t be reused to create other OS versions. The corollary to that requirement is that if the enterprise doesn’t have developers versed in all of the major codes, it has to find them, which increases costs and lead time. “You need a different code base for iOS and Android,” says Chavy. “You need to find Objective C developers for your IOS client and Java/Android developers for the Android client. Those are tough to find!”
Hence the growing selection of tools that enable cross-platform app development, such as MoSync , PhoneGap and Rhodes .
“You develop in C/C++,” says Henrik von Schoultz, MoSync co-founder and vice president of marketing and sales. “We will later also use other languages, like JavaScript and Lua. The developer uses MoSync APIs, and at build time we use an intermediate language and have profiles for your target devices. We compile native to the OS you want to target.
“If a feature does not exist on an OS, the system tries to handle that. For example, if the target device doesn’t have GPS, you may use positioning from the cell towers.”
So how much time could a developer reasonably expect to save by using MoSync versus developing from scratch for each OS? It depends, but in one case, a developer went from Symbian to Android in about four hours . “If you have an app with loads of logic and not so much UI, you can save up to 80 percent,” says von Schoultz. “But if it’s a very UI-intense app, you may save maybe 30 percent.”
PhoneGap, meanwhile, emphasizes the importance of having both apps and a mobile-friendly website.
“They can use largely the same code in their mobile website as their native app in PhoneGap because we’re just running HTML and JavaScript right there,” says Andre Charland, president and co-founder of Nitobi, PhoneGap’s creator. “We’re compliant with W3C APIs. You’re also future-proofing your app because as the mobile browsers evolve, you can take your PhoneGap applications and push more of that into the browser, while still augmenting the native app experience with native code via plug-ins from PhoneGap.”
One Size Doesn’t Fit All
Tablets and smartphones come in an ever-increasing range of screen sizes and resolutions. As a result, developers also have to ensure that their app looks and works just as well on a 3.5-inch display as a 4.3-inch display, or on both an Android phone and an Android tablet.
“The first decision is if you want the same GUI on the phone and on the tablet,” says Chavy. “Some developers decide to have the same UX. In that case, they just make sure that when they design the GUI, it can resize nicely by deciding on which area resizes and by setting proper anchors on the objects.
The catch is that consumers and business users increasingly expect tablet apps to take advantage of the extra screen space.
“For example, in our SCOPIA Mobile application, on the phone, you can see the video or the presentation, and not both at the same time,” says Chavy. “On the tablet, since you have a bigger screen, we have layouts with both the video and the presentation.”