

Hybrid sweet spot: Native navigation, web content - yawn
https://signalvnoise.com/posts/3743-hybrid-sweet-spot-native-navigation-web-content

======
evmar
I work on an app that has made a similar tradeoff. I won't restate the
positives because the post describes many of them (after all, we chose a
similar architecture) but I'll add that fetching app logic+assets (in the form
of JS/HTML) from a server also lets us iterate on the app more quickly and
without requiring the user to approve an update. (Edit: oops, he actually did
mention this in the post!) And we get to use all our HTML-based testing tools
(like automated screenshotting) to catch regressions.

Our app is also different in that we precache all the HTML in the background
so we can always load it from disk rather than the network, which helps avoid
any loading delays.

Here are some of the negatives I've encountered. (My experience is solely with
Android but I believe the basics are also true on iPhone.)

\- There's a long tail of details that are hard to get right. E.g., handling
multiple device DPIs, or getting navigation right (Android has a confusing
mess of back vs up and tasks vs activities). This is all solvable (after all,
that's why you've gone hybrid), but it ends up pushing more of your code
native than you'd originally expect.

\- There's a delay on all click events on a webview. This is probably worthy
of a longer blog post but to summarize, there are at least two causes of this.

One is that by default click events happen 300ms after the touch event (I
think due to it waiting for a double-tap?). You can work around this by
handling touch events specially (and there are JS libraries that claim to do
it) but in practice it doesn't work in all cases (e.g. some form controls
can't be worked around) and we ran into bugs on obscure devices (e.g. our
users report they can't focus a form control on certain Samsung devices; we
even got one of those devices but couldn't reproduce the problem).
Alternatively, the newer Chrome-based webview turns off this delay if your
content's meta tags indicate it's not zoomable, but you can't really rely on
this because the Chrome-based webview isn't widely deployed.

The other source of lag is that the "active" DOM state is _also_ delayed, but
by some other number and unrelated subsystem. This means when you tap a button
it'll light up a bit after you tap it. In my brief survey I think other mobile
apps work around this by not having a prelight state.

