with Rob Chandhok, President of Qualcomm Internet Services and SVP of Software Strategy
 |
|
Rob Chandhok |
June 2012 was an unprecedented month in the ongoing evolution of mobile software development: In the span of just a few weeks, Apple (NASDAQ:AAPL) unveiled its iOS 6 operating system update, followed in quick succession by the introductions of Microsoft's (NASDAQ:MSFT) Windows Phone 8 and Google's (NASDAQ:GOOG) Android 4.1, a.k.a. Jelly Bean. All three upgrades herald steps forward for their respective platforms, but also present new challenges and constraints for developers looking to create and distribute applications optimized for all segments of the mobile subscriber population, regardless of the user's OS or device.
Those complexities were a central theme of Qualcomm's (NASDAQ:QCOM) Uplinq 2012 developer conference, which took place in San Diego in late June. FierceDeveloper contributor Jason Ankeny spoke to President of Qualcomm Internet Services and SVP of Software Strategy Rob Chandhok about the obstacles and opportunities impacting cross-platform app development moving forward, and the role Qualcomm will play in that future.
FierceDeveloper: Cross-platform development has been one of the major themes of Uplinq 2012. What are the biggest challenges facing developers as they look to take their apps cross-platform, and what is Qualcomm doing to help them overcome those obstacles?
Chandhok: A lot of times when people think about developing cross-platform, they think that means resigning themselves to the least common denominator. One of the things that we're trying to show here--both with what we're doing with the tools that we give and the partners that we work with, from what we do with our Snapdragon SDK to working with folks like Unity--is that you can still do really cool stuff, but actually have a pretty broad market.
HTML5 is still one of our key focuses. We've seen in the last year a lot of development there in terms of the people writing tools for developers that are using HTML5 runtimes. We also still see a gap where we'd hoped we would be in terms of getting standardized on device APIs and other things we think need to happen. But our focus is on the idea that cross-platform doesn't need to mean bad. A lot of people retreat back into native because they think they can't do it right in HTML5 or in some other environment. We think there's still work to be done, but it's getting better.
FierceDeveloper: You said yesterday that a year ago at this time, you thought HTML5 would be further along that it has turned out to be. What did you envision? Where did you think HTML5 would be in mid-2012, and what has held the industry back from making the kind of progress that you anticipated?
Chandhok: I envisioned that a lot more of the features of HTML5 that are already standardized would be implemented. The evidence of that lack is the Ringmark benchmarks and performance tests that Facebook is driving--that's driven by their frustration at trying to do really cool UIs in HTML5 and finding out that a bunch of the browsers don't implement it properly. That has been partially due to the way people approached HTML5--plus, I think Microsoft has come a little slower to the game, but clearly with Windows 8 has made a really big investment in JavaScript and HTML5. [Internet Explorer] 10 passes the same amount of Ringmark that every other browser passes right now.
So we get HTML5 with core features like background Web workers and stuff like that. The Android browser didn't do those things like Chrome has for a long time--the Android browser was just more of a basic browsing experience. But now with Chrome moving to Android and coming to other platforms, that will drive a more ubiquitous platform to some degree.
The other piece is that W3C and other groups that are thinking about device APIs are moving much more slowly than I thought they would. One of the things we're trying to do to help that is that QuIC, which is our open-source subsidiary, just joined the W3C.
FierceDeveloper: How far away is HTML5 from realizing its full promise?
Chandhok: Hopefully about a year. I know I said that a year ago, but I think Windows 8 will change things--when that launches, I think the game will get a lot more interesting. We're working with Mozilla and supporting what they're doing with Boot to Gecko, although I'm not sure yet how big an influence that's going to have.
FierceDeveloper: When we talk about the possibilities of HTML5 and cross-platform, cross-device experiences, there's a sort of utopian element there where everything works together. As a natural-born cynic, I question whether that kind of environment is realistic. For example, say you're playing a game on an Android phone--then you move gameplay to a Mac, or another device. How will something like in-app purchases work in that ecosystem? If a purchase is made on one device, will there be revenue sharing across all the platforms involved? For HTML5 to be the panacea people believe it can be, is everyone going to play along for the greater good?
Chandhok: That is a really good question. I think it is in some sense rooted in the distinction of the issue of whether this is a technical exercise or a business exercise. You talked about both of those in your question.
I don't think that what's going to happen with HTML5 is going to be driven by technical reasons. Developers go where the money is. It can be hard to program on a platform, but if you can make money on that platform, you are going to go do it, because there is a return on your investment.
What has driven HTML5 and what has driven the ecosystem of the Internet is that fast, iterative design process that happens when you have more control over the expression of your ideas at a scale that is massive. When Twitter was starting up, and Facebook and Amazon and these kinds of sites were just beginning, they iterated so many different designs and experiences and tried different things, and they did it on a scale of millions and millions of users where they could pick subsets, they could do A/B testing and do all this other kind of stuff because they were running it all off of a webpage.
I view that in contrast with an app like [Zynga's] Draw Something. They just made a major UI release, but I know that probably 80 percent of their population doesn't have the update because they actually have to download it. At some point, I get fatigued with having to update all my applications--I don't even think about it on a Web-based application, and I don't think of the things in my browser being inferior to an application-based experience. And it strikes me that it shouldn't be about the fact that the screen size is different or whether it has a keyboard or not, or a mouse or not.
We're in a place where the rest of the glue around there just has to happen, because there are just a couple of fundamental things that have to be in there for it to be a mobile experience. People expect that you should be able to do more on that webpage and in that Web-based application than just getting to your location. That's like the only interesting device API that exists as a standard--websites on your laptop will use the GetLocation API and will use Wi-Fi access points and it doesn't have GPS in there, but it does a good enough job that when you look up a restaurant, it knows you're in San Diego. We need that equivalent for a couple more fundamental building blocks--camera being one of them, and some of the sensor stuff being the other one.
And if you get that, then you'll see the next class of applications that can be delivered in [a] Web-based [format]. They may be packaged in the App Store in a wrapper, but their guts will be Web-based, and instead of having to download a new version of the app, every now and then the app refreshes itself.
PhoneGap is a good example to track in terms of how real that is going to be. Adobe has generally been pretty good about building tools for people to build content--people that aren't at their core developers. That was the cool thing about Flash or Shockwave--that you could be a graphic designer or a Web person and not actually be a hardcore hacker, but you could build something and distribute something that worked on all these different websites. It made the ecosystem really, really broad. Which is why people watched the Flash versus iPad wars so carefully. Now you can see Adobe embracing HTML5 with PhoneGap and it's that glue that's missing to smooth out a bunch of the other things.
FierceDeveloper: Let's shift gears. One of the big announcements here was the Snapdragon SDK. Talk about what it means for developers to have access to that kind of processing power--how do you hope to see developers leveraging these new capabilities you're offering them?
Chandhok: What you're seeing with the Snapdragon SDK is a reflection of either the change or the maturation of the mobile market, depending on what you prefer to call it. It's a shift for technology platform providers like Qualcomm, from a view that our differentiation should be provided to our direct customers--which in most cases are OEMs--in a way that they can figure out what to do with it to differentiate their products. The OEM isn't driving that anymore. The differentiation comes from the kind of performance and behaviors you get in applications, and how you communicate that.
In some ways, the Snapdragon SDK is our way of saying that in addition to giving our direct customers access to what we've put in our silicon, we also want the developer community to--if they want to--have access to it. It's a little bit of a shift. SDKs for developers are different from how we release software to our OEMs. The OEMs can handle things changing--they're redoing their phones almost from almost scratch a lot. But now that they're building on top of operating systems, they're not differentiating in as many ways at that layer in the stack. They're differentiating in other ways.
We decided to commit to what an SDK really is. Which is 'Here is the way the APIs are going to be, they're going to fail gracefully if you're on a chip that doesn't have that feature, and we're not going to change them unless we absolutely have to, and if we do so, we'll do it in a backwards-compatible way.' That's what software developers want to hear. An OEM can cope with a larger set of changes in functionality and so forth.
We want people to have code that says 'Hey, if I'm on one of these cool processors, I'm going to take advantage of it. I'm going to make my picture-taking better, I'm going to make my image processing better after I take the picture, and I'm going to make video run at a higher resolution.' Some of these things will drive these extensions into Android and other ecosystems, and sometimes Android will make that happen in the next version, and we'll just fall back and point to the Android implementation. We just want people's software to not break, and we want developers to have the choice of actually exploiting the extra stuff we put in our chips that we think makes it interesting. If we don't make it accessible to developers, there's a lot less value in putting it in our chips versus just the stock functionality.
FierceDeveloper: To that point, if you're Apple or if you're Google, there's also value in looking at what developers are doing with Snapdragon to know where the developer interest lies, as opposed to spending your time and energy on new features and extensions that developers aren't interested in leveraging.
Chandhok: That's a great point. The way the Web community learned what WebGL should look like is we had a couple candidates. Google said 'Here's O3D--try this.' Turns out there was another model people thought worked better, and we ended up with WebGL for exactly the reason you're saying.
Every square millimeter in our silicon is expensive to us. It's expensive to build and it's expensive to test, so we don't want to build chips where just because this thing's running on Android, we can't get to the great camera functions. It's not Android's fault--I don't think Google is doing it to be malicious. So it becomes our responsibility. And we're fine with that.