mPulse iOS SDK (Version 2) Reference

Introduction

The mPulse iOS SDK (version 2) is a library that you can use to send beacons from any iOS application to mPulse.

What types of data can I send?

The mPulse iOS SDK lets you send Custom Metric and Custom Timer beacons to mPulse.

For each beacon, you can set the View Group, A/B test, and Custom Dimensions.

The mPulse iOS SDK also monitors all network activity performed by the application and its libraries. Each network request can be monitored individually and its performance data will be sent on a beacon.

The mPulse iOS SDK also allows you to monitor Actions, which are distinct user interactions. Actions can be started at any time via the SDK, and stopped either programmatically or automatically by the SDK once all network activity has quieted down. All network requests during the Action will be included on the Action beacon’s Waterfall.

Getting Started

Before using the mPulse iOS SDK, you will need to have a mPulse app and an associated API Key. For information on how to setup the mPulse app and the API Key, go to mPulse setup.

Once your app has been configured in mPulse, you can use the mPulse iOS SDK.

Custom Metrics

Custom Metrics are user-defined counts that refer to a business goal, or to a Key Performance Indicator (KPI) such as revenue, conversion, orders per minute, widgets sold, etc. The value or meaning of a Custom Metric is defined by the App Administrator.

You can programmatically increment a Custom Metric using the SDK.

Custom Metrics must be defined in the App dialog before use.

Custom Timers

A Custom Timer can be based on any measurable user-defined duration.

You can programmatically send the value of a Custom Timer using the SDK.

Custom Timers must be defined in the App dialog before use.

View Groups

A View Group (also known as a Page Group in a web app) allows for measurement across views that belong together. Grouping views in this way helps you capture and summarize the performance characteristics across the entire group.

For mobile apps, Launch may make up one View Group, while the Login view may make up a second, and Product views a third group. Search Results and Checkout views may also have their own groups.

You can programmatically set the View Group using the SDK.

Custom Dimensions

In addition to the out-of-the-box dimensions already provided within mPulse, App Admins can define additional Custom Dimensions for the given app. For example, a Custom Dimension to track Premium Users versus Free Users.

You can programmatically set a Custom Dimension using the SDK.

Custom Dimensions must be defined in the App dialog before use.

mPulse iOS SDK

You can either use the library via a Framework package or via CocoaPods.

Getting the Library (Framework)

To use the mPulse, you can install the mPulse iOS SDK via a Framework file:

  1. Navigate to the SOASTA/mPulse-iOS Github repository and download the MPulse.framework.zip archive.

  2. Unzip MPulse.framework.

  3. Drag and drop the framework into your Xcode project.

  4. Navigate to the Build Settings section of your target and add the following (if not already present) to the Other Linker Flags setting:

    • -ObjC
  5. Navigate to the Build Phases section of your target and add the following Libraries (if not already present) to the Link Binary With Libraries step:

    • CoreTelephony.framework
    • CoreLocation.framework
    • SystemConfiguration.framework
    • libc++.dylib or libc++.tdb
    • libz.dylib or libz.tdb
  6. If using mPulse from Swift, you must add the following line to the Objective-C bridging header ([project name]-Bridging-Header.h):

    • #import <MPulse/MPulse.h>

Getting the Library (CocoaPods)

The mPulse iOS SDK can also be installed via CocoaPods.

  • Install CocoaPods:

    gem install cocoapods
    
    pod setup
    
  • Create (or update) a file in your Xcode project called Podfile and add the following line to it:

    pod 'mPulse'
    
  • In the Podfile, use_frameworks! must be set for the desired targets.

  • Run pod install in your Xcode project directory, and then open the Xcode workspace:

    pod install
    

Configuration

Initialization

To use the mPulse iOS SDK, you must first initialize your iOS project with your API Key.

In most cases, it makes sense to initialize in application:didFinishLaunchingWithOptions:.

Objective-C:

#import <MPulse/MPulse.h>

#define MPULSE_API_KEY @"YOUR_API_KEY"

// Initialize the library with your
// mPulse API key, MPULSE_API_KEY
[MPulse initializeWithAPIKey:MPULSE_API_KEY];

