There Is No Cat - Native, Hybrid, and Web apps

We apologize for the inconvenience

Sunday, March 6, 2011

Native, Hybrid, and Web apps

Faruk Ateş has a couple of interesting posts up about the difference between web apps and native apps for mobile devices such as the iPhone, iPad, and Android-based phones and tablets. His point is basically that you can’t (at this point) replicate the quality of experience of a native app in a web-based environment. I spent a couple of months recently working on an iPad app and strongly agree with Faruk on this point.

The biggest problem is that the HTML/CSS/JavaScript technology stack on these devices is slower than natively-executed code. It’s a lot slower. This is the case whether you’re targeting Mobile Safari or using an app shell like PhoneGap, which Faruk mentions but says he hasn’t had a chance to play with yet. I have played with it for personal projects. The app I worked on at work was a custom hybrid app, with a crunchy Objective-C based shell surrounding chewy HTML, CSS and JavaScript. The idea was to have the shell simply provide a UIWebView window, and all the interaction would be performed within that by the JavaScript. It was incredibly difficult to get those interactions to act the way they would if they were executed by natively compiled code. There are a number of tricks you can use, taking advantage of the fact that 3D CSS transforms and opacity are hardware accelerated, but that introduced other complications, particularly around the limited memory available on the first generation iPad.

The tools available to debug your JavaScript are primitive at best. In Mobile Safari, there’s the debug console, but you can’t set breakpoints and step through the code and examine the variables to determine why things are breaking. In a hybrid app using UIWebView, you don’t even have that. We wound up hacking something together where a JavaScript library would URL encode anything you wanted to log, then use it to create and call a URL with a custom URI scheme, which the app shell would then interpret, understand that it was a log message, and output it into the XCode debugging window. My partner on the project, who wrote the Objective-C shell, had difficulty with the memory barriers we kept running into, as XCode doesn’t provide much information about what’s happening inside the UIWebView.

Another problem we ran into is that UIWebView didn’t provide support for accessing orientation in JavaScript. The window.orientation object existed, but wasn’t updated when the screen changed; it always reported that the screen was at 0 degrees, if I recall correctly. My colleague had to provide a way for us to access that information as part of the Objective-C shell that he wrote. I found that a really puzzling omission on Apple’s part. Note that Mobile Safari does update window.orientation properly. I think PhoneGap might also have implemented support for this to make up for Apple’s omission.

The worst thing was that implementing the entire interface in HTML/CSS/Javascript wound up creating an experience where items flickered when you moved them. Drop shadows and backgrounds proved particularly problematic. Matteo Spinelli, the author of the incredibly useful but sometimes flaky iScroll, has a post about how to avoid flickering by applying hardware accelerated transforms to items that flicker, but we found that then you exacerbate the memory limitations of UIWebView.

My colleague and I discussed this extensively. I’ve come to believe that there’s a place for UIWebView in App Store apps like this, but that implementing the entire interface within one is a bad idea. The user experience just isn’t up to the standard of a native app. And if you’re distributing your app through the App Store, then the expectation is that your app will behave just like a native app. The user doesn’t know how you implemented the app they just downloaded. They just expect it to work like every other app they’ve downloaded. Unless you have a barebones interface, your hybrid app is unlikely to provide that experience.

I’ve looked at a lot of apps on the iPad that distribute periodic content (like magazines and other news organizations) where the ability to use the HTML/CSS/JavaScript tech stack for periodic production tasks is a huge benefit. Very few of them seem to be implementing the entire interface with UIWebViews. The BBC News iPad app looks likely to be implementing some part of the app with UIWebView, specifically the display of articles. My colleague and I discussed how it’s much easier to display content on the screen using a UIWebView rather than from native code. But I don’t think the entire interface is done that way, or specifically, not all at once. It may be true that everything on the screen is drawn by a UIWebView, but it looks to me like the screen is carved up into several of them. I think the same could be said about the NPR News iPad app. Other apps seem to get around problems with rendering pages by prerendering them, which is to say, they’re showing you pictures of words. Any app that’s built around the Adobe Digital Publishing Platform is using this approach (I’m not sure if they're using UIWebView or native calls to display the graphics, though). This bloats file sizes hugely, as can be seen by downloading an issue of Wired magazine from the App Store. And I think it’s probably inaccessible; VoiceOver doesn’t do text recognition in pictures.

There’s definitely a place for the hybrid workflow, but you’re not going to be able to create an identical experience with web technologies that you can with native code. Integrating a web technology-based workflow into an app requires a lot of thought, and particularly careful design that takes the limitations of the targeted device(s) into account. Throughout the development process, I kept noting that the iPad was definitely a 1.0 device, despite its iOS 3.2 pedigree.

User expectations are different for a web-based app. The experience of using a browser is one where network latency is common and users are not surprised to find that pages take a while to fully compose themselves on the screen. This is even more the case when you’re using an iPad over a 3G connection, combining the relatively slow processor with the relatively slow network connection. So the kind of interface anomalies you might see because of the relative slowness of UIWebView (as opposed to native apps) are more acceptable. You can, and should, make sure you optimize the experience by taking advantage of hardware acceleration where you can, but if things take a half second to redraw, users are more likely to find that acceptable in the context of using a mobile browser. They see that all the time. There are apps where that kind of interaction is acceptable, and that would be a good case for creating a mobile-enhanced web site/app rather than a native app. But that kind of app is terribly limited.

Apple initially tried to tell developers that this would be the way that all “apps” for the iPhone would be created. Very little happened; some people tried to follow Apple’s direction, others went down the jailbreaking path. Neither resulted in a flood of applications. Once Apple delivered an SDK that enabled developers to take full advantage of the power of the device, we saw an explosion of apps that changed the way people use their phones.

One of the things that interested me most about the recent iPad 2/iOS 4.3 announcements was that Apple had ported its new-generation Nitro JavaScript engine to Mobile Safari (and presumably to UIWebView). Honestly, I was surprised that it hadn’t been there from the start, although its absence explains a lot of what I saw. It’s possible that these limitations will disappear as the hardware gets more powerful. But it’s also possible that as the hardware gets more powerful, native apps will blaze the trail due to their inherent relative speed when it comes to creating new and amazing apps that just wouldn’t be possible with the HTML/CSS/JS tech stack until a couple more hardware and/or software revisions down the road.

So by all means, if you have an idea that would make a good app and you think it could be implemented either as a web application or as a hybrid application, jump right in, but make sure you’re aware of the limitations of the approach. You’re very unlikely to replicate the native app experience from a web application, and in the hybrid approach, it’s going to be a lot harder than you thought.

Now listening to: "Chit Chat" from This Is Good by Hannah Georgas.

Tags: faruk ateş iPad mobile safari UIWebView

Posted at 3:17 PM

Comments

Trackbacks

Please note: your e-mail address is required, but will not be posted on the site. I reserve the right to delete any inappropriate posts.

Back to There Is No Cat

What do you mean there is no cat?

"You see, wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat."

- Albert Einstein, explaining radio