Releases: Iterable/react-native-sdk
1.3.11
1.3.10
This release points to the most updated version of the iOS SDK (6.4.10) and also includes several quality improvements such as
- providing descriptive comments to the Iterable.ts and IterableInAppManager.ts file
- adding instructions for implementation to the sample apps
- corrections to several unit tests
- addition of several unit tests
- updating eslint and enforcement of a consistent code style
- updating imports to prevent circular dependency issues
- fixing build.gradle to inherit config values from the parent project
1.3.9
Added
This release of Iterable's React Native SDK makes it possible for iOS apps to store in-app messages in memory, rather than in an unencrypted local file. (Version 1.3.7 added this same support for Android.)
To store in-app messages in memory on both iOS and Android, set useInMemoryStorageForInApps
to true
:
const config = new IterableConfig();
// ... other configuration options ...
config.useInMemoryStorageForInApps = true;
Iterable.initialize('<YOUR_API_KEY>', config);
When users upgrade to a version of your iOS or Android app that uses this version of the SDK (or higher), and they've enabled in-app memory storage, the local file used for in-app message storage (if it already exists) is deleted. However, no data is lost.
Deprecated
This release deprecates androidSdkUseInMemoryStorageForInApps
, which was introduced in version 1.3.7, and replaces it with useInMemoryStorageForInApps
. However, for now:
-
Android apps store in-app messages in memory if
useInMemoryStorageForInApps
istrue
,androidSdkUseInMemoryStorageForInApps
istrue
, or if both aretrue
. -
iOS apps store in-app messages in memory if
useInMemoryStorageForInApps
istrue
.androidSdkUseInMemoryStorageForInApps
does not affect iOS apps.
When you can, please update your apps to use useInMemoryStorageForInApps
instead of androidSdkUseInMemoryStorageForInApps
.
1.3.8
1.3.7
Changed
Starting with this release, as a privacy enhancement, Iterable's React Native SDK encrypts some data stored at rest.
iOS updates
In iOS apps, Iterable's React Native SDK now encrypts the following fields when storing them at rest:
email
— The user's email address.userId
— The user's ID.authToken
— The JWT used to authenticate the user with Iterable's API.lastPushPayload
— The JSON payload that came along with the last push notification received by the app.
(Note that, in iOS apps, Iterable's React Native SDK does not store in-app messages at rest—before or after this update.)
⚠️ Iterable's React Native SDK does, in fact, store in-app messages in an unencrypted local file—for Android and iOS apps. However, version 1.3.8 provides an option to store them in memory, instead.
When a user upgrades to a version of your app that uses this version of the SDK (or higher), the fields shown above are encrypted. No data that's already stored is lost.
For more information about this encryption in iOS, examine the source code for Iterable's iOS SDK (upon which the React Native SDK relies):
Android updates
For Android, this release includes support for encrypting some data at rest, and an option to store in-app messages in memory.
Encrypted data
In Android apps with minSdkVersion
23 or higher (Android 6.0) Iterable's React Native SDK now encrypts the following fields when storing them at rest:
email
— The user's email address.userId
— The user's ID.authToken
— The JWT used to authenticate the user with Iterable's API.
(Note that, in Android apps, Iterable's React Native SDK does not store the last push payload at rest—before or after this update.)
For more information about this encryption in Android, examine the source code for Iterable's Android SDK (upon which the React Native SDK relies): [IterableKeychain
](https://github.com/Iterable/iterable-android sdk/blob/master/iterableapi/src/main/java/com/iterable/iterableapi/IterableKeychain.kt).
Storing in-app messages in memory
This release also allows you to have your Android apps (regardless of minSdkVersion
) store in-app messages in memory, rather than in an unencrypted local file. However, an unencrypted local file is still the default option.
To store in-app messages in memory, on IterableConfig
, set androidSdkUseInMemoryStorageForInApps
to true
(defaults to false
):
const config = new IterableConfig();
// ... other configuration options ...
config.androidSdkUseInMemoryStorageForInApps = true;
Iterable.initialize('<YOUR_API_KEY>', config);
When users upgrade to a version of your Android app that uses this version of the SDK (or higher), and you've set this configuration option to true
, the local file used for in-app message storage (if it already exists) is deleted. However, no data is lost.
Android upgrade instructions
If your app targets API level 23 or higher, this is a standard SDK upgrade, with no special instructions.
If your app targets an API level less than 23, you'll need to make the following changes to your project (which allow your app to build, even though it won't encrypt data):
- In
AndroidManifest.xml
, add<uses-sdk tools:overrideLibrary="androidx.security" />
- In your app's
app/build.gradle
:
- Add
multiDexEnabled true
to thedefault
object, underandroid
. - Add
implementation androidx.multidex:multidex:2.0.1
to thedependencies
.
1.3.6
This release includes the serialization fix for the action context.
1.3.5
This release fixes issues with updateEmail and updateUserId. Also, provides additional methods to handle authHandler success and failure callbacks.
1.3.4
This release updates the setEmail, setUserId, and updateEmail to accept an auth token as a parameter.
1.3.3
This release points to the most updated versions of the iOS SDK (6.4.5) and Android SDK (5.4.7). The mobile inbox functionality is updated to include toggling of the navigation title and custom action handling.
1.3.2
This has a fix for our index.ts
being setup incorrectly (thanks, @alex-a-pereira !), and adds a new option in IterableConfig
to disable logging, set logReactNativeSdkCalls
to false
when you'd like to send/publish out a build without React Native side logging enabled. Native (Android/iOS) side logging is still independently controlled by logLevel
(this is completely unchanged).