// Later, you can get your instance with
MPulse *mpulse = [MPulse sharedInstance];

After you’ve called initializeWithAPIKey:, you can access the instance by calling [MPulse sharedInstance].

Swift:

// If mPulse was installed using Cocoapods then add the following line:
import mPulse

// Initialize the library with your mPulse API key
let apiKey = "YOUR_API_KEY"
MPulse.initializeWithAPIKey(apiKey)

With Swift 3, you may need to use:

MPulse.initialize(withAPIKey: apiKey)

After you’ve called initializeWithAPIKey:, you can access the instance by calling [MPulse sharedInstance].

Enabling or Disabling the SDK at Runtime

Once initializeWithAPIKey: is called, the mPulse iOS SDK is enabled.

You can disable the mPulse iOS SDK at runtime by calling disable:

Objective-C:

[MPulse initializeWithAPIKey:MPULSE_API_KEY];

// later:
[[MPulse sharedInstance] disable];

Swift:

MPulse.initializeWithAPIKey(apiKey)

// later:
MPulse.sharedInstance().disable()

Once disabled, mPulse will no longer send beacons.

mPulse can be re-enabled by calling enable:

Objective-C:

[[MPulse sharedInstance] enable];

Swift:

MPulse.sharedInstance().enable()

Automatic Network Request Instrumentation

Once included in the project, mPulse will automatically instrument all network requests.

Network requests will be instrumented as long as they are sent from one of the following classes (or a library that uses one of these classes):

  • URLConnection
  • URLSession

The following libraries (which use the above classes) will be instrumented:

  • AFNetworking
  • SDWebImage

Network Request Filtering

Network Request Filtering allows developers to selectively monitor the performance of specific network requests in the application. This means you can gather performance data for requests that are important to the user experience, while ignoring requests that are not relevant, such as other library’s analytics beacons.

You can modify the state of network request monitoring through either the mPulse UI or via the SDK at runtime. Network request monitoring can be in one of three modes:

  • ALL (Blacklist mode) (default): All network requests are instrumented. You can exclude specific URLs.
  • MATCH (Whitelist mode): Only those requests matching your criteria will be instrumented. Your Whitelist will control which URLs are included.
  • NONE: No network requests are instrumented.

The mPulse iOS SDK allows you to control the state of network request monitoring during runtime using the following SDK APIs:

Disable network request beacons (ie. set the mode to NONE):

Objective-C:

[[MPulse sharedInstance] disableNetworkMonitoring];

Swift:

MPulse.sharedInstance().disableNetworkMonitoring()

Enable network request beacons (ie. set the mode to ALL, Blacklist mode):

Objective-C:

[[MPulse sharedInstance] enableNetworkMonitoring];

Swift:

MPulse.sharedInstance().enableNetworkMonitoring()

Enable Whitelist-based network request filtering (ie. set the mode to MATCH, Whitelist mode):

Objective-C:

[[MPulse sharedInstance] enableFilteredNetworkMonitoring];

Swift:

MPulse.sharedInstance().enableFilteredNetworkMonitoring()

When these APIs are used, they will take precedence over the mPulse UI configuration, for the duration of the runtime of the application.

Programmatically Extending the Filters

The mPulse iOS SDK maintains a Blacklist and Whitelist (for ALL and MATCH modes respectively), and it will use these lists to filter URLs.

The mPulse UI allows you to control the Blacklist and Whitelist URLs within the app’s configuration dialog.

In addition, you can programmatically add URL filters at runtime. These filters will be amended to the app configuration from the mPulse UI.

If you wish to add to the Blacklist for ALL mode, you can use the example below. Returning a MPFilterResult with setMatched:YES will result in the network request not being monitored.

Objective-C:

[[MPulse sharedInstance] addURLBlackListFilter:@"Example.com Filter" filter:^MPFilterResult *(NSString *url) {
  // By default MPFilterResults are set to not matched.
  MPFilterResult *result = [[MPFilterResult alloc] init];

  if ([url isEqual:@"http://example.com"])
  {
    [result setMatched:YES];
  }

  return result;
}];

Swift:

