According to a recent report1, HTML is the most widely used language for mobile app developers. The main reasons among developers for selecting web technologies2 is cross-platform portability of code and the low cost of development. We’ve also heard that hybrid apps tend to be sluggish and poorly designed. Let’s prove whether it’s possible to deliver the native look and feel that we’re used to.
What Are Hybrid Mobile Apps?
Mobile apps can be generally broken down into native, hybrid and web apps. Going the native route allows you to use all of the capabilities of a device and operating system, with a minimum of performance overhead on a given platform. However, building a web app allows your code to be ported across platforms, which can dramatically reduce development time and cost. Hybrid apps combine the best of both worlds, using a common code base to deploy native-like apps to a wide range of platforms.
There are two approaches to building a hybrid app:
- WebView app
- Compiled hybrid app
While both approaches are widely used and exist for good reasons, we’ll focus on WebView apps because they enable developers to leverage most of their existing web skills. Let’s look at all of the benefits and drawbacks of hybrid apps compared to both native and mobile web apps.
- Developer can use existing web skills
- One code base for multiple platforms
- Reduced development time and cost
- Easily design for various form factors (including tablets) using responsive web design
- Access to some device and operating system features
- Advanced offline capabilities
- Increased visibility because the app can be distributed natively (via app stores) and to mobile browsers (via search engines)
- Performance issues for certain types of apps (ones relying on complex native functionality or heavy transitions, such as 3D games)
- Increased time and effort required to mimic a native UI and feel
- Not all device and operating system features supported
- Risk of being rejected by Apple if app does not feel native enough (for example, a simple website)
These drawbacks are significant and cannot be ignored, and they show that the hybrid approach does not suit all kinds of apps. You’ll need to carefully evaluate your target users, their platforms of choice and the app’s requirements. In the case of many apps, such as content-driven ones, the benefits outweigh the drawbacks. Such apps can typically be found in the “Business and Productivity,” “Enterprise” and “Media” categories in the app store.
Both Hojoki and CatchApp are very content-driven productivity apps, so we initially thought they would be a great match for hybrid development. The first three benefits mentioned above were especially helpful to us in building the mobile app for Hojoki in just four weeks8. Obviously, that first version lacked many important things. The following weeks and months were filled with work on optimizing performance, crafting a custom UI for each platform and exploiting the advanced capabilities of different devices. The learning in that time was crucial to making the app look and feel native. I’ll share as many lessons as possible below.
So, how do you achieve a native look and feel? To a mobile web developer, being able to use the features of a device and operating system and being able to package their app for an app store sounds just awesome. However, if users are to believe it is a native app, then it will have to behave and look like one. Accomplishing this remains one of the biggest challenges for hybrid mobile developers.
Make Your Users Feel at Home
A single code base doesn’t mean that the app should look and feel exactly the same on all platforms. Your users will not care at all about the underlying cross-platform technology. They just want the app to behave as expected; they want to feel “at home.” Your first stop should be each platform’s design guidelines:
- “iOS Design Resources9,” iOS Developer Library
- “Android Design10,” Android Developers
- “Design11,” Windows Dev Center
While these guidelines might not perfectly suit all kinds of apps, they still provide a comprehensive and standard set of interfaces and experiences that users on each platform will know and expect.
DIY vs. UI Frameworks
Implementing all of these components, patterns and animations on your own can be quite a challenge. All kinds of frameworks exist to help you with that, ranging from commercial (Kendo UI12) to open-source ones (Ionic13) and from ones with a common UI (jQuery Mobile14 and Onsen UI15) to many platform-specific UIs (Sencha Touch7716 and ChocolateChip-UI17). Some are really good at providing a pixel-perfect layout, while others are rather sloppy, thus making it easy for the user to identify a web app. However, my impression is that their main drawbacks are performance-related, because most UI frameworks try to be as all-embracing as possible. Judge for yourself by taking a few minutes to try the demos on your own device.
Custom UI Components
Custom UI components also have many good use cases. Deciding between a platform’s UI and a custom UI will obviously depend on your target audience. If you want to do your own thing, you should have a deep understanding of UX design, because the guidelines linked to above were crafted by experts to meet the particular requirements of their platform’s users.
Whether you stick to a platform’s UI guidelines or do your own thing with custom components, know that there are certain design patterns that most people use every day and love. How are people usually introduced to a new app? Through a slideshow walkthrough or an instructional overlay. How do people navigate? With a tab bar or a sidebar drawer18. How do users quickly load or refresh data? By pulling to refresh. (Native-like scrolling will be covered extensively further below.)
Resources for Mobile UI Design
- “Mobile UI Design Patterns: 10+ Sites for Inspiration19,” Jacob Gube, Six Revisions
- “Tapping Into Mobile UI With HTML521” (slides), Luke Melia and Yael Sahar, Slideshare
Design A Native-Looking Header Bar
One important part of a UI is the header bar, with its title and navigation elements, most notably the “up” and “back” buttons. To me, many popular frameworks fail to provide a HTML and CSS solution that compares to a native app. Mimicking this part of the UI with a minimal DOM and a few lines of CSS for each platform is actually fairly easy:
<header> <button class="back">Feed</button> <h1>Details</h1> <!-- more actions (e.g. a search button on the right side) --> </header>
Check out the full code of the native-looking header bar for iOS, Android and Windows Phone22 on JSFiddle. This is my result:
Using the same DOM across all platforms is generally preferable because it results in cleaner code and, therefore, maximizes maintainability. I’ve found this to be easily possible for many UI components on iOS and Android (including the header bar, tab bar, custom navigation menu, settings page, popover and many more). However, this becomes much harder when adding support for Windows Phone, which comes with some very different design patterns.
Support High-Resolution Screens
Nowadays, smartphones and tablets with high-resolution screens make up the vast majority of mobile devices, making up more than 80% of iOS devices23 and over 70% on Android devices24. To make your images look crisp for everyone, you usually have to deliver twice the dimensions than what is actually shown in your app. Serving properly sized images for all different resolutions is one of the most discussed topics in responsive web design. There are various approaches, each with its benefits and drawbacks related to bandwidth, code maintainability and browser support. Let’s quickly review the most popular ones, in no particular order:
- server-side resizing and delivering
- CSS media queries
- Resolution-independent images (SVG)
As always, there is no silver bullet for responsive images. It pretty much depends on the type of images and how they are used in the app. For static images (such as the logo and tutorial images), I try to use SVG. They scale perfectly without any extra effort and have great browser support as long as you’re fine with Android 3+25.
When SVG is not an option, the HTML5
picture element and
srcset attributes26 are definitely where front-end development is heading. Currently, their main drawback is the very limited browser support and, therefore, their need for polyfills.
/* Normal-resolution CSS */ .logo width: 120px; background: url(logo.png) no-repeat 0 0; /* HD and Retina CSS */ @media only screen and (-webkit-min-device-pixel-ratio: 1.25), only screen and ( min--moz-device-pixel-ratio: 1.25), only screen and ( -o-min-device-pixel-ratio: 1.25/1), only screen and ( min-device-pixel-ratio: 1.25), only screen and ( min-resolution: 200dpi), only screen and ( min-resolution: 1.25dppx) .logo background: url(firstname.lastname@example.org) no-repeat 0 0; background-size: 120px; /* Equal to normal logo width */ }
However, your app might already contain a lot of content (such as news articles), and adjusting all of the
img tags or replacing them with CSS would be exhausting. A server-side solution is the best choice in this case.
Starting last year, more and more Android manufacturers have gone one step further with what is called XXHDPI (or very very high-resolution) screens. Whichever solution above fits your need, keep in mind that you’ll need images that are three times the original dimensions to support Android’s latest flagship devices.
Use System Fonts
A simple yet important way to make users feel at home is to use system fonts.
These are my recommended font stacks on the major platforms:
/* iOS */ font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; /* Android */ font-family: 'RobotoRegular', 'Droid Sans', sans-serif; /* Windows Phone */ font-family: 'Segoe UI', Segoe, Tahoma, Geneva, sans-serif;
Furthermore, iOS 7 offers some interesting presets that automatically set the correct font family, font size and line height. It’s as easy as using
font: -apple-system-body for normal text and
font: -apple-system-headline for headings. This not only simplifies font declarations, but also improves accessibility through “dynamic type31,” Apple’s system-wide font-size setting. You can dig deeper into iOS 7 font presets in a post by Thomas Fuchs32.
An Icon Is Worth A Thousand Words
Iconography is an important part of the user experience on all major mobile platforms. As with fonts, you’re usually best off using icons that your target audience already knows. Recalling what I said about high-resolution screens earlier, make sure that your icons are scaleable. Implementing them as a font via CSS’
@font-face rule is a great way to achieve this, and it comes with wide browser support33. It even allows you to change an icon’s appearance (for example, its color, shadow and transparency) seamlessly via CSS. Here are my recommendations:
- Get various platform icon fonts.
Ionicons34 is our baseline set because it includes nearly everything we need. This includes specific icons for iOS and Android in addition to their general ones. The rest come from specific platform icon fonts for iOS35, Android set 136 and set 237 and Windows Phone38.
- Combine them with a icon font generator.
Using multiple icon fonts is confusing and quickly adds up in size. That is why we use Fontello39 to combine the different sets, adjust key codes and export them for each platform. The result is
<span class="icon">s</span>, which looks like a search icon on iOS, Android and Windows Phone, respectively. Also, check out the popular alternatives IcoMoon40 and Fontastic41.
On Windows Phone, you can also get away with the native
font-family: 'Segoe UI Symbol'42.
Optimize For Performance
- “Performance and UX Considerations for Successful PhoneGap Apps43,” Andrew Trice
- “Mobile: Web Performance44” (slides), Estelle Weyl
- “Minimizing Browser Reflow46,” Lindsey Simon, Google Developers
- “How to Make Your Website Faster on Mobile Devices47,” Johan Johansson, Smashing Magazine
Beyond that, mobile hardware and rendering engines are improving at a rapid pace, with new devices coming out every other day. Developers can make the performance of a hybrid WebView app difficult to distinguish from that of a fully native app on the iPhone 5 series and on Android phones comparable to Nexus 4 and 5.
Increase Perceived Speed
Building a performant app is one thing, but making it feel fast is a whole other. Whether your app needs some time for a certain task (such as some heavy calculation or client-server communication), presenting instant feedback is crucial to providing a fluid and responsive experience. A common technique is to delay tasks that the user doesn’t need yet, while predicting and preloading the steps the user might take next. A famous example is Instagram, which uploads photos in the background48 while the user is busy adding tags and sharing. Perceived speed can be very different from actual speed, so let’s use it in our favor. Here are some no-brainers.
Remove the Click Delay on Touch Devices
if ('ontouchstart' in window) window.addEventListener('load', function() FastClick.attach(document.body); , false); }
Internet Explorer 10+ is a bit easier. You just need some CSS:
html -ms-touch-action: manipulation; /* IE 10 */ touch-action: manipulation; /* IE 11+ */
Style the Active State
As soon as the user taps an actionable element such as a button or a link, they should immediately get some kind of feedback that the app has detected their action. While the CSS pseudo-class
:hover works great for this on the desktop, you need to switch to
Furthermore, remove the default tap highlight while adjusting your active states on mobile. I’d also recommend disabling user selections on actionable elements, because the selection menu would be quite disruptive if the user accidentally taps the button for too long.
iOS and Android:
button outline: 0; -webkit-tap-highlight-color: rgba(0,0,0,0); -webkit-tap-highlight-color: transparent; -webkit-touch-callout: none; -webkit-user-select: none; -moz-user-select: none; -ms-user-select: none; user-select: none;
Windows Phone 8+:
<meta name="msapplication-tap-highlight" content="no">
Cross-platform tools like PhoneGap and Trigger.io also provide access to native loaders, which is great for showing a full-screen loading animation.
Get the Scrolling Right
Scrolling is one of the most important factors in the user experience of many apps. This is both a curse and a blessing because the success of its implementation will depend heavily on the scrolling niceties that your app relies on and on the mobile operating systems that need to be supported.
Scrollable content and a fixed header and/or footer bar are common to nearly all apps. There are two common approaches to achieving this with CSS:
- Enabling scrolling on the
body, and applying
position: fixedto the header;
- Disabling scrolling on the
body, and applying
overflow: scrollto the content;
- Disabling scrolling on the
While the first option has some benefits (such as iOS’s native scroll-to-top action and a simple code structure), I highly recommend going with the second option,
overflow: scroll. It has fewer rendering issues54 (although still a lot), and browser support is great on modern platforms (Android 4+, iOS 5+ and Windows Phone 8+), with a nice little polyfill for some older ones55. Alternatively, you could replace
rgba) in the content area.
Let’s look at some of the basic scrolling features.
The touch-friendly momentum effect enables users to quickly scroll through large content areas in an intuitive way. It can be easily activated with some simple CSS on iOS 5+ and in some versions of Chrome for Android. On iOS, this will also enable the content to bounce off the top and bottom edges.
overflow-y: scroll; -webkit-overflow-scrolling: touch;
Pull Down to Refresh
Scroll to Top
Unfortunately, disabling scrolling on the
Many other scrolling features could be implemented on top of the native
Make It Easy To Hit Stuff
When performing a touch action, users will quite often miss their target by a few pixels, especially on small buttons (such as the ones in iOS’ top bar). Developers can assist users while keeping the design elegant by enabling an invisible touch area around small targets:
<button> <div class="innerButton">Click me!</div> </button>
Using Touch Gestures
Don’t Miss Out on Native Functionality
Building your app with web technology doesn’t necessarily mean that you can’t use native features. In fact, all major cross-platform development tools provide built-in access to the most important functionality. This includes APIs for device data, the file system, the network connection, geolocation, the accelerometer, notifications (including push) and much more.
focus() for input fields on iOS 6+:
if ([[[UIDevice currentDevice] systemVersion] floatValue] >= 6) [YourWebView setKeyboardDisplayRequiresUserAction:NO];
And here’s the code to copy a given string to the device’s clipboard on iOS:
[[UIPasteboard generalPasteboard] setString:@"Your copied string"];
Always Provide a Way Out
Web developers often overlook how to handle bad situations in a hybrid app (for example, a connection timeout, a bad input, a timing issue, etc.). A hybrid app is fundamentally different from a website, mainly because there is no global refresh button, and an app can easily run in the background for weeks on some mobile operating systems. If the user runs into a dead end, their only option will be to restart the app, which entails force quitting and then restarting. Many people don’t even know how to do that, especially on Android 2.x (where it’s hidden deep in the app’s settings) and on iOS 6 and below (where you have to double-tap the home button, long-press the icon and kill it).
So, ignore the refresh button during development, and handle bad situations as they come up. For all other situations that would have unexpected outcomes, such as ones involving client-server communication, be prepared for things to go wrong, and provide a way out for users. This could be as easy as showing a full-screen error message — “Oops! Something bad happened. Please check your connection and try again” — with a big “Reload” button below.
How To Wrap It
A few cross-platform development tools provide that native bridge and simplify the whole process of wrapping it. Let’s dive into some options.
PhoneGap and Apache Cordova
Both are open-source and free to use, with support for all major platforms and with an active community developing all kinds of plugins and extensions.
PhoneGap has shaped the hybrid lanscape significantly, and many new tools have emerged that offer additional services or that streamline the development process. They usually add a lot of convenience by enabling you to build an app in the cloud, thereby saving you the effort of locally installing all of the different platform SDKs and tools. Each tool has a different focus, level of platform support and price:
- PhoneGap Build71
- Telerik AppBuilder72 (formerly Icenium)
- AppGyver Steroids73
- Appery.io74 (formerly Tiggzi)
- Intel XDK76
Sencha Touch7716 started out as a UI framework for the mobile web and has been around for years. Traditionally, developers have used Sencha to build an app while using another service, like PhoneGap, to deploy it as a hybrid app. Nowadays, Sencha offers this kind of functionality built in for free. Platform support includes iOS and Android (both via Sencha’s own native packager) BlackBerry, Windows 8 and more (via PhoneGap Build).
At Hojoki, we started using Trigger.io78 two and a half years ago because we were looking for a lightweight alternative to PhoneGap. Even though iOS and Android are its only supported platforms, it offers a good set of native APIs, custom plugins and third-party integration (including Parse push notifications, Flurry analytics and parts of Facebook’s SDK). Trigger.io’s command-line tools allowed us to integrate the app’s packaging into our Grunt79 build process, which is great if you love automation.
Test on Real Devices
Building a mobile app with web technologies obviously tempts us to do most of our testing in a web browser. This might be fine when developing non-native features, but definitely avoid it when releasing. Test with as many manufacturers, platforms and form factors as possible before submitting the app. Android’s fragmentation brings endless possibilities of differences in browser rendering, unsupported features and manufacturer modifications. While iOS does much better with rendering differences, Apple has a growing number of devices with varying sizes, resolutions and pixel densities. Check out “Prioritizing Devices: Testing and Responsive Web Design84” to learn more.
When Facebook famously ditched most of its HTML5 and went native in 2012, it cited missing debugging tools and developer APIs85 as one of its main reasons. LinkedIn drew the same conclusions86 half a year later, stating that HTML5 itself is ready, but basic tools and the ecosystem don’t support it yet. From what I’m seeing, the situation is getting better, with remote debugging in WebView on Android 4.4+ and an increasing number of development tools on all platforms:
- “Web Inspector87,” Safari (iOS)
- “Remote Debugging on Android with Chrome88”
- “Debug Store Apps in Visual Studio89” (Windows Phone 8.1), Windows Dev Center
- Weinre90 (for everything), Patrick Mueller
- Edge Inspect91 (for iOS and Android), Adobe
Start Thinking in Terms of Hard Releases
When building an app for web browsers, deploying a hot fix to users is a simple step, which means that testing can lose some of its importance. This obviously needs to be reconsidered when you’re releasing an app through an app store. Think of it like software development in the ’90s: You’re now living in the world of hard releases.
So, why is this bad? First, the submission process could easily take a week or two (Hello, Apple!). Secondly, even if your hot fix is released quickly, that doesn’t guarantee that users will update the app any time soon. Here are my suggestions:
- Make testing a high priority.
- Have some kind of “force update” logic to deprecate old client versions.
- Use mechanisms like Trigger.io’s Reload9280 to fix code on the fly.
- Apply for an expedited app review93 (Apple only) if you need to be fast.
Get It in the Stores
The tools mentioned above spit out a binary for each platform, which can then be submitted to the relevant store. From this point on, the process is exactly the same as publishing a “normal” native app. Some of the tools we’ve looked at might even have better documentation for this. Nevertheless, here are the official guides:
- “App Distribution Guide94,” Apple
- “Get Started With Publishing95” and “Launch Checklist96,” Android Developers
- “Publish for Windows Phone97,” Windows Dev Center
Now that our hybrid mobile apps have been in Apple’s App Store and in Google Play for two years, I’d like to recapitulate some of the benefits and drawbacks mentioned at the beginning of this article.
For us, a web startup company with very limited resources and no native iOS or Android experience, building an app for multiple platforms in just a few weeks would have been impossible. Choosing the hybrid path enabled us to reuse a lot of code from the web app and to iterate quickly based on user feedback. We’ve even managed to publish native apps for Windows 8 for the desktop and Microsoft Surface as well as Mac OS X with exactly the same code base. The effort of moving to another platform will depend largely on the capabilities of the given browser and device and on the level of your need for native functionality. We needed push notifications, in-app purchases and access to the user’s contacts, among other things. Depending on your needs, a lot of native functionality could make you heavily dependent on the native wrapping tool that you choose.
Finally, let’s see whether hybrid apps really can deliver a native look and feel. Below is a compilation of user reviews from the app stores. Both positive and negative comments are included, but many of the negative reviews are for early releases, which had the same UI for all platforms and was comparatively slow in performance.
★ Great idea, but not a good app. The app runs extremely slow on my Samsung Galaxy Ace and Tab. The app also looks and controls like an iPhone app. This is confusing when you have never had an iPhone.
★★ Another reason apps should not use WebViews for UI.
★★ Service great but WebView app sucks.
★★★ It’s the right app in concept, but it really is too laggy to be practically used. And I’m using Jellybean so there is no excuse.
★★★ It lags a lot and the UI is not beautiful.
★★★ Good but very very slow.
★★★★ This app is very handy, but is a little slow to boot up.
★★★★★ This is working really hard well since the update. It’s a great app to begin with and now it’s working smoother and faster than before.
★★★★★ Extremely smooth and effective.
★★★★★ The app work flawlessly…
★★★★★ Beautiful designed app! Love the interface and the great overview of all your tools! Good job! Keep shippin!
★★★★★ This is an absolutely beautiful aggregate that runs buttery smooth, even on a 3GS. Recommend to anyone doing any sort of project.
We’re definitely moving away from platform-specific app development and towards the many new technologies that are emerging. Larry Page said this98 when asked at Google I/O last year about the future of the web:
In the very long term, I don’t think you should have to think about, as a developer, am I developing for this platform or another, or something like that. I think you should be able to work at a much higher level, and software you write should run everywhere, easily.
The (mobile) web is a major success story in this regard. Being able to use this platform and still be able to distribute an app in all stores is a huge step forward. It will be interesting to see how this all plays out. Whatever happens, using a technology that over a third of the world’s population99 (over two thirds in Europe and the US) relies on probably won’t be a bad choice.
(da, al, ml)
- 1 http://www.visionmobile.com/product/developer-economics-q3-2014/
- 2 http://www.visionmobile.com/product/developer-economics-2013-the-tools-report/
- 3 http://www.phonegap.com
- 4 http://www.trigger.io
- 5 https://xamarin.com/
- 6 http://www.appcelerator.com/titanium/
- 7 http://www.embarcadero.com/products/rad-studio/fmx
- 9 https://developer.apple.com/library/ios/design/index.html
- 10 http://developer.android.com/design/index.html
- 11 https://dev.windowsphone.com/design
- 12 http://www.telerik.com/kendo-ui
- 13 http://ionicframework.com/
- 14 http://jquerymobile.com/
- 15 http://onsenui.io/
- 16 http://www.sencha.com/products/touch/
- 17 http://chocolatechip-ui.com/
- 18 https://github.com/jakiestfu/Snap.js
- 19 http://sixrevisions.com/user-interface/mobile-ui-design-patterns-inspiration/
- 21 http://de.slideshare.net/yaelsahar/tapping-into-mobile-ui-with-html5
- 22 http://jsfiddle.net/prud/dnebx02p/
- 23 http://david-smith.org/iosversionstats/#retina
- 24 http://developer.android.com/about/dashboards/index.html#Screens
- 25 http://caniuse.com/#feat=svg
- 26 http://responsiveimages.org/
- 27 http://www.uifuel.com/hd-retina-display-media-queries/
- 28 http://iosfonts.com/
- 29 http://developer.android.com/design/style/typography.html
- 30 http://msdn.microsoft.com/library/windows/apps/hh700394.aspx#ux_font_choice
- 31 http://support.apple.com/kb/HT5956
- 32 http://mir.aculo.us/2013/09/16/how-to-create-a-web-app-that-looks-like-a-ios7-native-app-part-1/
- 33 http://caniuse.com/#feat=fontface
- 34 http://ionicons.com/
- 35 http://ios7-icon-font-demo.herokuapp.com/
- 36 http://www.spiderflyapps.com/downloads/android-developer-icons-the-font/
- 37 https://github.com/Turbo87/Android-Action-Bar-Icon-Pack-Font
- 38 http://modernuiicons.com/
- 39 http://fontello.com/
- 40 https://icomoon.io/app
- 41 http://fontastic.me/
- 42 msdn.microsoft.com/library/windows/apps/jj841126.aspx
- 43 http://www.tricedesigns.com/2013/03/11/performance-ux-considerations-for-successful-phonegap-apps/
- 44 http://estelle.github.io/mobileperf/
- 46 https://developers.google.com/speed/articles/reflow
- 47 http://www.smashingmagazine.com/2013/04/03/build-fast-loading-mobile-website/
- 48 http://www.cultofmac.com/164285/the-clever-trick-instagram-uses-to-upload-photos-so-quickly/
- 49 https://github.com/ftlabs/fastclick
- 50 http://jsfiddle.net/prud/x9y6cfhg/
- 51 http://fgnass.github.io/spin.js/
- 53 http://tympanus.net/codrops/2012/11/14/creative-css-loading-animations/
- 54 http://remysharp.com/2012/05/24/issues-with-position-fixed-scrolling-on-ios/
- 55 https://github.com/filamentgroup/Overthrow#browser-support
- 56 http://iscrolljs.com/
- 57 http://damien.antipa.at/2012/10/16/ios-pull-to-refresh-in-mobile-safari-with-native-scrolling/
- 58 http://damien.antipa.at/2012/10/16/ios-pull-to-refresh-in-mobile-safari-with-native-scrolling/
- 59 http://androidwidgetcenter.com/android-tips/how-to-refresh-gmail-on-android/
- 60 http://dwcares.com/pull-to-refresh-2/
- 61 https://github.com/prud/ios-overflow-scroll-to-top
- 62 http://jsfiddle.net/prud/r7kqr1a3/
- 63 http://quojs.tapquo.com/
- 64 http://hammerjs.github.io/
- 66 http://www.smashingmagazine.com/wp-content/uploads/2013/05/07-hybrid-app-opt.jpg
- 67 http://www.smashingmagazine.com/wp-content/uploads/2013/05/07-hybrid-app-opt.jpg
- 68 http://phonegap.com/
- 69 http://phonegap.com/2012/03/19/phonegap-cordova-and-what%E2%80%99s-in-a-name/
- 70 http://cordova.io
- 71 https://build.phonegap.com/
- 72 http://www.telerik.com/appbuilder
- 73 http://www.appgyver.com/
- 74 http://appery.io/
- 75 http://monaca.mobi
- 76 https://software.intel.com/html5/tools
- 77 http://www.sencha.com/products/touch/
- 78 https://trigger.io
- 79 http://gruntjs.com/
- 80 https://trigger.io/reload/
- 81 http://docs.build.phonegap.com/en_US/tools_hydration.md.html
- 82 https://trigger.io/pricing/
- 83 http://www.mosync.com/
- 84 http://www.smashingmagazine.com/2014/07/14/testing-and-responsive-web-design/
- 85 http://lists.w3.org/Archives/Public/public-coremob/2012Sep/0021.html
- 86 http://venturebeat.com/2013/04/17/linkedin-mobile-web-breakup/
- 87 https://developer.apple.com/safari/tools/
- 88 https://developer.chrome.com/devtools/docs/remote-debugging
- 89 http://msdn.microsoft.com/en-us/library/windows/apps/hh441472.aspx
- 90 http://people.apache.org/~pmuellr/weinre/
- 91 http://html.adobe.com/edge/inspect/
- 92 https://trigger.io/reload/
- 93 https://developer.apple.com/appstore/contact/appreviewteam/index.html
- 94 https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/Introduction/Introduction.html
- 95 http://developer.android.com/distribute/googleplay/start.html
- 96 http://developer.android.com/distribute/tools/launch-checklist.html
- 97 http://msdn.microsoft.com/library/windows/apps/jj206736.aspx
- 98 http://youtu.be/9pmPa_KxsAM?t=2h56m6s
- 99 http://en.wikipedia.org/wiki/List_of_countries_by_number_of_Internet_users
The post Hybrid Mobile Apps: Providing A Native Experience With Web Technologies appeared first on Smashing Magazine.