A Response to Benjamin Sandofsky’s Shell Apps

Dion Almaer retweeted an article by Benjamin Sandofsky that covers “shell apps”, or HTML/Hybrid apps in contrast to native apps. His thesis seems to be, from his post:

If you plan to write an app for iOS or Android, you will save time and create a better product if you stick to Objective-C and Java, respectively.

Which I agree with in principle, but I also found some of his arguments deeply flawed. He spends a lot of time talking about the cross-platform problem of trying to build a web-experience that looks native on iOS and native on Android. Specifically he calls out differences on iOS and Android:

The harder problems are inconsistencies in platform conventions. The iPhone uses Helvetica as its system font, while Android uses Roboto. iOS transitions between views by sliding new views in from the right, while Android uses a zoom effect.
You could recreate each platform in HTML5, but that requires a lot of work. You could design everything around an iOS look, and settle for things looking weird on Android. You could create a platform agnostic design language, making things equally weird for everyone. In a web view, it’s an uphill battle for consistency, whereas going native provides consistency for free.

Put aside the fact that if you’re doing native development you’re writing two different versions anyway (I’m not sure why that would be a knock against an HTML-centric solution), why do you have to design around an iOS or Android specific look?

The Native Component Question

I know it’s harder, and potentially more expensive, and requires more design sense, but why should developers of HTML-centric apps for mobile devices be locked into the specific UI look and feel of that platform? I’m not talking about UI paradigms (eg, soft back buttons on iOS, menu buttons on Android), but the specific look of apps. Instead of skinning your application to look like an iOS app and then try to make it look like an Android app, do a design that looks unique and polished that would translate well across both platforms. Then as you start to get into the specific differences (he brings up a good point about transitions) you can implement those device/platform-specific patterns. To me one of the beautiful things about the HTML/JS/CSS stack is the freedom with which we can develop. Bringing that to mobile applications, and letting some great CSS/HTML designers loose on that platform is a great thing. And it’s one of the reasons I love PhoneGap.

There are definitely some performance implications by going with a shell app/HTML-centric app approach. And as your application gets more complex, those will pop up more and more. So it’s something to be very aware of. Benjamin quotes some of the reasons he sees for people choosing HTML-centric apps: “we need to release faster”, “write once, run anywhere”, “HTML is easier”. I’m not sure any of those are great reasons to choose HTML-centric apps. Instead I see the primary benefits of the HTML approach as not being locked into a specific platform or deployment model. With HTML you can repurpose code for mobile web and you can target new platforms as they come (no device is not going to support HTML). But maybe most importantly, with HTML you can easily create custom app experiences. There are some great designers out there who can do amazing things with HTML and choosing something like PhoneGap lets you use those skills to create a unique web-like experience with all of the device features users expect from native apps.

Is it a silver bullet? Definitely not. But I think dismissing HTML-centric apps as being done because they’re cheaper/faster/easier doesn’t do them justice. For some kinds of apps, the HTML-centric approach is just better. There’s an amazing community of people that know HTML/JS/CSS, the web is the ultimate platform for reach and flexibility, and shell-apps bring those two elements to the native app world. That’s something to celebrate.

  • http://twitter.com/jonbcampos Jonathan Campos

    This is a common sentiment among native devs. If it doesn’t look native then it is a bad app. I’ve heard it 2 years in a row at Big Android BBQ. My response was always “why is a custom looking app mean that it is wrong”. I never got a good response beyond personal preference.

  • http://blog.digitalbackcountry.com Ryan Stewart

    Yup, totally agree. I think hopefully as more general web devs/designers start looking at shell or HTML-centric apps, we’ll see some kick ass examples that can be pointed to as evidence that users just like good apps. 

  • http://twitter.com/s9tpepper Omar Gonzalez

    To me I don’t think its necessarily about the actual aesthetic look of the application. Its more about the actual experience of using the application. On iOS apps users expect to be able to slide left/right on some lists to expose a Delete button. On Android users expect a long press to display a pop up selection list to perform a similar type of action. 

    I don’t think that making native applications look exactly the same as the native components is a must, but the interactions that users grow to expect from platforms like iOS and Android can’t just be dismissed. To dismiss these types of user experience expectations you’re forcing your user to learn more about how to use your app than they need to learn if the application reuses common paradigms, like long press on Android and slide reveal buttons on iOS. 

    Personally, I don’t think it matters at all whether its written in Objective-C, Java or HTML/JS/CSS. What matters the most is how easy is the app to learn for a non-power user, and using already established UX paradigms specific to each platform makes the learning curve of a native application much less steep than making custom controls/interactions so as to shoehorn UX into different platforms. I don’t think its impossible, but its harder to achieve and not intuitive to users.

    My .02.

  • http://blog.digitalbackcountry.com Ryan Stewart

    Definitely. And I think that’s the major knock on HTML-centric apps. It’s tough to get that exact experience right when you’re targeting different platforms. I don’t think it’s impossible, but it’s tough. And Ben (Sandofsky) brings up some good points about those behaviors. 

    Even more, traditionally web devs don’t *think* about those as much, so I also think there’s some learning that has to go on so that they can build apps that are easy to learn and based on UX patterns that users already know and understand. 

  • Barrand

    I’m being asked this question for an app that we will be writing, and I’d like to have some examples of well written shell apps. Anyone know of good examples?

  • dileepadayan

     yes