MPulse.sharedInstance().addURLBlackListFilter("MyFilter") { (url) -> MPFilterResult? in
  // By default MPFilterResults are set to not matched.
  let result = MPFilterResult.init()

  if (url != nil)
  {
    if (url!.contains("example.com"))
    {
      result.matched = true
    }
  }

  return result
}

If you wish to add to the Whitelist for MATCH mode, you can use the example below. Returning a MPFilterResult with setMatched:YES will result in the network request being monitored.

Objective-C:

[[MPulse sharedInstance] addURLWhiteListFilter:@"Example.com Filter" filter:^MPFilterResult *(NSString *url) {
  // By default Filter results are set to not matched.
  MPFilterResult *result = [[MPFilterResult alloc] init];

  if ([url containsString:@"example.com"])
  {
    [result setMatched:YES];
    [result setViewGroup:@"My View Group"];
  }

  return result;
}];

Swift:

MPulse.sharedInstance().addURLWhiteListFilter("MyFilter") { (url) -> MPFilterResult? in
  // By default MPFilterResults are set to not matched.
  let result = MPFilterResult.init()

  if (url != nil)
  {
    if (url!.contains("example.com"))
    {
      result.matched = true
      result.viewGroup = "My View Group"
    }
  }

  return result
}

Send a Custom Timer

The mPulse iOS SDK can be used to send a Custom Timer.

You can track the time it took for an action to occur, such as an image upload or an attachment file download, using Custom Timers.

At the start of your action, call startTimer: and give it a Timer Name. startTimer: will return a unique Timer ID (NSString) and will keep track of the start time:

Objective-C:

NSString *timerID = [[MPulse sharedInstance] startTimer:@"TimerName"];

Swift:

let timerID = MPulse.sharedInstance().startTimer("TimerName")

At the “end” of your action, call stopTimer: by passing in the timerID. mPulse stops the timer and sends a beacon to the server:

Objective-C:

[[MPulse sharedInstance] stopTimer:timerID];

Swift:

MPulse.sharedInstance().stopTimer(timerID)

You may also directly specify a timer name and value (in seconds) using sendTimer::

Objective-C:

// value is NSTimeInterval
[[MPulse sharedInstance] sendTimer:@"TimerName" value:4];

Swift:

MPulse.sharedInstance().sendTimer("TimerName", value: 4)

By default, the View Group, A/B Test and Custom Dimensions for the timer will be copied at the time startTimer: was called. If you wish to use the View Group, A/B Test and Custom Dimensions copied when stopTimer: was called, you can specify true for the updateDimensions: parameter:

Objective-C:

// stops the timer and updates dimensions
[[MPulse sharedInstance] stopTimer:timerID updateDimensions:true];

Swift:

MPulse.sharedInstance().stopTimer(timerID, updateDimensions: true)

If you wish to cancel a timer (and not send a beacon to mPulse), you can call cancelTimer::

Objective-C:

[[MPulse sharedInstance] cancelTimer:timerID];

Swift:

MPulse.sharedInstance().cancelTimer(timerID)

Both startTimer: and sendTimer: accept a final parameter of MPulseMetricTimerOptions, which controls the behavior of Custom Timers while an Action is ongoing. See the Actions documentation for details:

Objective-C:

MPulseMetricTimerOptions* options;

// include on the Action beacon (instead of sending a separate beacon)
options.duringAction = MPulseDataDuringActionIncludeOnActionBeacon;

// if the same Custom Timer was used twice on this Action, SUM the results
options.onActionDuplicate = MPulseDataOnDuplicateSum;

NSString *timerID = [[MPulse sharedInstance] startTimer:@"TimerName" withOptions:options];

// or

[[MPulse sharedInstance] sendTimer:@"TimerName" value:10 withOptions:options];

Swift:

let options = MPulseMetricTimerOptions()

// include on the Action beacon (instead of sending a separate beacon)
options.duringAction = MPulseDataDuringAction.includeOnAction

// if the same Custom Timer was used twice on this Action, SUM the results
options.onActionDuplicate = MPulseDataOnDuplicate.sum

let timerID = MPulse.sharedInstance().startTimer("TimerName", with: options)

// or

