Gone Native?

By Jake • September 30th, 2011 • 6 Comments

I’m a bit sad that one of the few social apps I actually use anymore, Untappd (@untappd) has released native apps for Android and iOS.

I’ll explain.

First, what is Untappd? With a motto “drink socially”, you can probably figure it out on your own. It’s a social app for beer drinkers with a bunch of badges, and I love badges, almost as much as I love beer.

Although I don’t spend much time on the social aspects of Untappd, the baked-in game mechanics have spurred me to try a metric ton of new beers, and for that, my palate is eternally grateful. Over the past few years, my social inertia has slowed greatly, due to checkin fatigue (foursquare), signal to noise ratio (Twitter), mainstream pollution (Facebook), and lack of compelling use cases (Google Plus, Quora).

However, Untappd is an easy fit for me, so it’s really the only social app I use with much frequency anymore.

I also love technology and the open web, and Untappd has been a shining beacon for the possibilities of the mobile web. Untappd launched with a mobile web app built in jQuery Mobile, something we investigated and prototyped internally.

JQM is a great project, and Untappd gave me a user’s perspective on how a jQM app performs and behaves.

Short story long, they’re going native, and I’m bummed.

I hope the guys over there, including John Vajda (@genexerjv) an ex-Oracle guy who joined Untappd when they acquired Red Pint, can shed some light on the technical reasons why. I’m curious to know.

I’m sure their native apps are great, not knocking native, but being in development, I’m hopeful for the future of mobile web apps because they’re cheaper to build.

Any thoughts on Untappd, jQM, mobile web apps, beer?

Find the comments.

Update: Before I even published, I hit up the new Untappd Android app, and it appears to be a native shell wrapped around their jQM code base, which is awesome. I’m actually stoked now, since this is an approach we’ve also considered. Kudos to Untappd.

Update 2: They’ve used PhoneGap to package up their jQM code into native. 


Possibly Related Posts

  • http://www.kiranslog.com Kiran

    This tug of war between Native and HTML Apps is going to continue for a little while before it settles down. Even Google struggles with it right. You might also be following Joe Hewitt moves between Native iOS and HTML/Javascript. Part of the problem is with Native both iOS and Android are innovating at an amazing pace, they will keep adding value to the Native APIs. HTML5 catching up is going to get harder and harder. Internally we are continually debating this same issue, we are trying very hard to stick with jqm etc but there are certain things that are so damn easy to do in iOS natively.

  • http://theappslab.com Jake

    I don’t see this as a tug of war. These are two toolsets that both do a good job. So, ultimately, you need to understand who your users are, where and how they use your app, what they do w it, etc. before committing to a path.

    Frankly, I doubt your users really *need* native apps. 

    The one major caveat is performance, which the Untappd team mentioned in their post. 
    The mobile web doesn’t need to catch up to native SDKs, and it never will. That’s OK because teams need to choose a toolset based on their users and what they need. 

    Also, it’s not that easy to do things in iOS natively when you factor in all the costs. The number of really good Obj-C devs out there is tiny. Compare that to number of really good JS devs. Not even close.

    So, hypothetically it may be easier, but in practice, it’s to good at Obj-C, and not just at writing code, but at building good, extensible MVC.

  • http://www.kiranslog.com Kiran

    The fact is you cannot generically determine the stack, you need to understand the users, the requirements and chose. Part of the problem is until you code in both you cannot decide. 

  • http://theappslab.com Jake

    And yet many times the stack is determined for you, which leads to writing only one flavor code. 

    You *can* make a call about platform without coding first, assuming you have the necessary skill sets for both (or all) options. Sadly, it’s very rare for a team to have that range of skills. So, decisions are made without understanding the users.

  • http://www.kiranslog.com Kiran

    “And yet many times the stack is determined for you”  -ain’t that the truth

  • http://theappslab.com Jake

    Sometimes :)