Going Native.

by jennifermshoop

One of the toughest decisions I had to make during the app design process was whether we were going to design a mobile-ready web application or a native application.  (Spoiler: we ended up going native.)  Having done a lot of hand-wringing and tossing and turning on the topic, I thought I’d share the framework I built for myself (on the fly) as I was weighing our options.



{Image via Sheridan.com}

Important caveat: there are no right or wrong answers here, in my opinion, which is why we’ve seen big companies like LinkedIn and Facebook go in one direction and then shift to another.  (Both of them began with mobile-friendly web apps and then went native.)  There are pros and cons on both sides, and this is a decision that requires a lot of careful thinking and balancing.  I asked myself the following questions:

1.  Will the app make use of native smartphone features?  (Or will the use of those features dramatically optimize the experience?)

Our app is designed to make primary use of the smartphone’s built-in camera — youth post their progress on most of their financial challenges by snapping photos and posting them to a “challenge room news feed.”  This design feature made the decision to “go native” fairly straightforward.  If you’ve ever been prompted to toggle between apps while trying to accomplish something in one app, you know how frustrating a non-native experience (i.e., without the camera API) would be.  (In my opinion, there’s nothing more frustrating and disruptive than clicking a link that then launches the Safari browser.)

In this fantastic article, mobile technology guru Michael  Mahamoff also makes the point that “smartphone users demand alternative surfaces such as widgets and notifications. While the latter is starting to get support in HTML5, it’s often difficult if not impossible to construct these UI surfaces from the browser, and even HTML5-powered native apps are limited in their means to provide rich, interactive interfaces outside of their primary arena.”  Though our minimum viable product will not include notifications of this kind, we envision that as we move to concept, this will be a crucial feature addition, as our target market (youth between the ages of 16 and 18) are accustomed to viewing a cross-application feed of notifications in their smartphone notification center.  I think this is an important observation that the tech world should keep an eye on — possibilities for notification “channels” are emerging.  As  this article points out: “Our portal is our app screen. Our network isn’t Facebook or Google or Twitter. It’s the phone address book that is the union of those three imports. And on the phone we stop dreaming about “If only there was a service that integrated functions of Twitter, Gmail, and Snapchat!” Because there is a service that integrates that — your phone’s notifications screen.”

I digress here.  But the point is — think carefully about the features of your app’s design.  Will it make use of the phone’s GPS?  Scan?  Camera?  Etc.  If so, lean towards native.

2.  Will the app have a complex UI?

Let’s be honest: all native apps will feel more elegant and rich than their web app counterparts.  If you question this, check out Facebook through your mobile safari browser.  Then remember that Facebook has hundreds of engineers who work on optimizing this experience.  That being said, there are interfaces that are on the simpler side and won’t be as dramatically impacted by the comparatively clunkier web app experience.  For example, if your app primarily consists of “static” content for reading/reviewing (for example, a blog or news syndicator), or maybe simple checkboxes to demonstrate interaction, then the mobile-ready web app won’t be dramatically improved in a native format.  If, on the other hand, your user will need to interact quite a bit with the screen or will be providing a lot of user-generated content, the equation changes.  For our app, youth will be updating a “challenge room newsfeed” with their progress.  Envision the clunkiness of a newsfeed refreshing every time you enter something new — possibly taking you to the very top of the newsfeed, or not showing new entries in real time.

If you want to get even more advanced in this conversation, note Mahamoff’s comment that: “The HTML5 “write-once, run-many” argument was more compelling when platforms lacked strong visual identity. A bespoke, run-anywhere, HTML5 UI could be just as good. These days, that’s just wishful thinking; Android, Windows, and BlackBerry have joined iOS as platforms with distinctive look-and-feel – and have discerning users who truly give a damn. So while HTML5 still aids reuse in some areas (subject to the fragmentation concerns mentioned above), user interfaces must be customised to build a great app. Even then, there are inevitably telltale signs and a lot of performance work that could be avoided in native platforms.”

3.  Are you planning to make frequent updates?

If yes, web apps are infinitely easier to update on the fly, and you don’t need to worry about version control.  You also don’t need to worry about app store approval — which, for iOS apps, can take days and even weeks.  (The Google Play store takes less time, but there is a process involved.)

4.  Are you trying to design something universally accessible?

If yes, web apps are likely the smarter route.  This was the biggest sticking point for me in my decision-making: in an ideal world, we would have come up with a way to provide the app to all of our students right from the get-go.  But our budget and contract only permitted the development of either a native app for Android OR iOS (not both) OR a mobile-ready web app.  It came down to weighing the pros and cons of getting the UX right with a native app vs. including all students with a web app.  At the end of the day, we decided that engaging students was more important.  We were worried that the UX would be so compromised in web app form that it might foreclose on our opportunity to engage youth longterm.  (N.B. One survey revealed that user engagement with a native app is 2x that of a web app.)

At the same time, the fact that only about half of our students will be able to use the app during our pilot this spring is admittedly imperfect.  We were comforted by the fact that, during our prototype test, student engagement largely followed cohort-specific trends and dynamics.  (That is — we ran multiple cohorts within three different classrooms, and specific cohorts within classrooms tended to vary with engagement — but not classrooms as a whole.)  We also saw that Android devices enjoyed a slightly larger market share, which made sense to me — there are a variety of different Androids at different price points.

It should be noted, however, that the web app route has browser segmentation issues — that is, browsers can be inconsistent in supporting HTML5, and you need to guard for these use cases.

5.  What are your budget restraints?

Native is always more expensive, especially because you’ll need to design for both Android and iOS (and potentially beyond…?)

6.  What sort of experience is your target customer accustomed to for this sort of product?

Youth are especially picky about design.  They’re much less forgiving than older generations, who have seen the idea of a native app come into existence.  We heard kids say: “If it’s pretty, I’ll use it,” and, on the other side of the spectrum, one student told me: “Craigslist is so ugly that I won’t use it.”  Our youth are accustomed to the rich, elegant native app experience.  I also felt that owning real estate on the smartphone would be especially important in terms of driving app use — would students remember to navigate to our web app when unprompted?  (N.B.  Users today spend almost 8x as much time in native apps than they do in a mobile web browser.)

7.  Will the app encounter difficulty in getting approved by an app store?

Something to keep in mind!

Send me your thoughts!