MPulse.sharedInstance().sendTimer("TimerName", value: 10, with: options)

Send a Custom Metric

You may increment a Custom Metric by using sendMetric::

Objective-C:

[[MPulse sharedInstance] sendMetric:@"MyMetric" value:[NSNumber numberWithInt:23]];

Swift:

MPulse.sharedInstance().sendMetric("MyMetric", value: 23)

sendMetric: accepts a final parameter of MPulseMetricTimerOptions, which controls the behavior of Custom Metrics while an Action is ongoing. See the Actions documentation for details:

Objective-C:

MPulseMetricTimerOptions* options;

// include on the Action beacon (instead of sending a separate beacon)
options.duringAction = MPulseDataDuringActionIncludeOnActionBeacon;

// if the same Custom Metric was used twice on this Action, SUM the results
options.onActionDuplicate = MPulseDataOnDuplicateSum;

[[MPulse sharedInstance] sendMetric:@"MetricName" value:[NSNumber numberWithInt:10] withOptions:options];

Swift:

let options = MPulseMetricTimerOptions()

// include on the Action beacon (instead of sending a separate beacon)
options.duringAction = MPulseDataDuringAction.includeOnAction

// if the same Custom Metric was used twice on this Action, SUM the results
options.onActionDuplicate = MPulseDataOnDuplicate.sum

MPulse.sharedInstance().sendMetric("MetricName", value: 10, with: options)

Set View Groups

You may get, set, and reset the View Group. Once set, the View Group will be associated with every subsequent beacon.

View Group strings are limited to 100 characters, and can include any of the following:

  • 0-9
  • a-z
  • A-Z
  • (space)
  • _ (underbar)
  • - (dash)

Set a View Group using setViewGroup::

Objective-C:

[[MPulse sharedInstance] setViewGroup:@"MyViewGroup"];

Swift:

MPulse.sharedInstance().setViewGroup("MyViewGroup")

Reset the View Group using resetViewGroup::

Objective-C:

[[MPulse sharedInstance] resetViewGroup];

Swift:

MPulse.sharedInstance().resetViewGroup()

Get the current View Group using getViewGroup::

Objective-C:

NSString* viewGroup = [[MPulse sharedInstance] getViewGroup];

Swift:

let viewGroup = MPulse.sharedInstance().getViewGroup()

In addition, for each network request beacon, you can override the global View Group for that beacon by creating a filter and calling setViewGroup: on the MPFilterResult.

You can call setViewGroup: even if the result is un-matched. For example, in ALL (Blacklist) mode, you can call setMatched:NO so the network request is still monitored, and call setViewGroup: to set that request’s View Group. If multiple filters set the View Group, the result is undefined (the last filter will take precedence).

See the Network Request Filtering section for details.

Set A/B Test

You may get, set, and reset the A/B Test. Once set, the A/B Test will be associated with every subsequent beacon.

Set a A/B Test using setABTest::

Objective-C:

[[MPulse sharedInstance] setABTest:@"A"];

Swift:

MPulse.sharedInstance().setABTest("A")

Reset the A/B Test using resetABTest::

Objective-C:

[[MPulse sharedInstance] resetABTest];

Swift:

MPulse.sharedInstance().resetABTest()

Get the current A/B Test using getABTest::

Objective-C:

NSString* abTest = [[MPulse sharedInstance] getABTest];

Swift:

let abTest = MPulse.sharedInstance().getABTest()

Set Custom Dimensions

You may get, set, and reset Custom Dimensions. Once set, the Custom Dimension will be associated with every subsequent beacon.

Set or reset a Custom Dimension using setDimension::

Objective-C:

[[MPulse sharedInstance] setDimension:@"My Dimension" value:@"new value"];

Swift:

MPulse.sharedInstance().setDimension("My Dimension", value: "new value")

Reset the Custom Dimension using resetDimension::

Objective-C:

[[MPulse sharedInstance] resetDimension:@"My Dimension"];

Swift:

MPulse.sharedInstance().resetDimension("My Dimension")

Reset all Custom Dimensions using resetAllDimensions::

Objective-C:

[[MPulse sharedInstance] resetAllDimensions];

