Both Android and iOS SDKs are compatible with React Native. We do not, however, provide a React native wrapper, it is up to the customer to create one. If there is a demand for it, we can consider making our own React Native wrapper in the future.

Both Android and iOS SDKs are compatible with Flutter and Xamarin. We do not, however, provide a wrapper, it is up to the customer to create one. Should there be a demand for it, we can consider making our own Flutter and/or Xamarin wrapper.

We support basic accessibility features.

Currently, offline mode is not supported. We will be able to consider this in future as a feature of the Mobile Consent Solution.

All texts are provided by the platform and can be changed at any time without redeploying the app. If you want to update the SDK in your apps that will, however, require re-deployment.

Unlike webpages, mobile apps don't load their source code from a server, they are instead installed on a mobile device's internal storage in a so-called binary package. In layman's terms, the original source code was converted by a program called a compiler into machine language (the famous ones and zeros).

This also means that there is no need for a browser or any other program to show these apps - they are self-contained and have everything they need to run inside their package. Both Apple and Google are committed to privacy and app security, and therefore don't allow any other app to access the data that was saved by a different app. On a vanilla device with an app downloaded from AppStore or PlayStore you won't be able to check if the trackers are being blocked or not.

To verify the CMPs blocking function you need to prepare a little more elaborate setup with the following components:

After verifying that the target device is tunnelling data through the proxy, you need to start the app that is being tested, and without consenting to anything but necessary use the app for a few seconds and observe if any of the outgoing traffic contains web addresses that are suspicious. If you find suspicious addresses, it is possible to enable so-called "SSL" proxying that enables the intermediary (the proxy server) to swap the SSL certificate of each request on the fly and use its own certificate which allows us to read the contents of network calls that would otherwise be encrypted (HTTPS).

You must use the App Tracking Transparency framework (ATT) if your app collects data about end users and shares it with other companies for purposes of tracking across apps and websites. The App Tracking Transparency framework presents an app-tracking authorization request to the user and provides the tracking authorization status.

The ATT, however, only covers one part of the equation and does not make you GDPR compliant. The ATT and MCS go hand in hand together to cover you both legally (MCS - GDPR) and technically (ATT - Apple's requirement, not a legal one).

By not allowing cross-app tracking in ATT, iOS won't allow you to use the device’s advertising identifier. This is a unique ID that can be used to collect user behaviour across apps even if the user is not logged in. It is primarily used by advertisers to profile users and deliver ​​​​​​​personalised ads.

Since both ATT and MCS are invoked by the developer, it is in their hand to handle the flow correctly, such as:

​​​​​​​​​​​​​​Notes:
It might be confusing how and which framework to use, so here's a little cheat sheet:

Case 1: User consents to tracking in MCS -> invoke ATT dialogue -> user agrees to cross-app tracking -> track all you want

Case 2: User consents to tracking in MCS -> invoke ATT dialogue -> user does not agree to cross-app tracking -> you can track, but you cannot use the device’s advertising identifier.

Case 3: User does not consent to tracking in MCS -> you cannot invoke ATT and cannot track any personally identifiable data (the system will still share crash reports with the developer if the user allowed it during the iPhone onboarding)