SDK FAQs
Frequently Asked Questions about the Interaction SDK
Last updated
Was this helpful?
Frequently Asked Questions about the Interaction SDK
Last updated
Was this helpful?
Monterosa / Interaction SDK supports iOS 13+, Android 6+ and most modern web browsers. It also supports support React Native with a limited feature set.
Please see for more in-depth information.
We take the stability of the SDK very seriously and use a minimum of third party code.
iOS depends on , and . SwiftyJSON is slated to be removed in the next version of the SDK.
Android depends on for network stack management and Google's for JSON parsing.
SDK for Web depends on for event management and for UUID generation.
iOS adds around 2MB to the app's binary size, resulting in only a minimal increase in the app's initial download time.
Android increases the final binary size by around 700KB, without a noticeable impact on performance or download time.
We distribute our JS SDK as a set of npm modules with the following characteristics:
Readable Code: The distributed code is not obfuscated.
Non-Compressed: Modules are provided without compression.
Bundled as a Single File: Each module is bundled into a single JavaScript file.
Transpiled to ES2017: The code is transpiled to ES2017 for better compatibility with modern JavaScript environments.
This distribution method results in larger file sizes. However it also allows developers to further optimise the codebase during the final build of their application. This includes additional bundling, tree-shaking, transpilation, obfuscation, and compression, enabling customised optimisations based on specific use cases.
Below are the current file sizes for each module bundle (as of 1.0.0-rc.1):
analytics-kit
4 KB
connect-kit
15 KB
core
9 KB
enmasse
52 KB
identify-kit
33 KB
interact-kit
75 KB
launcher-kit
59 KB
util
24 KB
All Modules Combined: 268 KB
Minimum Required to embed an experience (core + util + launcher-kit): 91 KB
Note: These sizes are pre-compression and pre-optimisation. When bundled by third-party developers, additional optimisations can greatly reduce the overall size. For example, compressing the
interact-kitmodule alone can reduce its size from 75 KB to 16 KB (a reduction of approximately 4.5 times).
The SDK’s load behaviour — whether it is asynchronous or blocking — depends on how it is integrated by third-party developers. While the SDK includes some internal fetch operations, the initial loading is primarily controlled by the developer's implementation strategy.
The volume of traffic exchanged between the SDK and the backend varies based on the complexity of the user experience. Communication is also spread between CDN, WebSockets and APIs.
Typically, the application will download several megabytes of code and graphical assets upon initialisation. Following this, it will consume only a minimal amount of data, generally measured in single kilobytes per minute, during real-time interactions.
Media files that are content managed on a per-event and per-experience basis tend to be the primary contributors to overall traffic volume. To address this, Monterosa / Interaction Cloud offers specialised tools and workflows designed to optimise media asset management and minimise unnecessary data consumption, such a limiting headshot filesizes.
Monterosa / Interaction SDK does not collect its own crash information for compliance reasons.
Instead, we request our customers to supply us with any evidence of crash behaviour that might be related to the SDK and we're proud to say that there have been no crashes reported in the current version of production applications.
The SDK uses TLS-encrypted network protocols such as HTTPS and WSS when communicating with back-end APIs.
SDKs for iOS and Android store data in the app-scoped storage, which is not available to any other application or the users of the device.
SDK for Web stores data in the domain-scoped local storage. All new deployments use customer-scoped domains and content security policies to minimise vulnerability to CSRF/XSS attacks.
Transactional data depends on your use case. This may include user responses to interactive games, data form submissions and any other data points explicitly tied to the user experience.
If your application includes user identity integration, the SDK will send the user's proof of identity such as an access token to the back-end for authentication.
By making direct network calls to Monterosa back-end APIs, the SDK implicitly exposes the user's IP address and metadata, such as the browser's User-Agent string.
The SDK does not send data to any third party services.
The SDK does not require any user-obtained app permissions.
Our SDK does not track any identifiable user data. We do not perform any tracking on the SDK side, so there is no information related to privacy settings that needs to be passed. Since no tracking occurs, the user's decision to reject tracking does not affect the SDK's functionality.
The JavaScript SDK stores various types of data in localstorage. Below is a detailed description of the data saved by the SDK:
SDK Version
Module
Key
Description
>=0.16.12 && <1.0.0
core
monterosa_sdk_device_id
Used to uniquely identify the user's device
>=1.0.0
identify-kit
client_id
Stores the client_id returned by the Identify service
all
connect-kit
enmasse_session_id
Enmasse server user session identifier. This value is stored indefinitely for the domain and is used to restore the Enmasse session for returning users. It also enables accurate user statistics to be provided in the Studio.
all
interact-kit
element_<elementId>_vote
Stores user votes associated with specific elements
Currently, there is no option to prevent the JavaScript SDK from storing these values in localStorage. If localStorage is available, the SDK will use it as the primary storage mechanism.
The team runs a regular cadence of sprints and releases, with selected updates being made available publicly.
Every effort is made to ensure the SDK remains backwards-compatible within a major version — i.e. version 0.3.x will be backwards-compatible with 0.2.x.
Monterosa takes responsibility for maintaining a superseded major version of the SDK for at least a year after a new major version has been released.
Once a new version becomes publicly available, it is added to the platform-specific . New releases are also communicated via internal support channels and a dedicated SDK mailing list — to be added.
A new major version release of the SDK such as the migration from 0.x.x to 1.x.x, may introduce breaking changes that will be highlighted in the , alongside any required migration instructions.