Using the Device Clipboard in React Native


As a quickly evolving library, React Native is often supplemented by features from the community, only to consume them or incorporate similar concepts later on.

Up until a few months ago, using the native clipboard on iOS or Android meant installing an npm module and then configuring the native components in each device environment (configuring the library in XCode or modifying your configuration for Android).

It wasn’t a huge burden, but it still required some platform specific knowledge and a few extra steps beyond being able to just plug and play with the module.

Existing packages

If you’ve tried using the native clipboard before in a React Native project you’ve probably used one of the two main libraries available for it: react-native-clipboard (iOS and Android) and react-native-pasteboard (iOS only).

With release 0.17 of React Native, those packages are no longer necessary. We now have a Clipboard component which works seemlessly for both iOS and Android.

How to use it

The functionality is as straight forward as it gets. There are no configuration file changes or library linkages required. Just import from the react-native package and go to town.

Here’s how to import the component using the ES6 import syntax

  import React, {Clipboard} from 'react-native';

Then to set a value to the device clipboard call #setString

  Clipboard.setString('my string');

Getting the current value is a tiny bit more work, as it’s returned asynchronously in a promise returned from #getString

  Clipboard.getString().then(function (content) {

And if you want to use the ES7 await/async functionality (which React Native ships with enabled by default), it looks like this

  async function getString() {
    console.log(await Clipboard.getString());

Just remember that your code has to be in the context of an async function for await to work properly.

The whole example

  import React, {Clipboard} from 'react-native';
  Clipboard.setString('my string');
  Clipboard.getString().then((content) => {

Now with only a few lines of code you can set a value to the device clipboard, and retrieve it.

And that’s it. Go forth and copy/paste.

React Native impressions from a Cordova user


As web developers, we see the potential that the web offers, as a platform and as a cross platform development environment. I don’t think it’s a desire for sameness or lack of imagination that propels web technologies across device targets, but the potential and power of what those tools can provide.

But being so ubiquitous means that solutions often fall short or feel off in comparison to what a platform provides natively. Native application development vs development using a web stack is a source of constant debate, and generally when tested at the extremes, web technology struggles to hold up to what a native experience can offer.

The gap is closing. Cordova has been a great environment, but as a baseline it is difficult to achieve the same level of polish and native feel that comes more natural from a native application. Frameworks like Ionic and Framework 7 make bridging that gap much easier. Their creators and developers have taken the time to polish and provide a set of tools, interactions and widgets so you don’t have to try and build it from scratch every time (and often fall short in trying).

But what if we could utilize our familiarity with part of the web stack (javascript) to delivery something truly native? A seamless experience delivered by web tech but not bound by it.

React native might be the answer to doing just that.

Where I’m Coming From

Talking about React Native as someone who uses web technologies in almost all of my development, a meaningful comparison would reference back to that tech. When is and how is React Native more compelling than what the competition offers?

What makes it a better alternative to a tool like Cordova matched with Ionic or Framework7? What are its clear strengths? Where is it lacking and where will it improve? That’s what i’m trying to answer for myself, and explore in the rest of this post.

A Very Brief History

React is the base library that powers React Native, and is a view layer, written in Javascript, and originally created by engineers at Facebook. Since its initial release in 2014 it has risen in popularity quickly (32K stars on github and rising) and people have been embracing its model. You write all of your view layer in their abstractions, and let them manage rendering to the appropriate format. They manage your UI and the flow of your data in an optimized way.

We’re seeing them refine React into a reusable base library, and extract the view implementations into their own modules (they recently removed all DOM related logic and created a new package – react-dom – to handle that for the web side of things). In addition to react-dom in the browser, people are using React for server-side rendering, and Flipboard recently came out with react-canvas – which writes your UI directly to the canvas tag. These are just a few examples of React view implementations taking the base React layer and applying it across different environments.

The obvious momentum here is towards reusing the React architecture to output to different formats. React Native takes these same principles, and applies it to the native app environment.

Why React Native

Learn Once, Write Anywhere

“The focus of React Native is on developer efficiency across all the platforms you care about — learn once, write anywhere.” (

With the ability to learn all of the react principles and patterns, and then apply those to whatever view abstraction can be written, you’re able to take all of that knowledge and apply it on multiple views and across different platforms. Not just platforms that contain a browser but any platform where javascript can be run.

You know react from using it in other environments, and you’re now able to leverage that to build a native app. The components are different, how it functions is different, but the concepts are all the same.

Truly native

Everything you use in React Native is, behind the scenes, a native UI component. Many of the features that native developers are accustomed to on Android and iOS are available to you in their actual forms.

My understanding is that React Native makes this possible by serializing communications from your Javascript layer to a native layer, where the UI work is accomplished. Your javascript SwitchIOS component is a native iOS switch. Same for your MapView and ListView. It’s all first-class with the rest of the app environment. You define what you want to use in Javascript, and React Native handles the communication and implementation of how it is rendered.


The result is a larger ecosystem of code you can lean on, as well as out of the box improved performance.


One of the top reasons to use React Native is for performance. Because your javascript is communicating instructions to actual native code, you are able to operate at near native speeds. Your animations, gesture recognition and layout rendering will all be faster with no additional effort on your part.

Knowing that you are getting these out of the box gains, the main concern you are left with is keeping your javascript code running lean. Javascript operations are batched up and then sent to the native layer, but if your processing takes too long you can miss some of those communication windows and cause visibly degraded performance.

The React Native’s team is heavily focused on getting the best performance out of every aspect of the library they control. As part of their developer tools you can actually monitor the framerates of both your native UI and javascript threads, which helps to debug where a slowdown might be occurring.

perf monitoring

First Class Native Projects + Keeping up with iOS/Android updates

With a React Native project your generated iOS and Android applications are a first-class part of your development and source control. The obvious benefit here is unobstructed control of all of your application settings and libraries.

In the Cordova model, your “platforms” (the implementation of code for a given operation system like iOS and Android) are read-only and are not intended to be source controlled. The output of that generated code is controlled from generic configuration files within your project.

The Cordova approach is a double edged sword because while you are benefiting from the generic cross-platform nature of your configuration files, you can also lag behind new developments and be forced to wait on Cordova updates or make modifications to the runtime yourself. Recently there were issues with the introduction of Application Transport Security in iOS 9, which meant having to use some hacks to get around the problem until Cordova could release an update to address it (which took some time).

Using React Native you trade off the generic configurability of Cordova for full project control.


The React Native community is growing fast. Much like the React community, React Native is garnering tons of attention and contribution. As of this writing they have around 24k github stars, and new modules are coming out for it every week.


It doesn’t feel quite like an ecosystem yet as much as a large group of people excitedly producing code. There are a number of React Native modules started and abandoned, many of the modules are not mature enough yet, and they’re working on a moving target. The React Native team is doing a good job avoiding massive breaking changes, but the framework is young and these things are to be expected.

App Reloads / Dev Tools

Ability to reload from the app was awesome, and something Cordova and Ionic are only just starting to offer.

You can bring up and options menu while running your application in real-time, and it comes with several options including live code reload, remote debugging from your browser, and performance statistics of your running code.


Touch Events

The gesture system in React Native is a rich and complicated aspect of the library. They claim that the touch interaction offered by the web is a big usability issue, and that “Users can feel huge differences in the usability of web apps vs. native” ref.

I’ve seen and worked with some great touch interactions in a web context – but I believe them that there is more the user could be offered. I just haven’t seen the value in action yet. The “Gesture Responder System” is a fairly dense API and I haven’t gone beyond basic tap interactions with it so far.

UI Flow

Everything being native, the flow and styling of your application is very consistent. Contrast this with trying to integrate a native component into a Cordova application and it’s a very different experience. Bringing in something like the native Map component and trying to style it into a completely different UI paradigm (your webview) can be confusing and the precedence of elements unclear.

In React Native, it’s as easy as laying out your components and styling them using a subset of CSS that you define in your javascript. The components interact and flow with each other naturally with no magic involved, because everything is speaking the same language.

Where it’s the only option

One of the most interesting aspects of React Native is its ability to go places that standard web technologies cannot.

Up until a year ago, Cordova was still an option for all the common “smart” technologies that people used: phones and tablets for Android, iOS, Windows Phone (even Amazon FireOS, Firefox OS, Blackberry, and more). But it wasn’t until the Apple Watch came out that hybrid developers found themselves at a loss. Watch OS 1 and Watch OS 2 do not support UIWebView.

Around six months later Apple released tvOS. Another platform intentionally missing UI and WKWebView.

There is a reasonable explanation for why they’re excluding webviews: they just don’t make sense on those platforms. The reason they include webviews is to be able to display web content. But interacting with a web page on your watch, even a responsive one, is cumbersome at best. tvOS has a similar problem in the opposite direction – they don’t expect people to be interacting with webviews on a large screen using a remote control. Wired explains it pretty nicely: “Instead of tapping and swiping a 4.7-inch display with your fingers, you’re using a remote to control a 55-inch digital tapestry from 10 feet away. It’s like trying to play a banjo with two oven mitts on.”

So without a webview, what can a hybrid developer do? The answer right now is nothing. So far there are no solutions to get around this problem.

So in the case of these two platforms, React Native has the potential to shine. Being a native technology that doesn’t rely on a webview, we’re able to adapt to almost any platform.

The community is already working on it for tvOS:


Watch OS is not receiving much interest so far, but that certainly could change over the next year:

Unless Apple releases webview capabilities for these platforms in the future, Cordova will never be an option for them. So you’re left with either developing something entirely natively, or using an environment like React Native.

Scratching the surface

There are alot of other reasons to look into React Native and what i’ve described are just my impressions, understanding and usage so far. Check out their docs for more. I haven’t had a chance to fully utilize it yet, but their animation implementation looks powerful.

Why Cordova/Ionic

We’ve gone through what i’ve learned about React Native so far and what has me excited. But what are the positives to continuing with a tool like Cordova?


The obvious win for developing applications using standard web technologies is familiarity. When you develop an app using a tool like Cordova, you are writing standard HTML, CSS and Javascript. Whatever tools or approaches you add on top do not change the fact that this is the same code that could also power a website.

Does this familiarity actually play out in practice? Do web developers navigate seamlessly into the mobile world?

My experience is that no, it’s rarely that straightforward or simple. Frameworks make it easier, but there is always a learning curve to thinking with a mobile mindset, understanding the proper interactions, and dealing with the quirks of developing in this environment.

But is the learning curve smaller – definitely.

CSS, not “Styles”

I glossed over the way React Native handles styling when I talked about UI Flows earlier. That’s because despite the benefits of of all your components interacting consistently and performing nicely, the way you style them is not exciting. It works, but there are some definite weaknesses (you can read through a speaker deck about why they made these choices here. It’s at the top of the article).

To start, what you know about CSS is only partially relevant here. The full specification is not implemented, shortcuts are not supported, and you have to define it all in your Javascript code. It’s somewhat akin to writing all your styles using the dom style attribute, but more limited (everything is assumed to be pixels, for instance, so you define things like margin and padding as simple integers).

For example:

var styles = StyleSheet.create({
  container: {
    flex: 1,
    justifyContent: 'center',
    alignItems: 'center',
    backgroundColor: '#F5FCFF',
    margin: 10,
    marginBottom: 5
  text: {
    color: 'black'

That code compiles your definition, and you can now use that styles object to apply styling to your components.

Applying the styles

So how do we apply this to our components? Let’s take a simple React Native code sample, and apply it to that. I’m not going to elaborate on what is going on in the code except to note how the styles are being applied, since the general concepts are the same as any React code.

var ExampleApp = React.createClass({
  render: function() {
    return (
      <View style={styles.container}>
        <Text style={styles.text}>
          My example with styles applied.

If you’re like me, your initial reaction to that example is probably something like this:


It’s a CSS styling sin to employ inline styling at all, let alone as your primary mechanism for your entire layout. It’s a bummer, but in practice it’s not so bad. In a sense the styles are acting a bit like selectors, in that you are defining your style elsewhere and referencing it from here. There is some amount of cascade that goes on here as well, though I haven’t identified all the rules around it yet and have encountered some surprises along the way.

Flexing your layout

You may have noticed I have some flex properties defined in that example, and that’s because in addition to only supporting a subset of properties, React Native only supports one layout option: Flexbox. This also seems like a downside, and technically it is (more options being better than less), but it turns out to be a pretty solid choice. Flexbox supports the app layout and concept nicely so in practice this is not a huge determent – just a learning curve for many developers (including myself).


There is no nesting of styles, so you end up defining multiple style objects, or prefacing your definitions with additional context about where it goes. It doesn’t always use standard names and properties: flexDirection instead of flex-flow, for instance. So even where it is using standard CSS concepts there are some subtle differences. (correction).

React Native’s approach to styling works, and at least you can take advantage of many of the principles of CSS… But it’s not CSS. It’s comparatively cumbersome, verbose, and seems likely to stay that way unless projects like react-native-css take off and become a community standard.

Back to Cordova

So developing using standard CSS means you have the full feature set of CSS available, and as new features are added you can start to take advantage of them immediately. It works the same way you’re used to in your regular web development, and that’s a pretty large advantage.

It also means you can potentially use things like CSS Grid Layouts. I’m going to back away slowly now, before i’m pressed further and you realize I have no idea why that would be useful to you. But it’s coming, you won’t get it with React Native today, and may never be able to.

Updating your app without updating your app

The app submission process is not known for being speedy, so having options to update application functionality without going through a full submission process is a definite benefit towards developing applications with Cordova. There are lots of tutorials explaining how you can achieve that, so I won’t go into it here. But being able to load in your javascript and CSS remotely means faster code turnaround and faster deployment of new features to your users.


Originally I thought this would not be an option for React Native, but was proven wrong pretty quickly. It’s not quite as straight forward as what you can do with Cordova, but there are approaches available.

Apphub offers a service for it:

And here is a medium article about dynamically updating your app:

Richer pre-built components

In fairness, React Native is a young library. And compared directly to straight Cordova, they actually have an advantage because of their out of the box native components.

But the existing pre-built components (both in the project and in the community) are still pretty limited at the moment, and not as mature as what you’d get by using a library like Ionic.

I was disappointed to find no Pull to Refresh or Swipe action implementations available in React Native itself. From what i’ve read in their responses to issues is that they aren’t interested as a core project in coming up with a huge array of components – they want the community to get involved to build that out while they focus on the library itself. I can definitely respect that, and I look forward to what gets produced over the next year. There are already some community pull to refresh and swipe action implementations available, but the quality is variable right now.

So compared to what I can use now in Ionic, if I had to build something on a tight timeline and use a breadth of components, Ionic has a clear advantage.


Before I close, there are a couple great tools I want to mention for playing around with React Native with the lowest barrier to entry possible. ( is a service that lets you stream iOS and Android apps in the browser. While not directly relevant to React Native, it’s what powers the next tool. let’s you write React Native code in your browser and test it using their app viewer (which is powered by Other users can fork your code and for trying out React Native for the first time there is no better option (as long as you don’t need to branch outside the core components). I’ve embedded an example here for you to try. Feel free to fork the code and see what you can put together!


You’ll notice that where I have complaints about React Native, most of them are surface level, or related to the young age of the project. I’m excited about what React Native is offering, and excited for what is next for them.

I’ve been using Ionic/Cordova for awhile now, and really enjoy it. I’ve deployed client code using it, and will continue using it for the foreseeable future.

But React Native has definitely caught my eye, and I think it’s a powerful and interesting project. It’s not usable for everything just yet – there are some widget niceties that I think it needs for more mass appeal and quick use. But it will get there, and using it has been fun and productive so far.

I’ve got an app coming out soon that I will write about more in depth in terms of actual implementation details using React Native. Something very simple, but it gave me a good way to test the tech and see what React Native could offer and handle, and fueled everything in this post. I’ll go into specifics about what modules I used, benefits of the native experience, issues I hit, community responsiveness, resources available, and bugs in the platform I encountered.

So what is my final feeling on React Native? Excited, and a little mixed. There’s a side of me that loves everything they are offering and the possibilities, but it is also at odds with my love of a more pure web tech solution. Despite using many elements of web technology is also eschews a lot of it and does its own thing. So if you’re a web developer looking to try React Native – you’ll feel comfortable there, but not exactly at home.

Update 12/5/15:

Thanks to @notbrent for some feedback on this post. Notably pull to refresh just landed in core ios/android, and a mistake I made about non-standard flex properties (flex-direction is valid. While react-native doesn’t support shortcut definitions, the properties it supports should be capable of handling all simple forms in a standard way)

Better Than Bootstrap Javascript: Click Delay

This entry is part 3 of 3 in the series Better Than Bootstrap Javascript

Last week we dug into Javascript Carousels, first analyzing the implementation Bootstrap offers and then examining two alternatives in Flexslider and Slick. We reviewed examples in each and noticed the simplicity of setup as we moved beyond Bootstrap – but that wasn’t enough. Developer productivity and effectiveness is important, but what else did alternatives have to offer?

Ultimately, the user experience was the major differentiator. Flexslider and Slick offered swiping and dragging for navigation, natural animations, and fine tuning for responsive displays. One important differentiator was around user feedback – how the carousel responded to a users tap or click, and the detriment of the click delay.

This weeks post is a bit different in that it’s not specifically comparing a Bootstrap component to an alternative, but comparing the absence of a feature and how you can implement it in your web apps. Let’s get started.

Click delays and the smartphone tap

If you’re an iPhone user, i’d encourage you to visit the Bootstrap website on your phone and tap around on the links and features displayed there. A great example on the phone would be clicking the “hamburger” menu (the three stacked bars you see at the top right corner of the page). You’ll immediately notice the short delay between tapping the menu, and actually seeing the content open or close. Is it loading from the server? Did my action register?


Looking at it in action, it’s not painfully slow. Is there really an issue? Is the perceived latency that big of a deal?

Now go to the Google homepage, and click the menu in the top left corner (again, the same “hamburger” style menu, with three horizontal bars). Here, the reaction is immediate. You tap, and right away it slides open and gives you a scrollable list of pages. Tap it again (now moved to the right) and it immediately slides closed.


The experience on the Google homepage is a clear improvement over that of the Bootstrap site. The Bootstrap responsiveness seemed fine, but then we experience Google’s menu and the Bootstrap interaction feels less natural. The responsiveness of Google’s menu is instant – difficult to distinguish from a native application.

What’s the deal, Bootstrap?

You might be wondering why Bootstrap, being a mobile first framework, wouldn’t take care of something like click delay for you?

I’ve never looked into it specifically, but Bootstrap’s reasons could fall into a few camps – reducing dependencies, inconsistencies between the multitude of platforms Bootstrap tries to support with one codebase, or feeling that browsers will eventually fix the issue for them.

I used to be a jquery mobile user, and their goal is to support as many mobile platforms as humanly possible. They found removing the click delay was problematic while trying to maintain maximum platform support, so they left it as a task for the developer to deal with on a case-by-case basis. Since Bootstrap does the same, it’s up to us to figure out how to approach the issue.

So how can we move ourselves beyond the sluggishness of the Bootstrap site with their click delay to the immediate feedback that we get in the Google example?

Immediate feedback with touch events

The first approach you could take to resolve this might be with touch events. Touch events are fired immediately when a user taps something. Using touchstart, we recognize the users tap and can react right away.

$('.action-button').on('touchstart', function () {
  alert('no click delay');

The problem is that this is only useful for isolated interactions. What about regular pre-existing links on the page – do we apply touchstarts to them all? What if we want to prevent the default behavior and perform a different action when something is clicked? How can we apply this to existing javascript code running on the site without modifying it (for instance, how could we improve the speed of the Bootstrap menu)?

Pretty quickly, the depth of the click delay issue becomes apparent. In principle the solution could be simple, but the reality is that it bleeds into all aspects of your site, and can be inconsistent to implement between browser vendors and devices.

Leveling the playing field with FastClick

The most popular approach available to solve the click delay issue is with a tool called FastClick. They take the issue and approach all of the multitude of scenarios for you, all wrapped up in a very simple API.

Since we’re talking about Bootstrap here, I’ll assume jQuery is available and use it to load FastClick once the DOM is ready. You get a reference to the body element (which can be accessed directly from the document object using the body property), hand it off to FastClick, and you’re good to go.

$(function () {

This is the shotgun blast approach. Everything on your site is now freed of the click delay – buttons, links, click events – all of it. FastClick attaches itself to the touch events that are immediately responsive (similar to what we did with touchstart earlier), and handles the rest for you from there.

Now when you attach a click event to something, the delay is gone. Not only that, but our ability to suppress the default behavior (for instance, a link changing the url of our browser) is also available.

$('.action-button').on('click', function (e) {
  alert('clicked immediately!');

It’s dead simple, and generally it just works.

If we apply FastClick to our Bootstrap example from earlier, we now have the same responsive feel that the Google homepage gave us.


Alternative to FastClick: device-width

You might notice that when I first talked about the issue, I said “If you’re an iPhone user…”. That’s because outside of the iPhone, there are some alternative approaches that browsers and devices take to the click delay.

If you’re on an Android phone, check out the sites I mentioned earlier (Bootstrap and Google) in Chrome. Depending on your Android version, and which provider released it, you may not experience any click delay. This is because some browser vendors have been introducing ways to avoid click delay when your site meets certain criteria. In this case – if you define your viewport as being the width of the device – Chrome on Android will remove the click delay for you.

<meta name="viewport" content="width=device-width">

In general, this is an important setting for mobile-first sites, and a Bootstrap recommendation. Having a width of device-width means your viewport width is based on the device you’re using. So if your site is responsive, and the width of the viewport is device width, you’ll get a display that is better suited to the device.

On Chrome on Android, they piggy back on your viewport setting to mean you don’t need tap-to-zoom, and they remove the click delay for you automatically.

You can read more about this here. That article is also nice because it mentions approaches that apply to Windows Phone as well, which works by a different set of rules from iOS and Android.

Why wouldn’t I always use FastClick?

Learning about FastClick might seem like a good point to stop the discussion, apply it to your site, and call it a day. And in many ways, it could be. If you have a responsive site using Bootstrap and you want to remove click delay across the board, this is the way to go.

There are some warnings here, though. FastClick works really well, but like any project it is continually in development, and it can have issues. New versions of mobile OS’s come out and break things. The browser vendors are not expecting FastClick, they implement their own behavior, and edge cases arise. FastClick meets the browser, meets the rendering and javascript engines, and on the fringes of functionality things can breakdown.

In some cases, FastClick can also impact other plugins. At the time of this writing i’ve had issues personally getting FastClick and Select2 to play well together, and have had to patch FastClick to bypass the issue. This is something that could happen with other libraries as well, who may try to eliminate the click delay issue themselves, or just have some other scenario which ends up conflicting with what FastClick is trying to do.

There’s also the question of whether this user experience matters to you at all. If your site is heavily content driven, and most of the interaction is through clicking links – you may not want to bring in another library just to remove a click delay which only happens as the user intermittently clicks things. Perhaps in this case just manually applying touch events when appropriate is the better approach (for instance, to improve a specific scenario like a carousel, but not to remove it from everything across the board).

The important thing to consider if that FastClick is a tool, and you should weigh the benefit of the tools that you use, and test them on your site. If you’re creating a web experience that needs to give the user a native feel – I’d encourage you to use FastClick. Just make sure you do your due diligence and test your site before pushing it off into production.

Should I always use device-width?

If you’re designing responsive, mobile-first sites using Bootstrap, then you should definitely be setting the device-width on your viewport. But in terms of its impact on click delay be careful, and understand the extent to which it’s available. If you have some sense for what browser or devices you’re deploying to, test to see that it actually works.

I’ve encountered situations where it didn’t work, even when it was supposed to. I had a client with a lower-end Android tablet being deployed to their userbase running Android 4. We were having the client use Chrome and the click delay was supposed to be removed. It wasn’t. Even applying FastClick we still had some work to do – FastClick tries to intelligently disable itself if it detects a browser and device which should have click delay disabled natively. In the end we had to apply a minor patch to FastClick to remove the check for the native feature.

Approaching the problem differently with FastActive

A very different way of approaching click delay is to solve the problem by altering the users perceived performance and offering immediate visual feedback, even if the actual result of the interaction is not immediate. This can be achieved by using the FastActive library.

It applies an .active class to links and inputs, so you can create the appearance that they are reacting immediately (through CSS). This may be an alternative for you if you do not want to risk platform related click issues, and are more concerned with the users perception of performance.


You’ll notice that i’ve talked at length about user perception and interaction in this Bootstrap series so far. This is because despite my love for the web and its potential, the experience of native is compelling and fluid and fast, and the web struggles to compete with this out of the box. More and more people have an expectation of performance, regardless of whether they’re in an app or in their browser. The app experience creates high expectations, and that expectation still remains when using the web. How we deliver on that expectation is through tools and approaches like these.

If approaches like flipboard’s react-canvas are any indication, ios has raised the bar and users are expecting beautiful interactions. Flipboards approach was about flawless animation and scrolling. Click delay wasn’t even discussed in this situation because it’s so basic as to be taken for granted – it’s just not an option. When I hop out of a native app where I can swipe, tap and scroll with ease into a website where I click a link that takes 300ms to register, I feel it. And if your app is trying to compel your users to continuing using it, that may make the difference between them coming back or choosing something more compelling (or ditching the web entirely, and using a native app instead).