Will a Mobile OS Update Break Your Apps?

It’s one of the biggest headaches in mobile app development: The operating system (OS) vendor issues an update that immediately renders some apps partly or completely inoperable, sending developers scrambling to issue their own updates to fix the problem. For instance, remember when Android 2.3.3 broke Netflix’s app in June, as iOS 5 did to The Economist’s in October? These examples show how breakage can potentially affect revenue -- especially when it involves an app that’s connected to a fee-based service. In the case of enterprise apps, breakage can also have a bottom-line impact by reducing productivity and inundating the helpdesk.

Tsahi Levent-Levi, CTO of the technology business unit at videoconferencing vendor RADVISION, has spent the past few years trying to head off breakage. His company’s product portfolio includes an app that turns iOS tablets and smartphones into endpoints. With an Android version imminent, his job is about to get even more challenging. Levent-Levi recently spoke with Intelligence in Software about why app breakage is so widespread and so difficult to avoid.

Q: What exactly causes apps to break?

Tsahi Levent-Levi: The first thing to understand is that when you have a mobile platform, usually you have two sets of APIs available to you. The first set is the one that’s published and documented. The other is one that you need to use at times, and this is undocumented. When it is not documented or not part of the official API, it means that the OS vendor might and will change it over time to fit its needs.

For example, we’re trying to reach the best frame rate and resolution possible. To do that well means you need to work at the chip level. So you go into the Android OS NDK, where you write C code and not Java code. Then you go one step lower to access the physical APIs and undocumented stuff of the system level, which is where the chipset vendors are doing some of the work.

Even a different chip from the same vendor or a newer chip from the same vendor is not going to work in the same way. Or the ROM used by a specific handset with the same chip is going to be different from the ROM you get from another one, and the APIs are going to be different as well.

Q: So to reduce the chances that their app will break, developers need to keep an eye on not only what OS vendors are doing, but also what chipset and handset vendors are doing.

T.L.: Yes, and it depends on what your application is doing. If you’d like to do complex video things, then you need to go to this deep level.

I’ll give you an example. With Android, I think it was version 2.2 of those handsets that had no front-facing camera. Then iPhone 4 came out with FaceTime, and the first thing that Android handset manufacturers did was add a front-facing camera. The problem with that was that there were no APIs that allowed you to select a camera for Android. If you really wanted to access that front-facing camera, you had to use APIs that were specific to that handset. When 2.3 came out, this got fixed because they added APIs to select a camera.

Platforms progress very fast today because there’s a lot of innovation in the area of applications. Additional APIs are being added by the OS vendors, and they sometimes replace, override or add functionality that wasn’t there before. And sometimes you get APIs from the handset vendor or chipset vendor and not from the OS itself. So there is a variance in the different APIs that you can use or should be using.

If the only thing you’re doing is going to a website to get some information and displaying it on the screen, there isn’t going to be any problem. But take streaming video, for example. Each chipset has a different type of decoder and a bit different behavior than another. This is causing problems.

It’s also something caused by Google itself. When Google came out with Android, the media system that they based everything on was OpenCORE. At one point -- I don’t remember if it was 2.1, 2.2 or 2.3 -- they decided to replace it with something totally different. This meant that all of the applications that used anything related to media required a rewrite or got broken. The new interface is called Stagefright, and there are rumors that this is going to change in the future as well.

Q: With so many vendor implementations and thus so many variables, is it realistic for developers to test their app on every model of Android or iOS device? Or should they focus on testing, say, the 25 most widely sold Android smartphones because those are the majority of the installed base? You can read more about smartphones and mobile app safety here.

T.L.: You start with the devices that most interest you, and then you enhance it because you get problem reports from customers. Today, for example, I got a Samsung Galaxy S. When I go to install some applications from the Android Market, it will tell me that I cannot do it because my phone doesn’t support it. That’s a way that Google is trying to deal with it, but it doesn’t always work because of the amount of variance.

The way it should be done in terms of the developer, you should first start from the highest level of instruction that you can in order to build your application. The next step would be to go for a third-party developer framework like Appcelerator, which is a framework that allows you to build applications using HTML5 and Javascript CSS. You take the application that you build there, and they compile it and make an Android or an iOS application. If you can put your application in such a scheme, it means you will run on the most amount of handsets to begin with because these types of frameworks are built for this purpose.

If you can’t do that, then you’ll probably need to go for doing the most amount of stuff that you can do in Android on the software development kit (SDK) level. If that isn’t enough, then you go down into the native development kit (NDK) level. And if that isn’t enough, then you need to go further down into the undocumented systems drivers and such. And you build the application in a way that the lower you go, the less code you have there.

Mitigate Mobile Cross-platform Headaches

Android is now the most widely used mobile operating system in both the Unites States  and the world , according to the research firms Canalys and Nielsen. But behind that news lurk a lot of headaches for enterprise developers.

For example, 36 percent of U.S. smartphones run Android. So unless an enterprise is comfortable alienating 2 out of every 3 employees 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 MoSynch , 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 Java Script 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 Java Script 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.”

Need more details about mobile cross-platform development tools? Check out this article on Mashable.

Nice Gesture, But What Does It Mean?