Swift:

MPulse.sharedInstance().resetAllDimensions()

Global Settings

The MPulseSettings class can be used to configure multiple SDK settings at once. MPulseSettings can be given to initializeWithAPIKey: to apply settings at startup, or later to updateSettings: to update multiple settings at once.

MPulseSettings has getters and setters for configuring the View Group, A/B Test, Custom Dimensions, Network Filters and Action settings.

When using MPulseSettings, any items that have not been set will not be changed:

Objective-C:

MPulseSettings* settings;
[settings setViewGroup:@"Default"];
[settings setAbTest:@"A"];
[settings setMaxActionResources:100];

// configure settings at init
[MPulse initializeWithAPIKey:MPULSE_API_KEY withSettings:settings];

// change settings later
[[MPulse sharedInstance] updateSettings:settings];

Swift:

let settings = MPulseSettings()
settings.viewGroup = "Default"
settings.abTest = "A"
settings.maxActionResources = 100

// configure settings at init
MPulse.initialize(withAPIKey: MPULSE_API_KEY, with: settings)

// change settings later
MPulse.sharedInstance().update(settings)

Actions

The mPulse iOS SDK allows you to monitor Actions, which are distinct user interactions.

Actions can be started at any time by calling startAction:, and can stopped by either calling stopAction:, or, by having the SDK automatically stop the Action once all network activity has finished.

The two Action modes are called Wait mode and Timeout mode:

  • Wait mode will wait for stopAction: to be called, and the duration of the action will be from startAction: to stopAction:
    • This mode is best when you want to define the Action’s start and end times in your application
  • Timeout mode (default) will monitor background network activity to determine when the Action has ended, and will set the end timestamp when the final network request is complete
    • This mode is best when the Action triggers multiple network requests. The SDK will monitor all of those requests automatically.
    • By default, the mPulse SDK will wait for 1,000ms after the final network request to see if any additional network requests are started (and if so, wait for those requests to complete)
    • This mode should only be used when the Action triggers network activity

All network requests during the Action will be included on the Action beacon’s Waterfall.

There can only be a single Action ongoing at a time.

Starting an Action

To start an Action, you call the startAction: API:

Objective-C:

// start an Action without a name
[[MPulse sharedInstance] startAction];

// or, start an Action with a specific name
[[MPulse sharedInstance] startActionWithName:@"MyAction"];

// or, start an Action with a name or other settings
MPulseSettings* settings;
[settings setActionName:@"MyAction"];
[settings setActionTimeout:[NSNumber numberWithInt:500]];
[settings setMaxActionResources:100];
[settings shouldTimeoutToStop];

[[MPulse sharedInstance] startActionWithSettings:settings];

Swift:

// start an Action without a name
MPulse.sharedInstance().startAction()

// or, start an Action with a specific name
MPulse.sharedInstance().startAction(withName: "MyAction")

// or, start an Action with a name or other settings
let settings = MPulseSettings()
settings.actionName = "MyAction"
settings.actionTimeout = 500
settings.maxActionResources = 100
settings.shouldTimeoutToStop()

MPulse.sharedInstance().startAction(with: settings)

Starting an Action while an existing Action is ongoing will abort the previous Action.

Wait Mode

In Wait mode, the mPulse iOS SDK will wait for stopAction: to be called. The duration of the Action will be from startAction: to stopAction:.

Any network activity that occurred during the Action will be included on the Action’s Waterfall.

Example:

Objective-C:

// start an Action
[[MPulse sharedInstance] startActionWithName:@"MyAction"];

// ... do stuff ...

// stop the Action
[[MPulse sharedInstance] stopAction];

Swift:

// or, start an Action with a specific name
MPulse.sharedInstance().startAction(withName: "MyAction")

// ... do stuff ...

// stop the Action
MPulse.sharedInstance().stopAction()

Timeout Mode

In Timeout mode, the mPulse iOS SDK will monitor all network activity. Once network requests begin to start, the Action will remain active until all network requests have finished.

After the last network request has finished, the SDK will wait the Action Timeout (default 1,000ms) to see if any additional network activity was triggered by the last request. If not, the duration of the Action will be set to the end of the final network request. If new activity is triggered during the waiting period, the SDK will wait until all network activity has finished again.

