Web! Native! Both?

I once had a professor who insisted that writing software was 70% planning and 30% implementation. I thought he was crazy at the time. 18 years later I completely understand where he was coming from.

Nolan Lawson kicked off another round of discussions about using web technologies exclusively to build native apps (and a follow-up here). The native app people always come down on the side of no way. They rightly point to the fact that web apps don’t feel like native apps. The animations between views aren’t as smooth, the look-and-feel can never be native enough, and the “write-once, run-everywhere” approach just means really mediocre applications everywhere. Learn to write native code!

The web-centric developers point to the complexities of learning web, iOS, Android, Windows and Mac program. Learning any one language well is hard enough. Learning five well enough to write performant apps and maintain those apps is nearly impossible. Besides it is the web that made Mac relevant. We already have write-once, run-everywhere. It’s called a web browser. Why should we go back to coding like its 1995?

These arguments, however, ignore a third way: the hybrid app. The hybrid app is where some of the application uses web technology and some use native code. We use embedded web views wrapped within native code to present the application to the customer.

Apple already does this in some of their apps today. The Mail app uses web views to show email. It is also rumored that iMessage uses web views to show individual message bubbles. iBooks may use web views as well. Third-party apps, especially reader applications, RSS apps and apps like Flipboard and read-it-later applications use web views in this way as well. The entire app isn’t HTML and the entire app isn’t native.

The key to this approach is understanding clearly what makes each of the various technologies superior and then use each of those technologies appropriately to build a superior experience. Just like in the days when developers would use Assembly to write really CPU-intensive aspects of their apps, web technologies can be used to do what they are best at: rendering and formatting text, especially when combined with other medias. Have you ever tried showing an image along with a block of formatted text in iOS or Android? How about a bulleted list with text around it? It’s possible but it isn’t easy. HTML makes that simple, even giving us the ability to edit that text and return the output to the native app.

HTML fails miserably at animation¹, though, and it is nearly impossible to make HTML look like Android or iOS. Don’t use it for that. Learning the basics of navigation, list management and animation techniques in any native platform, though, takes a much smaller amount of time and doesn’t require nearly the skill set.

This is why planning is so important. When we started working on Equals we broke the product down into small pieces, deciding how to accomplish each piece, thinking ahead to both how the app would work on the web and also how it would be presented on native platforms.

We used Equals’ technology to develop our first mobile app: DEWALT Mobile Pro for Android. I had never written an Android app before this. (powerOne for Android was developed by a third-party.) True to my word, DEWALT Mobile Pro is a hybrid app: it uses all native Android code to present the list, calculator and various dialogs, and uses HTML technology to present the template itself, which combines various elements — images, links, text, and some input keypads — in a single page.

It took less than three months to write the entire application, including learning how to develop for Android. In comparison, it took six months to develop powerOne for iPhone back in 2008. The difference, frankly, was the amount of time I needed to invest in native code that shows and allows data input into the templates.

By utilizing a combination of HTML5 and native code I believe I was able to attain a superior presentation of the templates while, at the same time, maintaining a native look-and-feel for the application. We can shout “native!” “web!” but in the end we should use the technologies — or, more appropriately, the combination of technologies — that make the best applications. Sometimes that’s native code, sometimes it’s web code, and sometimes it’s both.

¹ I am specifically referring to animation that acts like native code. Making a spinner spin isn’t a big deal anywhere. But transitioning from one view to another never reacts well in HTML. If you do any animations, I can highly recommend Greensock’s GSAP technology. It is amazing, and the recommended animation engine by Google for their Material Design stuff.

3 thoughts on “Web! Native! Both?

  1. I really don’t consider HTML5/JS hybrid a native app as most of the application logic is still in JS. If you want a cross-platform native app that looks like one, and performs like one, you should take a look at Xamarin. With that approach you can still use HTML5 and JS wherever you want but aren’t limited like with the hybrids.

    • Only as much of the logic is in JS as is required. It neither needs to be little or lots. For instance, I don’t believe massive amounts of the logic of Mail are in JS. Same for iMessage.

      • I guess in the end it all depends on what the goal is. To reuse the code across all platforms you would then need to write the app logic in something that compiles on all. That would then be C or C++. Needless to say that approach has its own little quirks too.

Comments are closed.