One step forward, two steps back. That’s how Don Norman describes today’s gesture-based user interfaces (UIs) for smartphones, tablets and a growing assortment of other devices.

Named one of the world’s 27 most influential designers by Business Week, Norman laments the lack of standards, which have created a world where a finger-swipe on one device often doesn’t have the same effect on another. That inconsistency often makes using gesture-based UIs as much fun as folding a fitted sheet. Norman recently spoke to us about this and more from South Korea, where he’s distinguished visiting professor in the Korea Advanced Institute of Science and Technology’s Department of Industrial Design.

Q: Your colleagues from the Nielsen Norman Group recently did usability tests on Apple’s iPad: “The first crop of iPad apps revived memories of Web designs from 1993, when Mosaic first introduced the image map that made it possible for any part of any picture to become a UI element. As a result, graphic designers went wild -- anything they could draw could be a UI, whether it made sense or not. It’s the same with iPad apps -- anything you can show and touch can be a UI on this device. There are no standards and no expectations.” Yet tablet and smartphone sales remain brisk.

A: It’s confusing and difficult for people. On the other hand, it’s so engaging and so much fun, that it in many ways compensates for its difficulties.

I’m about to give a series of talks about the way the field has evolved. In the beginning, we were so delighted with the technology. With the passage of time, we’ve come to take understandability, usability and function for granted. What we want now is a good experience, some fun and delight.

That’s where Apple has transformed itself as a company. It really is about experience, fun, delight and entertainment. That’s what the iPhone did: By this whole new way of interacting with strokes and gestures, it was so delightful and different.

Q: In “Gestural Interfaces: A Step Backwards in Usability,” you and Jakob Nielsen identified two root causes for gesture UI inconsistencies: a lack of industry guidelines and “the misguided insistence by companies (e.g., Apple and Google) to ignore established conventions and establish ill-conceived new ones.” Will we ever have standards for gesture UIs?

A: There will be gestures that Apple will patent and refuse to let Microsoft and Google use. All of the companies will have competing methods that will just confuse the hell out of people. But we had that in the beginning of computers too.

When I was at Apple as vice president of the Advanced Technology Group in the ’90s, I was fighting hard for standards. We had this wonderful meeting, and we got all of the major companies together to argue for standards: Sun, IBM, Apple. Microsoft walks in and says, “This meeting is unnecessary. If you want standards, just use Microsoft’s.” That’s Apple’s attitude today.

Q: One downside of standards -- whether it’s a UI or a wireless technology -- is that they sometimes don’t leave companies with many opportunities for market differentiation, aside from price.

A: Every Android phone basically looks the same. So how do you compete in a world like that, where if you really follow Google’s guidelines, you can’t distinguish LG from Samsung from HTC from Motorola? Nobody wants to compete on price. That’s death.

With early technologies, as people are learning, it’s understandable that we don’t have standards and that sometimes different applications don’t follow the same rules. Jakob and I wrote our joint piece to be critical yet friendly, to say that we thought gestures and the new interfaces were exciting, powerful, adding a lot to our experience, and that this early confusion can be overcome. This confusion is compounded by the lack of differentiation among the vendors, who are desperate to do anything different, and the companies don’t wish to cooperate.

Q: For now, consumers and business users seem to be willing to put up with those inconsistencies, judging by how many iOS and Android apps and devices there are. How long before the gee-whiz wears off and they start to complain that app and device UIs aren’t as user-friendly as they could or should be?

A: It’s starting to wear off already. When the iPad came out, people just swooned over it. Now you’re starting to see articles, sometimes by the same journalists, saying, “You know, it’s got a lot of weaknesses. You can’t really type on it.” I think it’s becoming more realistic that the pad is not a substitute for a computer. It’s a wonderful device, but for its own purpose: You can read on the couch or answer a quick question. That’s a reality that wasn’t there at first.

Q: You and Jakob also bemoaned the lack of “Undo” in today’s gesture UIs. That absence is surprising, considering that PCs have conditioned us to expect it, and it’s useful.

A: I think because it comes a little out of the browser world, where the theory is that the “Back” button is the “Undo.” But it isn’t, not when you type something. On top of that, “Back” has always been very confusing. You’re never sure what’s going to happen when you hit “Back.”

I really hate this. There’s a stack of the previous locations, and “Back” takes you to the previous location. But I’m in some app, and I’m not sure where I am because it doesn’t tell me, and I want to get back to what I think is the home page. I hit “Back” and, whoops, I’m on the desktop.

It shouldn’t do that. You shouldn’t be able to back out of the application. In the browser, when you reach the end of its list, it doesn’t close the browser or take you to the desktop. It just dims the back button and doesn’t work anymore.

That’s what ought to happen when you hit “Back” in an application. I got really angry at one application developer. I kept saying, “Why are you doing this?” They explained that it wasn’t them, that the “Back” was programmed into the operating system.

Q: That means operating system companies have to provide a foundation that enables device vendors and app developers to make UIs more user-friendly.

A: Yes, it does. And they know that. That’s why Apple has usability guidelines. I’m not sure if Google does. There are people who have written them for Google.

Photo: @iStockphoto.com/studiocasper