Action Settings

You can set global Action settings that will apply to all Actions, as well as overriding the global Action settings when starting a new Action.

Settings:

  • Action Collection Behavior: Whether to use Wait or Timeout mode
  • Action Timeout: How long, in Timeout mode, the SDK waits after the last network request has finished to ensure no additional network requests were started
  • Action Max Resources: The maximum number of network requests that will be included on an Action’s Waterfall. In Timeout mode, this does not limit how many network requests will be waited for, just how many network requests will be reported in the Waterfall.

Configuring global Action settings:

Objective-C:

// Timeout in milliseconds
MPulseSettings* settings;
[settings setActionTimeout:[NSNumber numberWithInt:2000]];

// Maximum number of resources on an Action's Waterfall
[settings setMaxActionResources:200];

// Wait mode
[settings shouldTimeoutToStop];

// Update the Global defaults
[[MPulse sharedInstance] updateSettings:settings];

Swift:

// Timeout in milliseconds
let settings = MPulseSettings()
settings.actionTimeout = 2000

// Maximum number of resources on an Action's Waterfall
settings.maxActionResources = 200

// Wait mode
settings.shouldTimeoutToStop()

// Update the Global defaults
MPulse.sharedInstance()?.update(settings)

You can overwrite the global Action settings when starting an Action:

Objective-C:

// Timeout in milliseconds
MPulseSettings* settings;
[settings setActionTimeout:[NSNumber numberWithInt:1000]];

// Maximum number of resources on an Action's Waterfall
[settings setMaxActionResources:300];

// Use these settings for the Action
[[MPulse sharedInstance] startActionWithSettings:settings];

Swift:

// Timeout in milliseconds
let settings = MPulseSettings()
settings.actionTimeout = 1000

// Maximum number of resources on an Action's Waterfall
settings.maxActionResources = 300

// Use these settings for the Action
MPulse.sharedInstance().startAction(with: settings)

Custom Metrics and Custom Timers during Actions

Custom Metrics and Custom Timers that occur while an Action is ongoing can be included on that Action beacon. Otherwise, Custom Timers and Custom Metrics will generate their own beacon.

The benefit of including Custom Timers and Custom Metrics on the Action beacon is that it ensures the context is kept – the Timer and Metric are linked directly to the Action.

When starting a Custom Timer or sending a Custom Metric, you can decide the what to do if an Action is ongoing. The MPulseMetricTimerOptions class configures this:

  • MPulseMetricTimerOptions.duringAction: What to do with a Custom Timer or Custom Metric when an Action is happening
    • MPulseDataDuringActionSendDirectBeacon: Send the Custom Timer/Custom Metric as a Custom Timer/Custom Metric beacon
    • MPulseDataDuringActionIncludeOnActionBeacon: (default) Include the Custom Timer/Custom Metric on the Action beacon

If the Custom Timer / Custom Metric is set to MPulseDataDuringActionIncludeOnActionBeacon, you should also decide what happens when a Custom Timer / Custom Metric is repeated during the same Action. An Action can only include a single named Custom Timer / Custom Metric per Action (Timer1 and Timer2 can both be included, but Timer1 can’t be included twice).

There are 4 options for what happens when a Custom Timer / Custom Metric occurs repeatedly during the same Action:

  • MPulseMetricTimerOptions.onActionDuplicate: What to do with a Custom Timer or Custom Metric when it is repeated during the same Action
    • MPulseDataOnDuplicateOverwrite: Overwrite the old value
    • MPulseDataOnDuplicateIgnore: Ignore the new value
    • MPulseDataOnDuplicateSum: Add the two values together
    • MPulseDataOnDuplicateSendDirectBeacon: (default) Convert the new value to an individual Custom Timer / Custom Metric beacon

Example usage:

MPulseMetricTimerOptions* options;

// include on the Action beacon (instead of sending a separate beacon)
options.duringAction = MPulseDataDuringActionIncludeOnActionBeacon;

// if the same Custom Metric was used twice on this Action, SUM the results
options.onActionDuplicate = MPulseDataOnDuplicateSum;