Sorry to be full of bad news. (Like I wrote above, I still think this
architecture is the right tradeoff for my application's purposes.)

~~~
yesimahuman
The reality is that tap events won't work correctly until you actively fix
them, and almost all of them can be fixed (including ghost clicks).
Fastclick.js does help here a bit, but it's not perfect. We did a ton of work
on our end to have a comprehensive tap solution (though some of it is specific
to Ionic projects), but could be useful for inspiration for your own project:
[https://github.com/driftyco/ionic/blob/master/js/utils/tap.j...](https://github.com/driftyco/ionic/blob/master/js/utils/tap.js)

~~~
evmar
Thanks for the link. We also have an in-house solution like fastclick.

The hard part about this is tracking down the long tail of failures,
particularly when they affect devices you don't have access to like the
Samsung phones I mentioned above. It means we cannot make any changes to the
code we already have without risking breaking some users who currently work
(and rely on our app; as separate from the users for whom the app has never
worked).

~~~
yesimahuman
Yea, I agree. The situation is annoying, but with Chrome on 4.4 around the
bend, I think it's only time before this is a legacy issue.

------
marknutter
I'm glad to see an organization as prominent as 37 Signals coming out in favor
of the hybrid mobile development approach. Everything DHH mentions in this
post is spot on as far as my experiences developing hybrid apps goes. I was on
a project that was resource constrained but needed good mobile presence as
well called kona.com that's in the same problem space as Basecamp. We tried
both the full native and full HTML5 routes but neither option worked for us.
We didn't have enough developers for our native apps to keep up with the web
app and the HTML5 app (powered by Sencha) simply didn't perform well enough on
phones back in 2012.

After scrapping both those attempts I suggested we go with a hybrid app. We
would lean heavily on javascript (angular.js in our case) and rely on native
for access to native APIs and for UI elements that required better performance
like the Facebook style drawer, slide up animations, the top and bottom nav
bars, etc. It was the right mix between developer efficiency and app
performance and allowed us to target not only Android and iOS with 90% of the
same codebase, but also a native desktop app as well using Chrome packaged
apps. We had written the main web app in JavascriptMVC but when I left the
project we were just starting to port over the angular app to the main site,
so eventually the same angular app would be powering the website, desktop app,
iOS app, and Android app.

It only took one developer (myself) to manage the native code on Android and
iOS and the logic was very similar in both places so it ended up being pretty
simple to maintain. And as DHH mentions, setting up communication between your
native code and your web code is easier than you'd think, although I am
interested in hearing more about how they did it.

At any rate, DHH is totally right about the fact that most apps would be
suited just fine by hybrid mobile apps as most apps are data heavy like
Basecamp. Don't tell that to native developers though because you will catch
an earful about poor user experiences and maintenance hell, which in my
experience is a bunch of FUD. The proof is in the numbers, and the Basecamp
apps are well received (as were ours). The FUD around mobile apps and user
experience reminds me of this post that showed up on HN last week:
[https://medium.com/design-founders/f59c964513ef](https://medium.com/design-
founders/f59c964513ef), which examines the failure of the assumption that
meticulous, cutting edge design will guarantee success. In my experience, if
you can get close to native but you solve the user's actual problems (which is
very rarely related to a lack of unique swipe gestures and translucent
backgrounds) you are usually good to go. Why continue to deal with the pain
and cost of having dedicated teams working on the _exact same app_ for
Android, iOS, Windows Phone, the Web, native desktop apps and god knows what
else?

~~~
BSousa
The user experience problem is a real one. But it doesn't mean it makes
business sense for a small company to hire 2 iOS developers and 2 Android
developers for native apps when the user base doesn't make heavy use of their
mobile app (hybrid or not). I honestly don't care if I'm doing native
development, backend, frontend, etc. But throughout the last 4 years I've
used, analysed and worked in many different mobile apps, and the hybrid ones
stick out, from speed issues to expected user patterns that aren't respected.

I tried the basecamp app on android and I'm to say that the UX is good is a
stretch (for consuming the data is fine, but for inputing data is not).

~~~
marknutter
> The user experience problem is a real one.

Not in my experience. Without fail the only people I've ever heard complain
about UX of hybrid apps are other developers who know which signs to look for.
Most people won't notice or won't care to notice so long as the app does what
it's supposed to do.

After all, I've been hearing developers complain about Craiglist's poor UX for
years and it hasn't seemed to affect them.

~~~
rimantas

      > Most people won't notice or won't 
    

Oh they will, they will. But you will never hear them say "man, this app
sucks, cause it is hybrid, I wish they did it all native"—because they don't
know the difference in the technologies. But they do know the difference in
experience.

~~~
marknutter
Well, the proof is in the pudding. If what you're saying is true Basecamp's
ratings would be a lot lower, wouldn't they?

------
thekingshorses
User's don't care if you use native or HTML5 as long as you get them what they
need.

One of the major problem with HTML5 is not HTML5/JS but how you we are trying
to use those. We want to use all the libraries and frameworks. Backbone,
AngularJS, bootstrap are good but using those on mobile will slow down your
app. Also there is this mentality that you can only have good interaction if
you build 100% client side rendering.

Everyone thinks that rendering on client will be faster as we are only sending
JSON and html templates are cached. They should do compare and see if JSON
that they are sending is really lighter then rendered HTML. Most of the time I
found that after gzip, HTML is smaller compare to JSON.

Browser wise, Android is lagging behind when it comes to transitions. Its
getting better but still not good as Safari or IE on WP8. Also Samsung is
always uses wrong version of android browser. Even on galaxy S4, they screwed
up big time (Browser on S3 was better than S4).

I build hacker news mobile client using HTML5, and I do have 4.5 star ratings
on the both app stores.

[https://play.google.com/store/apps/details?id=com.premii.hn](https://play.google.com/store/apps/details?id=com.premii.hn)

[https://itunes.apple.com/us/app/hacker-news-
yc/id713733435](https://itunes.apple.com/us/app/hacker-news-yc/id713733435)

or Try it on your browser

[http://hn.premii.com/](http://hn.premii.com/)

~~~
thekingshorses
I started working on this but no time.

[http://dn.premii.com/](http://dn.premii.com/) \- Designer News For mobile.
Lot of animations and works on Android, Safari on iOS and IE10+ on WP8.

~~~
Kiro
I'm very impressed by the performance on both your DN and HN clients. Usually
everything web lags a lot using the stock browser on my Galaxy S3 but these
are very smooth. What's your secret?

------
thoughtpalette
Just made my first "app" using Cordova, and the Ionic framework/CLI,
[https://github.com/driftyco/ionic-cli](https://github.com/driftyco/ionic-
cli).

Was super simple and straight forward. Simple 7 page site with a breadcrumb
nav and PDF/Video integration. Highly suggest cordova/phonegapp and Ionic if
you're doing something simple in a WebView.

~~~
yesimahuman
Thanks, glad you like Ionic :)

I personally think you can do 100% of the nav in the web. The problem is there
legitimately weren't native-style navigation tools in web until recently.

Unfortunately, the standard linear history doesn't work for apps that run in a
native container. You'll often be managing three or more concurrent navigation
stacks (for a 3 tabbed app, for example), and the concept of a browser back
button just doesn't make sense in an app like that.

So we've built a lot of that with Ionic. Perhaps at the expense of the _mobile
web browser_ app experience.

~~~
thoughtpalette
Don't get me wrong, I'm loving the experience so far and my "simple" comment
refers to my skill level.

I did have a couple issues finding answers. Since you've commented, I'll post
a couple here but I'll try to add them to the forum.

* Setting webviewbounce, UIWebViewBounce to false in the config.xml doesn't get respected by the framework. You have to manually add the attribute has-bouncing="false" to the ion-content tags to stop the bouncing.

* The helper ionic.Platform.fullScreen(); to hide the status bar initially flickers on first load of a fresh build. I'm currently trying to figure out how to hide the status bar on initial build. [http://stackoverflow.com/questions/23553220/how-to-completel...](http://stackoverflow.com/questions/23553220/how-to-completely-remove-uistatusbar-in-ios-application)

* I was a little confused using ui-view vs. ion-view. (I think)

Thanks for taking the time to comment!

~~~
yesimahuman
Hey thoughtpalette,

WebView bouncing is a vague term and I'm not exactly sure which you are
referring to. If you're talking about the entire frame, it's now
"DisallowOverscroll" in the Cordova config. If you use the ionic utility
you'll get the correct config for a new project.

To hide the status bar, use the status bar plugin
(org.apache.cordova.statusbar) and call StatusBar.hide():
[https://github.com/jonathannaguin/org.apache.cordova.statusb...](https://github.com/jonathannaguin/org.apache.cordova.statusbar)

The ui-view vs ion-view discussion: use ion-view. We basically have a custom
ui-router implementation with multi-stack routing.

Hope that helps, and I'll look into our docs to make this all more clear.

~~~
thoughtpalette
Thanks for responding!

I did use the DisallowOverscroll in my config, I still had to manually add
has-bouncing=true to every ion-content tag.

These are the values I tried:

    
    
        <preference name="fullscreen" value="true" />
        <preference name="webviewbounce" value="false" />
        <preference name="UIWebViewBounce" value="false" />
        <preference name="DisallowOverscroll" value="true" />
    

The issue with the status bar is even using that plugin (which I have working
now thanks to the forums) there is a flicker on initial load of the app when
it hides. Still can't figure out how to get rid of that.

Thanks again though for answering!

------
malandrew
The only true advantage the hybrid approach offers is improved interface
performance, but that comes at the great cost of (1) increased complexity
(multiple technologies, possibly multiple teams), (2) poor distribution and
conversion (install require), (3) dealing with draconian app store approval
bureaucracy, and (4) speed of tech and design iteration much slower than the
web.

The gap for this sweet spot is going to close very rapidly over the next year
or so due to work being done by us at famo.us and engineers working on
react/om.

DHH, like others love to point out Facebook's decision to pull out of HTML5,
but that is going to become a tired meme. One of the FB engineering managers,
Dave Fetterman, who was instrumental in making the call to go with HTML5 and
then reversed course towards native, is now the VP of engineering here at
Famo.us. That's a testament to what's possible soon, since typically someone
doesn't go back an revisit what many people popularly consider to be be a
mistake unless there is real value there on the horizon. The fact that
Fetterman is back working on this problem and that Pete Hunt and team at
Facebook is actively working on react is testament to the performance that's
now achievable without having to be a javascript neckbeard.

If you were a web developer that left the web years ago for native land, or
you have always been in native land and were waiting for the web to catch up,
now is the time to start exploring what's possible. There will always be a use
case for native technologies, but the web is going to gut a lot of the current
use cases for native over the next 1-3 years. When that happens, there is
going to be a glut of iOS and Android devs and a dearth of javascript
developers who really know how to build great web apps.

(disclaimer: I work for famo.us)

~~~
chadcf
You guys need a little love on your page :) I've not heard of it before so I
google it and get to what appears to be the home page, and am presented with a
login box with zero info about what it is, or why I would want to register or
log in in the first place. Plus 3 of the links in the header aren't linked to
anything. Not the best first impression!

~~~
malandrew
Yeah, it does need some love. We're aware and plan on really fixing it up over
the next month or so. For the most part almost all engineers on the team are
working on some fundamental part of our medium to long-term vision and we're
mainly trying to bring all those parts together in a coherent way first.

Another reason for its current state, is that the tech media and the community
have been quite eager to take care of our positioning and messaging, so we
haven't had to focus engineering effort on these areas too much in order to
see adoption and growth. Improvements are coming. Look out for changes to the
site over the next 1-2 months.

------
pietrofmaggi
Motorola Solutions employee here (MSI bought RhoMobile three years ago).

RhoMobile is a platform that deliver on building a native application using
web technology. A lot of the idea are borrowed from Ruby on Rails in the
Framework (MVC framework done in Ruby with a simple ORM on top of SQLite).

    
    
      * Updating the app without user intervention? 
      covered[1]
    
      * Common set of API available in JS and Ruby? 
      yes [2] 
    
     * Offline capability, local data and a synchronization server based on a NoSQL DB? 
      of course. How can you leave without a NoSQL DB? :-) [3] 
    

By the way, did I mention that RhoMobile won 2010 Fukuoka Ruby Award Grand
Prize? [4]

You can take a look on Launchpad, MSI developer website [5]

[1]
[http://docs.rhomobile.com/en/4.1.0/guide/app_upgrade](http://docs.rhomobile.com/en/4.1.0/guide/app_upgrade)

[2]
[http://docs.rhomobile.com/en/4.1.0/guide/apisummary](http://docs.rhomobile.com/en/4.1.0/guide/apisummary)

[3]
[http://docs.rhomobile.com/en/4.1.0/rhoconnect/introduction](http://docs.rhomobile.com/en/4.1.0/rhoconnect/introduction)

[4] [http://www.prnewswire.com/news-releases/rhomobile-rhodes-
sma...](http://www.prnewswire.com/news-releases/rhomobile-rhodes-smartphone-
app-framework-wins-fukuoka-ruby-award-grand-prize-82252817.html)

[5]
[https://developer.motorolasolutions.com/community/rhomobile-...](https://developer.motorolasolutions.com/community/rhomobile-
suite)

------
kpapke
Surprised that Famo.us has not been mentioned in this thread. It looks like a
very significant technology to solve this problem.

[https://famo.us/about/](https://famo.us/about/)
[http://www.codepen.io/befamous/](http://www.codepen.io/befamous/)

~~~
garthk
I'm not. To the degree famo.us is wonderful, its about page gives a
misleadingly bad impression on my default mobile browser.

On my landscape iPad Air, the hamburger menu on the first link flapped state
during scrolling and selection. I genuinely had no idea, when I tapped Docs,
whether I'd got that or Demo. Scrolling the next page moved the content up,
but also the header, while leaving the left side navigation in place.

~~~
malandrew
I totally understand how our mobile site gives a poor impression.

We're aware of this, but FWIW, we haven't really spent much time on the mobile
site at all given other priorities and because there really isn't much if any
content on there that provides utility in a mobile use context. Most of our
work at the moment is focused on Famous University (desktop only). We'll fix
the mobile experience as soon as we wrap up the more pressing parts.

If you want a real world example to try out and judge us one, install the
chrome app Beepe.me. Plugg.me is another app, but I don't think it's been
released yet.

[https://beepe.me/getstarted](https://beepe.me/getstarted)
[http://www.plugg.me/](http://www.plugg.me/)

------
dotnetkow
Great article from 37signals. I built my app for Fitbit, Fitwatchr
([https://itunes.apple.com/us/app/fitwatchr/id684005201?mt=8&u...](https://itunes.apple.com/us/app/fitwatchr/id684005201?mt=8&uo=4)),
using web tech only. I leveraged PhoneGap for native access (OAuth via an
InApp browser and Google Analytics) via plugins, PhoneGap Build for native
iOS, Android and Windows Phone 8 builds, and KendoUI Mobile to achieve native
looking UI for all (handled mostly automatically!). They are correct - in 2010
the technology, tools, or performance may not have been quite there yet, but
in 2014 things are much more viable.

------
ksec
I think there is this luxury where the targeted users, or audience of
Baasecamp may actually have the higher end Phones. So the 5/5c or definitely
5S will be fast enough.

But there are an Ocean of cheap / slow and older phones out there, which i
dont think they will have quite the same experience if it was in Web compared
to Native.

The Gap will shrink, as technology moves forward. But for the best experience
around, may be its best to stick to native for now.

------
jackschultz
He goes through all of the pros and cons of this approach, but doesn't mention
which framework they used for the html portion (unless they rolled their own
in which case might as well go all native). There are so many different
frameworks it seems (Phonega, Cordova, Trigger etc), does anyone out there
have a rundown of all the different ones and the quality of each?

~~~
zachwaugh
We're not using a framework. The app itself is a standard Cocoa/Objective-C
app, just using a mix of web views and native views for rendering the content
of individual screens.

------
ljoshua
Has anyone used AppGyver, which seems to be a framework that incorporates this
combo of native navigation with WebViews and Cordova? I've been working solely
on the HTML components of an app, nav included, but would love to hear
anyone's experience.

~~~
pcardoso
Plugging my own work here, but I wrote a blogpost about how to do such a
system from scratch on iOS.

[http://luminescente.com/2014/03/how-to-build-your-own-
phoneg...](http://luminescente.com/2014/03/how-to-build-your-own-phonegap-
clone-on-ios/)

I'm also writing a book on the subject, there's a link to it at the bottom.

Any feedback appreciated.

~~~
jordanlev
Pretty cool, thanks! Here is some feedback: * Overall it's great. * The
instructions on where to input the code starts out very precise, but as the
piece goes on it gets sloppier. For example, "Open WebViewController.m and
after the viewDidLoad method, after the comment, add this new method" is not
entirely accurate, because you're adding the new method AFTER the existing
method, not after the comment inside the existing method (fortunately the
screenshot is there to show what you mean). And the very last code sample (for
the loading indicator) doesn't actually have a code sample, just the
screenshot. * I was not able to get forward/backwards swiping to work -- but
perhaps this is just a limitation of the simulator?

Definitely looking forward to seeing a more fleshed-out version. Thanks!

~~~
pcardoso
Thanks! Points taken. I will review the text to make it more accurate and
clear. Seems appropriate since I'm trying to do a "Clear Hybrid Apps" ebook.
:)

To swipe forward/back you have to drag from the exact edge which on the
simulator takes some practice.

------
zaidf
I'm curious how they get away with having basically 100% of their app as web-
based. We used native controls for login screen and another screen to play it
safe. Are we playing too safe?

------
rimantas
If native development is slow compared to the HTML, you are doing something
horribly wrong.

