Integrations and SDKs

Integrating an external service depends on the specific SDK or service and requires a prior technical evaluation. This page describes the possible routes, what each one involves and what information is needed to evaluate them.

The three integration routes

Web route. The provider works with a script on your store. Web-based integrations can keep working inside the WebView when they are compatible with that environment, with no need to modify the binary. It is the usual route for analytics and content personalisation.

API route. The integration happens between servers: your system talks to the provider’s, or to the push API, which is the public Reskyt API currently available. It does not affect the app.

Native SDK route. The provider publishes a library for iOS and Android that is compiled into the binary. It is required when the feature needs access to the operating system: notifications handled by the provider, install attribution, biometrics, camera, or a native payment flow.

The first question for any integration request is which of the three routes it requires. When specifically native capabilities are needed, an integration through an SDK or native development may be required; in all other cases, the web route or the API route are usually enough and do not require a release cycle.

When the app has to be modified

Whenever the integration goes through a native SDK. That means recompiling, submitting for review in both stores and waiting for users to update. Until then, the SDK is not on the devices.

The planning consequence: it is better to group several SDKs into the same release than to publish once per provider.

Impact on iOS and Android

An SDK may not exist for both platforms, or may behave differently on each one. Before committing to an integration you have to confirm that the provider publishes a library for both and which minimum operating system versions it requires, because that can force the app’s minimum supported version up.

Permissions and privacy

An SDK can request system permissions (notifications, camera, tracking) and collect data. Both have consequences outside the code:

The privacy declaration in App Store Connect and Play Console must reflect what the SDK collects, and it is updated in the same release.

If the SDK does advertising tracking, it also enters the territory of user consent, which is settled during project setup.

What we need to evaluate an SDK

1. Provider name and a link to its technical documentation for iOS and Android.
2. Minimum operating system versions it requires.
3. System permissions it requests.
4. Data it collects and where it sends it.
5. Whether it needs a bridge with the WebView or works on its own.
6. Whether the provider offers integration support and under what conditions.
7. Credentials or a test environment to validate against.

With that, we can say whether the integration is feasible, through which route, and what it involves.

The timeline and the conditions of the integration are settled when the evaluation closes.

Testing and validation

An integration is considered complete when you verify that the provider receives the expected data. That verification requires access to their panel during validation, which is best requested at the start of the process.

Limitations to consider

No SDK is automatically compatible. It may have no library for one of the two platforms, conflict with another module already active, require an operating system version higher than the one supported, or need a bridge with the WebView that is not resolved.

Each of those factors affects the scope and the timeline of the integration, and that is what the prior technical evaluation determines.