Getting Started with iOS Data Capture

Available for the following Plan types:

FullStory Enterprise*

FullStory Business*

FullStory Free

*with the following add-on:

FullStory for Mobile Apps

Available to the following User roles:

Admin

Architect

Standard

 

Using native data capture on iOS requires adding the FullStory capture framework to your app. You can add the FullStory framework to your app in several ways. Choose the approach that best integrates with your existing app build and follow the setup instructions linked below.  

As you're implementing the instructions below, you may find it useful to reference a sample app with FullStory integrated. We have an example of the SDK being implemented into an iOS app here.

Adding the FullStory framework

Adding FullStory as a Swift Package
Adding FullStory as a CocoaPods Pod
Adding the FullStory Framework Manually

Using FullStory in a non-XCFramework environment

We recommend using the Swift Package method of installation as it provides the best compatibility with modern Apple platforms. For build environments that cannot use XCFramework (including some older versions of CocoaPods), a legacy .framework integration is also available.  Note that when using the legacy .framework, running the simulator on Apple Silicon (M1) Macs will not be supported.  To use the legacy integration, remove the "-xcframework" from the download URL; the latest non-xcframework FullStory bundle can be found at https://ios-releases.fullstory.com/fullstory-1.26.1.tar.gz.

Configure FullStory

To complete the FullStory integration, you need to tell the framework which FullStory organization to capture data to.

  • Open your app's Info.plist
  • From the menu, choose Editor > Add Item.  Set the key name to FullStory, and the type to "Dictionary".
  • Right click on the FullStory row, and choose "Add Row".  Set the key name to OrgId, and the type to "String".  For the value, paste in your assigned organization ID.

When configured correctly, the Info.plist entry should look as follows:

image (63).png

(Note that these instructions have changed in 1.18.0.  However, old integrations that use the FSOrgId key will continue to work.)

Using FullStory's Advanced Features

Identifying users and passing custom data to FullStory

On the Web, FullStory offers the FS.identify and FS.setUserVars JavaScript functions to enable you to enrich your FullStory data with additional variables for use in searches, segments, and integrations. This functionality is replicated on iOS to allow you to pass user information to FullStory directly from your native app. The methods behave identically to their JavaScript counterparts linked above. The parameters are simply the Objective-C/Swift equivalents of the original JavaScript parameters:

Objective-C

  • [FS identify:userVars:] takes a NSString and an optional NSDictionary<NSString *, id>
  • [FS setUserVars:] takes a NSDictionary<NSString *, id>

Swift

  • FS.identify(_:userVars:) takes a String and an optional [String : Any]
  • FS.setUserVars(_:) takes a [String : Any]

Preventing FullStory from automatically capturing data on startup

Added in version: 1.5.1
By default, FullStory will automatically request a session and start data capture on app startup. If you need to capture data within the app once certain conditions are met, then you can use the new RecordOnStart feature. Configuring FullStory to not RecordOnStart will prevent data capture until you explicitly invoke FS.restart.

To prevent FullStory from capturing data on start, in your app’s Info.plist's FullStory dictionary, add a RecordOnStart key, of type Boolean, with a value of NO.

(Note that these instructions have changed in 1.18.0.  However, old integrations that use the FSRecordOnStart key will continue to work.)

FullStory Delegate

You can implement the FullStory Delegate protocol FSDelegate to be notified about the session lifecycle.

Objective-C

// File: Appdelegate.m

// Set the FS delegate in `didFinishLaunchingWithOptions`
FS.delegate = self;

// Implement the optional methods
- (void)fullstoryDidTerminateWithError:(NSError *)error {}
- (void)fullstoryDidStartSession:(NSString *)sessionUrl {}
- (void)fullstoryDidStopSession {}

Identify

Identify is used to associate your own application-specific id with the active user.

Objective-C

NSString *userId = @"13ff474bae77"; // replace with your user’s Id
NSDictionary *info = @{
@"email": @"user@example.com",
@"displayName": @"Shopping User"
};

[FS identify:userId userVars:info];


Swift

In order for FullStory to be imported and used in Swift you’ll need to make sure that you’ve configured an Objective-C bridging header and @import FullStory; in the bridging header. See Apple’s Importing Objective-C into Swift documentation for help with adding the header.

let userId = "13ff474bae77" // replace with your user’s Id
let info = ["email": "user1@example.com",
"displayName": "Shopping User"
]
FS.identify(userId, userVars: info)

Additional topics

FullStory for Mobile Apps Privacy rules

For more information about configuring privacy rules and masking, please consult our FullStory for Mobile Apps Privacy Rules guide. 

Turning mobile data capture on or off

Mobile data capture can be toggled on or off from Settings > Data Capture and Privacy > Mobile Data Capture. This applies across your entire FullStory account.

UI Framework Support

FullStory for Mobile Apps works best with native UIKit and with React Native applications. If you're using another framework to build your app's UI, including SwiftUI, please reach out to your Account Executive or to our Support team to make sure that we can support your use case.

Configuring domain allowlisting for WebViews

If your application makes use of WebViews, you must explicitly allowlist any domain you wish to capture within a WebView. For security and privacy reasons, you should only allowlist domains which are under your control. Wildcards and subdomains are supported using the same scheme as Web domain settings. The key difference between the Web and Mobile settings is that while domain allowlisting is optional on Web, it is mandatory on Mobile if you wish to capture content within WebViews. If your application doesn’t use WebViews or you don’t care to captue within WebViews, you can safely ignore this section.

These settings can be configured from Settings > Data Capture and Privacy > Mobile Data Capture.

How you can integrate FullStory Logs with your iOS App Logging Framework

Data Capture Logs can help you troubleshoot app issues, as well as uncover unintended behavior. In this guide, we're going to review a few popular logging frameworks and how you can integrate them with FullStory.

Impact on App Size

For apps downloaded from the App Store, FullStory’s framework adds ~ 9MB to your uncompressed app size on device but only ~ 2.8MB to your compressed download size. (Note that compression rates can vary by app.)

Since iOS 9.0 when App Thinning was introduced, the App Store will automatically slice your app into different variants for all devices targeted. In each variant, executables and resources for unsupported architectures or screen sizes are automatically removed.

If your app targets both 32-bit and 64-bit devices (true for iOS 10 or earlier), your App Store submission will include both armv7 and arm64 versions of FullStory.framework (~ 18MB, uncompressed). However, when your users download your app, they’ll only receive the version of FullStory.framework that matches their device (~ 9MB, uncompressed).

Note that FullStory.framework will occupy more space in developer builds. We ship a universal framework that includes a variant for each architecture we support. Currently, that’s arm64, armv7, and x86_64. The full universal framework adds ~ 29MB uncompressed to your app, but that’s because app thinning / slicing doesn’t happen for developer builds.

To learn more about how app thinning impacts app size, see Getting an App Size Report in Technical Q&A QA1795.

 

Need to get in touch with us?

The FullStory Team awaits your every question.

Contact us