Tapstream

Tapstream SDKs

Setting up campaigns

Running reports

APIs

Advanced

Third-party integrations

Objective-C Swift

Using In-App Landers with the Tapstream iOS SDK

First, integrate the latest iOS SDK.

Integration instructions for iOS

Tapstream In-App Landers let you automatically display a landing page to your new installs, based on their route to downloading your app. You could, for example, show one lander to visitors from your Twitter profile, and another to visitors from your product site.

You can provide a custom URL, some custom HTML, or use our lander builder to produce landers on the fly. You can add new landers and associate existing landers with advertising or marketing campaigns, without having to release app updates.

Using the Lander Builder

In most cases, you will want to use Tapstream's in-dashboard lander builder for your landing pages. The builder provides a variety of options to create a mobile-optimized lander. Within the lander builder, you'll find a field to provide a form action; this is the address to which your lander form will POST when it is submitted. You will want to point this at a service or server you control to collect the data and use it how you like.

The builder includes automatic support for Mailchimp forms. To use a Mailchimp form, enable the "Use Mailchimp" toggle and provide your form action, user ID and list ID, along with the styling options for the automatically-generated email collection field. You can add additional fields from your Mailchimp list as regular form fields, as long as you match the field names (likely "MERGE1", "MERGE2", etc.)

Advanced Usage

If the lander builder doesn't suit your needs, you can provide either custom HTML or a custom URL to your lander. Make sure that all assets are served via HTTPS with an App-Transport-Security (ATS) compliant certificate. IOS 9 will reject by default any loading of insecure content.

SDK Integration

You can use In-App Landers on iOS by integrating Tapstream's SDK. If you use CocoaPods and have a 'Tapstream/Core' dependency, you'll need to add one on 'Tapstream/InAppLanders' (if you just use 'Tapstream' you're good to go). Wherever in your app flow you would like your lander to open, after Tapstream has been initialized, insert a snippet such as the following:

[[TSTapstream instance] showLanderIfExistsWithDelegate:nil];

If a Lander exists for this user, it will be displayed in a full-screen WebView window. Navigating away from the lander will close it.

The lander cannot not be shown before the app has finished launching, or before Tapstream has finished initializing. If you would like to display the lander on application start-up, the applicationDidBecomeActive lifecycle hook is a good place for this, presuming that Tapstream was initialized during applicationDidFinishLaunchingWithOptions. Remember that any given lander will only be shown once per user.

Lander behavior

Landers are keyed by the user's session. When deciding to display a lander, Tapstream's lander API endpoint inspects the user's timeline for any hits on your campaigns. If any of these is associated with a lander, it will be displayed. After a lander is displayed, the Tapstream SDK saves the id of the lander on the device, such that the same lander will not be displayed again to that user.

If a user has hit more than one of your campaigns on their way to running your app, the most recent lander will be shown. If after seeing one lander the user proceeds to hit another of your campaigns with a lander and run your app again, that lander will be shown if and only if the lander has not been shown to that user before.

The lander is retrieved from an API endpoint. A 404 response means that no lander was found for this user; a 200 response means that a lander was returned. However, if a lander with a matching id has already been shown, then the lander will not be displayed.

Customizing behavior and collecting extra data

For more control or information about your users' behavior, you can implement a delegate conforming to the TSLanderDelegate protocol, which looks like this:

#import "TSInAppLanders.h"

@protocol TSLanderDelegate <NSObject>
- (void)showedLander:(NSUInteger)landerId;
- (void)dismissedLander;
- (void)submittedLander;
@end

The first method, showedLander, is called when a lander is displayed, with that lander's numeric id. The second, dismissedLander, is called when the lander is dismissed via the close button in the top right corner. The final method, submittedLander is called when the form is submitted.