Adding In-App Feedback to Your Mobile App

I would like to share with you the single greatest bug report I have ever received:

“The last time I had something for sizing, my computor didn’t keep things inside other boxes like most others that did resizing.”

This sentence was special enough that I immediately saved it in numerous locations; you can’t lose a quote like this. Shockingly, I was unable to understand the issue this individual was having, and needed to meet face-to-face to see the problem. As it turns out — and this will also shock you — it was an issue that only occurred in IE6, on a PC with a 800 x 600 screen resolution.

Every developer I share this quote with has their own feedback-related story to tell (feel free to share your “fun” experiences in the comments.) As developers we rely on feedback to build better products, but, as these stories show, getting good feedback is really, really hard.

This is especially true when building mobile apps. Feedback such as, “it doesn’t look right on Android”, isn’t helpful, as there are 10,000+ Android variations (literally). To debug, you need to know hardware characteristics – the OS version, browser version, and screen resolution — information testers and users often don’t know.

In this article we’ll attempt to solve this problem. We’ll discuss several popular approaches to in-app feedback, and how to implement them in Cordova-based applications.

Rate My App! Please? PLEASE!

The most common — and perhaps most annoying — means of gathering feedback is to leverage the platform’s app store rating mechanism. If you have used a mobile device before, you have almost certainly seen a dialog that looks something like this:


All demos in this article are running in Kendo Sushi, a Cordova-based AppBuilder app that is available at

The iOS App Store, Google Play (Android), and Windows Store (Windows Phone) all provide URLs you can link to access a given application. And with the power of Cordova, you can write a single function that provides this functionality for all three platforms.

The following code uses the Cordova notification plugin to prompt the user for a review, and sends them to the appropriate store if they accept:

// Codes for the Telerik Mobile Testing app on each platform.
// Replace these values with your own.
var appIdIos = "787441509",
    appIdAndroid = "com.telerik.testing.executionagent",
    appIdWindows = "fc0fcfdc-9666-4c6a-b667-ee882fc3ba0d";


    // The message
    "If you enjoy using my application, would you mind taking a minute " +
        "to rate it? Thanks!",

    // A callback when the user clicks a button
    function( index ) {

        // index is the 1-based index of the clicked button.
        // 1 == Sure, 2 == Later
        if ( index === 1 ) {
            var url = device.platform == "Android" ?
                ( "" + appIdAndroid ) :
                device.platform == "iOS" ?
                ( "itms-apps://" + appIdIos ) :
                "" + appIdWindows;
   url, "_blank" );

    // The title of the notification
    "Rate My App",

    // The text for the two buttons
    [ "Sure", "Later" ]

The gif below shows this code in action on Android, iOS, and Windows Phone devices:


However annoying it may be, there are a few advantages to this feedback approach. For one it’s simple; all you need to do is link to a URL. On top of this, there is some anecdotal evidence that these prompts do increase the number of app store reviews — which can be vital to the success of an app.

But before you run off and implement a Rate My App prompt, you should know that there has been an enormous public backlash to the use of this tactic. Perhaps the strongest stance comes from John Gruber, who stated the following:

I’ve long considered a public campaign against this particular practice, wherein I’d encourage Daring Fireball readers, whenever they encounter these “Please rate this app” prompts, to go ahead and take the time to do it — but to rate the app with just one star and to leave a review along the lines of, “One star for annoying me with a prompt to review the app.”

And he’s not alone. iOS developer and podcaster Marco Arment added the following (speaking of “Rate This App” dialogs):

I’m strongly against them — to me, they’re spam, pure and simple. They’re as intrusive as a web popup ad, they betray a complete lack of respect for users, and they make their apps’ developers look greedy and desperate.

If that wasn’t enough, there’s also an Eff Your Review tumblr blog that collects and ridicules these rating prompts. Because of this backlash, if you do decide to implement a rating dialog, make sure you have some respect for the user, and give them an easy way to never see the dialog again. The most popular iOS library for implementing these dialogs, iRate, responded to this criticism by not allowing users to prompt with each new version, and to ensure that the user never sees the dialog again if they select the “No, Thanks” option.

Regardless of how these dialogs are implemented, from the perspective of trying to get good feedback, the Rate My App prompts are limited. Because of how the app stores work, users can only type short messages in a public forum — which probably isn’t where you want users to report bugs. You also can’t use app stores as a feedback mechanism during testing or a beta release. Let’s see how we can do better.

A Rating Menu Option

Another common approach to getting feedback is to include a menu option somewhere within the app. For instance, the Gmail iOS app includes a “Help and Feedback…” button in its Settings menu.


Facebook uses a “Report a Problem” option in its “More” menu.


Most of these feedback mechanisms take you to a form where you can input text and send that data to the app’s owner. For instance, here’s the form that Gmail’s iOS app uses:


This approach works, but there is one problem with such an approach: you lose context. Because the user has to navigate to the feedback form, you can no longer take a screenshot of what they’re seeing on their device — and this is often invaluable for debugging issues.

To address this, over the last year or so, some apps have experimented with another feedback mechanism: shaking.

Shake to Send Feedback

Although I have no idea where shake-to-send-feedback idea came from, the first app I saw it in was Google Maps for iOS. Shake to send feedback works exactly like it sounds — you shake your device, and you’re prompted to give feedback. After you shake your device in Google Maps for iOS, you see the following menu:


When you choose the “Send general feedback” option, you get the following form:


Importantly, note the “Include screenshot” option that is now present. Personally, I think this is a rather slick way of implementing in-app feedback — especially in a mapping app, where seeing what the user sees is vital.

The biggest issue with using shake is discoverability. How are users supposed to figure out they can shake their devices? Google sort of handles this by presenting the following dialog the first time they detect the gesture:


It’ll be interesting to see if other apps come up with ways of making this mechanism more intuitive, or whether it becomes commonplace enough that people just expect it to work (think pinch-to-zoom).

But there’s another use case where the shake effect makes sense. Suppose you’re only using the feedback mechanism during the testing phase or your application. In this situation, you know who the users are (your testers), and you can inform them of the shake effect’s existence.

With this use case in mind, let’s look at how you can implement a shake-to-send-feedback approach in a Cordova app.

Implementing In-App Feedback with AppFeedback

For this example we’ll be using Telerik AppFeedback, as it takes care of some of the grunt work for us automatically — such as gathering device information and a screenshot. To give you a sense of how it will work, here’s a video showing the end result of using AppFeedback:

AppFeedback is a part of the Telerik Platform, so to use it you must create a Telerik Platform account (which is free for 30 days). Once you have an account, you’ll see options to create the various project types in the Telerik Platform; you’re interested in this one for AppFeedback:


Click the big button, which takes you to the screen below, where you have to give your new project a name. Here I use “Kendo Sushi Feedback” to go with the Kendo Sushi app I showed earlier:


Click “Create project”, and you’re taken to the dashboard shown below. This is where feedback appears after users submit it:


Adding the AppFeedback Plugin

Now that you have the necessary setup done, you have to add the AppFeedback Cordova plugin to your project.

If you’re unsure how to add Cordova plugins, check out this guide in the AppBuilder documentation.

The plugin creates a global feedback object. While this object has several methods (you can view the full list here), the important ones for the purposes of this tutorial are the initialize and postFeedback methods.

The initialize method must be called before you do anything else with the plugin. The call needs to happen after the Cordova deviceready event to be sure that the AppFeedback Cordova plugin has loaded. When you call initialize, you must pass your API key, which you can get from project you just created in the Telerik Platform (the “API key” menu item in the sidebar). The code for the call looks like this:

document.addEventListener( "deviceready", function() {
    feedback.initialize( "abcdefgh-ijkl-mnop-qrst-uvwxyz12345" );

After initialization, call the plugin’s postFeedback method whenever you wish to send feedback.

feedback.postFeedback({ text: "Hello world" });

After this call, return to your project in the Telerik Platform, and you’ll see the feedback in your dashboard:


Here’s the cool part: click on the feedback, and you’ll see both screenshot of your app, as well as device information — such as the OS version, and screen resolution. AppFeedback collected all of this information automatically when you called the postFeedback method.


Of course, this was a hardcoded call to postFeedback, and not actual user feedback. Let’s expand on this example by adding a form and a shake effect.

Adding a Shake Effect

The Kendo Sushi app uses Kendo UI Mobile; therefore, I’m going a place the feedback form in a Kendo UI ModalView widget. For simplicity, the form contains a single text box, as well as Submit and Cancel buttons.

<div data-role="modalview" id="feedback-modal">
    <div data-role="header">
        <div data-role="navbar">
                <label for="feedback">Feedback:</label>
                <input type="text" id="feedback">
        <button id="feedback-submit">Submit</button>
        <button id="feedback-cancel" type="button">Cancel</button>

You can choose to show this dialog at any time, but our goal was to show this when the user shakes their device. To do that, we’re going to use shake.js. Shake.js is a lightweight plugin that does what its name implies — triggers a custom “shake” event when the user shakes their device. With shake.js, detecting a shake is as easy as using the following code:

window.addEventListener( "shake", function() {
    // A shake occurred!

Now all you need is the code that shows the modal dialog on shake, and calls the feedback plugin’s postFeedback method when the user submits the feedback form. The following code does that:

(function() {
    var modal;

    function setupEvents() {

        // Create an instance of the ModalView widget.
        modal = $( "#feedback-modal" ).kendoMobileModalView({ width: 320 });

        // When the user clicks the cancel button, close the modal dialog.
        $( "#feedback-cancel" ).on( "click", function( event ) {
            modal.kendoMobileModalView( "close" );

        // When the user submits the feedback form, call sendFeedback().
        $( "#feedback-submit" ).on( "click", function( event ) {

        // When the user shakes their device, open the modal dialog.
        $( window ).on( "shake", function() {
            modal.kendoMobileModalView( "open" );

    function sendFeedback() {

        // The object that you'll send to AppFeedback.
        var feedbackObj = {
            text: modal.find( "input" ).val()

        // Close the modal dialog so the screenshot does not contain the modal.
        modal.kendoMobileModalView( "close" );

        // Wait a second for the modal dialog to finish closing.
        setTimeout(function() {

            // Post the feedback to the AppFeedback backend.
            feedback.postFeedback( feedbackObj, function ( result ) {

                // A success callback—show a confirmation message
                navigator.notification.alert( "Thank you for your feedback",
                  $.noop, "Thanks!" );
            }, function ( error ) {

                // An error callback—show the user an error message
                  "Sorry, an error occurred sending your feedback." );
        }, 1000 );

    // Wait for the Cordova deviceready event before setting up our custom events.
    document.addEventListener( "deviceready", setupEvents );

That’s all there is to it. The see how the pieces come together, here’s the same video I showed earlier that walks through the process:

The great thing about AppFeedback is its flexibility. If you want to use a shake effect — great. But if you want to use a more traditional menu approach, that works too.

Wrapping Up

Regardless of how you gather it, feedback is important for any app. Prompting users to leave app store reviews can help boost your review stats, but you risk annoying users. Adding a feedback menu option somewhere in your app is the most conventional approach, but you lose the ability for users to gather screenshots from users.

Gathering feedback after a user shakes their device is a new trend that is starting to gain some traction. The main problem with the shake approach is discoverability — since few apps use this convention, users don’t know it exists.

Regardless of your UI implementation, AppFeedback provides a convenient API for gathering feedback in a Cordova-based app. By automatically taking a screenshot and gathering device information, the plugin lets you focus on your UI.

What do you think of the shake-for-feedback mechanism? Have you tried it on any live apps? Let me know in the comments.