Setting up a secret trigger on iOS to display SDK debug information

Contents

Overview

Skill Level: Intermediate

One of our recommended practices is to set up a way to obtain SDK debug information from your app to help when getting technical support. Specifically, itâ€™s very common for our support team to request mobile user ID and SDK versions, though there are a number of other items you may want to include in a debug screen such as OS version and platform, build version of your app, channel ID, app key and so on. If you have this information easily available from devices in the field, it becomes significantly easier to resolve problems. Most customers prefer to keep this information hidden until itâ€™s needed. We recommend that as well. Thus the question arises: how can one make a secret trigger that can be used to report SDK information, but make it relatively easy to access when needed. This is one possible solution. You may want to use a different way to trigger the way to open the screen, and consider issues with accessibility.

Prerequisites

Not what youâ€™re looking for? Check out all our available tutorials for mobile app messaging here.

Step-by-step

Make changes to the sample app

The following changes will be made to the sample app. Changes to your app will be similar.

1. Decide where you’ll invoke a trigger

You will need to find an appropriate place in your app from which a user invokes the trigger. Often this is the Configuration screen, but if you have a lot of elements on that screen, another view may be preferable. Itâ€™s best if itâ€™s a screen where youâ€™re not already collecting gesture events.

A view that has a text entry field offers slightly more security than one that doesnâ€™t (described later).

In this case, we will be adding the event to the â€śSend User Attributesâ€ť screen in the sample app.

2. Add the changes

Add the following variables to AttributesVC.m in the @implementation section:

The â€śpatternâ€ť static variable represents the quadrants on the screen where the user must triple-tap to trigger the event. In this case, we require the user to triple-tap in the upper left, then the upper right, then the lower left, then the lower right, then again in the upper right, then lower left, then upper right. When that happens, the event will be triggered. Any deviation from the pattern resets it back to the beginning.

We strongly recommend you change the sample pattern. You might want to use a different pattern for each app, or even each major revision of the app. Remember, however, that your support reps will need to be able to tell people how to trigger the diagnostic event. If itâ€™s too complicated, you may need to adjust it.

Add the following three methods to the bottom of the view controller before @end (AttributesVC.m in the sample):

Since the showDebugScreen in this example opens RegistrationVC, we need to include its header to the imports of AttributesVC.m:

Â

// Secret diagnostics// reporting screen#import "RegistrationVC.h"

Â

The action that is executed when the event is triggered is in showDebugScreen. In the case of the sample app, it already has a screen which reports mobile user ID, channel ID and app key. If the touch events are appropriately triggered, we invoke it.

Note the test for fieldString in tryKey:. In our example, the sample app will never invoke an action (even if the trigger triple-taps happen) unless the â€śnameTextFieldâ€ť field contains the value â€śtextâ€ť. We chose that value because itâ€™s already present in the class, so it will be reused from the class pool. Doing so obscures the code slightly from those who decompile the class. Similarly, you might want to change method names so people who decompile will not think to look further, or change how pattern is stored (perhaps by encoding it or constructing it via computation). Ultimately, your code may be extracted and examined. Because of this, keep passwords out of your diagnostics.

Another option (rather than opening a screen) is to create an email message addressed to your support group. In general, this is done by calling MFMailComposeViewController.

No matter how you do it, we recommend that you give users some way to get diagnostic information at the direction of your support team. This will make problem resolution much more efficient both within your company and when interacting with our mobile support team.

Expected outcome

Expected Outcome: Need more help? Check out all of our available tutorials for mobile app messaging here.