[[MPulse sharedInstance] sendMetric:@"MetricName" value:[NSNumber numberWithInt:10] withOptions:options];

Swift:

let options = MPulseMetricTimerOptions()

// include on the Action beacon (instead of sending a separate beacon)
options.duringAction = MPulseDataDuringAction.includeOnActionBeacon

// if the same Custom Metric was used twice on this Action, SUM the results
options.onActionDuplicate = MPulseDataOnDuplicate.sum

MPulse.sharedInstance().sendMetric("MetricName", value: 10, with: options)

Troubleshooting

No Beacons Being Sent

If you are not seeing beacons in the mPulse dashboards, please ensure the app has been configured correctly:

  • Ensure you are using the correct mPulse API Key in initializeWithAPIKey:
  • Ensure you see the following lines in the debug log after the application has started:

    mPulse Mobile build: n.n.n
    mPulse initialized.
    mPulse session has started.
    
  • If you are trying to send a Custom Timer or Custom Metric, ensure they have already been defined in the mPulse app configuration

  • Using a system proxy such as Fiddler or Charles, validate that:

    • There is a Config request to https://c.go-mpulse.net/api/config.json?...
    • There is a beacon being sent to https://*.mpstat.us or https://*.akstat.io

FAQ

  1. Why is this warning in my build logs?

    Ignoring file libMPulse[Sim].a, missing required architecture [arch] in file libMPulse.a ([n] slices)
    

    Answer: This is just a warning, and is expected. The mPulse libraries are split into two files (libMPulse.a and libMPulseSim.a) because of GitHub file size limits (100 MB), where the CocoaPod libraries are hosted. libMPulseSim.a is for simulators and libMPulse.a is for devices, and only one will be used at a time.

Opening Support Tickets

When opening new support tickets, please include the following information:

  • Platform: iOS
    • iOS SDK version
  • mPulse SDK version
  • Complete debug logs (i.e. console) from a device or simulator
  • If possible, the project’s Podfile or build configuration
  • If possible, a compiled IPA with the mPulse SDK integrated
  • If possible, code samples of:
    • mPulse initialization
    • Beacon filtering (if used)
  • If possible, the full project source code

Release Notes

The mPulse iOS SDK can be found on SOASTA/mPulse-iOS Github repository and CocoaPods.

2.3.6 (2019-01-17)

Bug Fixes:

  • Protect against empty Server URLs
  • Fix for EXC_BAC_ACCESS on startup on iOS 12

2.3.5 (2018-10-17)

Bug Fixes:

  • Rename classes to avoid MPSession conflict with MasterPass

2.3.4 (2018-05-17)

Bug Fixes:

  • Filtering applied only to Network beacons (and not Metrics, Timers, etc)

2.3.3 (2018-04-09)

Bug Fixes:

  • Fix an issue where user-defined Whitelist filters were not taken into account

2.3.2 (2018-02-15)

Breaking Changes:

  • Black/Whitelist filters must return MPFilterResult instead of BOOL

Bug Fixes:

  • Prevents a race condition for filter configurations
  • Prevents crashes on startup in some cases.

2.3.1 (2017-11-30)

Bug Fixes:

  • Fixes a bug with initialization

2.3.0 (2017-11-29)

Bug Fixes:

  • Network Filtering added

Bug Fixes:

  • setDimension resets the Custom Dimension if the value is empty

2.0.5 (2016-12-05)

Bug Fixes:

  • Timers, Metrics and Dimensions set before config.json is fetched now work
  • Removes third party JSON parser
  • Fixes exception on invalid config.json

2.0.4 (2016-07-25)

Bug Fixes:

  • Fixes MPulse symbol not found on Release builds

2.0.3 (2016-07-21)

Bug Fixes:

  • Fixes mPulse version string missing

2.0.2 (2016-07-21)

Bug Fixes:

  • Fixes CocoaPods duplicate symbols issue

2.0.1 (2016-07-20)

New Features:

  • stopTimer:updateDimensions added

2.0.0 (2016-06-15)

Bug Fixes:

  • First mPulse iOS SDK version 2.x