ForeSee Developer Portal

Everything you need to configure and optimize your ForeSee products. Home of developer documentation, implementation guides, and release notes.


Common Problems

When implementing the iOS SDK, you may encounter some compile time or runtime errors. This document aims to summarize such errors.


Many common errors are caused by configuration issues that are automatically handled when using CocoaPods. The latest ForeSee CocoaPod can be found here:

General Invitation Issues

"The invitation isn't showing when I expect it to."


There are a number of reasons the invitation may not be showing. Verify the following items when testing the display of invitations:

  1. Ensure you have a working network connection that is not being restricted by a firewall or proxy. The SDK must be able to contact ForeSee servers before showing an invitation.
  2. Ensure that the invitation is not being declined due to a failed sampling check. If your sampling check is set to less than 100%, you may find it useful to call [ForeSee setSkipPoolingCheck:YES] to skip the check. Note: The skip method should not be used in your production environment.
  3. Ensure you start from a 'Tracking' state. Once it has displayed an invitation, the SDK changes state to restrict the number of invitations shown to the same user. The state can be reset by one of the following:
    1. Uninstall and reinstall the app.
    2. Call [ForeSee resetState]. This also resets all other SDK information, including the launch count, first launch date, and any significant events. As such, this call should not be made in the production environment.
  4. Make sure you are calling [ForeSee checkIfEligibleForSurvey] in the correct place. Calls placed in AppDelegate:application:didFinishLaunchingWithOptions only run on the first app launch or after the app is completely removed from memory. To check for eligibility every time the user switches to the app, add the check into AppDelegate:applicationWillEnterForeground:
  5. Make sure you are meeting the Trigger criteria. If you require five launches in your configuration file, make sure the app has been launched five times.

"I'm experiencing a drop in respondents after a new release."


A drop in respondents can occur for a number of different reasons:

  1. A change in the ForeSee® SDK may produce a change in behavior. For example, a fix was made in v3.2 of the SDK, which means fewer users are successfully sampled. This can affect you if you upgraded from an SDK version prior to 3.2. However, if you are seeing lower respondent counts and have changed to any SDK version in your new release, please contact us for additional support.
  2. You've changed the position of the eligibility check in your app so that...
    1. Some users no longer hit that point in the app.
    2. Users are less likely to take a survey at the point you've chosen.
  3. A reduction that leaves close to zero respondents could indicate that a change in your app code means your app is no longer implementing the SDK correctly. Remember that some respondents could still be on a previous version. Please check the calls to the ForeSee® SDK against the instructions in the Getting Started guide.
  4. A change has been made in the configuration you use (invitation criteria, repeatDays, etc.) which means fewer users become eligible. Please compare your foresee_configuration.json file both before and after your release to see if any changes have been made.
  5. A change in the OSs or devices used by your users has not been allowed for in the SDK. One example is compatibility for 64-bit devices, which was added in v3.3. While ForeSee strives to keep the SDK up to date with the latest technology, earlier versions of the SDK are likely to contain compatibility issues. Please be sure to upgrade to the latest version of the SDK for each new release.

Compile-time errors

Unrecognized selector

[UIDevice fs_isTablet]: unrecognized selector sent to instance

This is handled automatically when using CocoaPods.


The ForeSee.framework makes use of Objective-C categories. The -ObjC flag must be added to OTHER_LDFLAGS in the project settings.

Apple Mach-O Linker Error

This is handled automatically when using CocoaPods.


The ForeSee.framework requires linking a number of iOS frameworks. See the Getting Started guide for more information.

Runtime errors

Configuration not found

4c (l) – Configuration not found displays in the XCode console.


This indicates that the foresee_configuration.json file has not been added to the project.

New Relic error - NRInvalidArgumentException

Terminating app due to uncaught exception 'NRInvalidArgumentException', 
reason: 'New Relic detected an unrecognized selector, 
'fs_viewWillAppear:', sent to 'UIViewController'. It's possible _cmd was 
renamed by an unsafe method_exchangeImplementations()

This issue was fixed in ForeSee SDK 4.3.2.


This is a known issue with how New Relic reports on method swizzling implementations. Many other frameworks have reported similar issues:

Here's one example (with some explanation).

In the short term, you can work around the issue by disabling interaction tracing:

[NewRelicAgent disableFeatures:NRFeatureFlag_InteractionTracing];
[NewRelic startWithApplicationToken:<appToken>];

The ForeSee iOS SDK and New Relic should function smoothly together, even though both swizzle the same method. However, New Relic continues to report this error unless you disable interaction tracing.

Errors uploading to the App Store

Unsupported architectures

iTunes Store Operation Failed
ERROR ITMS-90087: "Unsupported Architectures. The executable for 
Berkshire&Nash contains 
unsupported architectures '[x86_64, i386]'."

This is handled automatically when using CocoaPods.

Your app contains simulator images, which are not allowed in App Store submissions.

The framework object file delivered in the SDK contains architectures for both simulators (x86_64, i386) and real devices (armv7 armv7s arm64):

$ lipo -info lib/ForeSee.framework/ForeSee
Architectures in the fat file: lib/ForeSee.framework/ForeSee are: 
x86_64 i386 armv7 armv7s arm64

The App Store rejects executables that include simulator architectures, so they must be removed before uploading. CocoaPods handles this task automatically. If you can't use CocoaPods, for some reason, then these architectures must be manually removed using one of the techniques detailed in these links:

Common Problems

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.