React Native

Collect the User Consent in React-native App.

Introduction: Why ask for the user's consent.

The European General Data Protection Regulation (GDPR) requires mobile apps that mine user's data for tracking and ad targeting purposes to first obtain their consent through a graphical interface clearly and explicitly, On top of that, recently Apple launched its App Tracking Transparency (ATT) policy that requires all mobile apps in the apple store, starting from ios 14. 5, iPadOS 14.5, to obtain the user permission through the ATT framework to track them or access their device's ad ID. This made the consent collection in mobile devices more confusing.

In this article, we will explain how to handle both of these legislative constraints by defining the scope of your user consent of each case, and then, we will give an example of how to implement a custom consent collection system on a react-native application with both theses two constraints considered.

Define the consent scope

SOme Definitions

- GDPR: the GDPR (stands for General Data Protection Regulation) is an EU regulation that aims is to enhance individuals' control and rights over their personal data, it concerns any organization, public or private, regardless of its size, country of establishment, and activity, which processes personal data on its behalf or not, as long as it's established on the territory of the European Union, or if its activity directly targets European residents.

This means that companies must take into account the principles aimed at protecting personal data from the design phase of the mobile application. These principles are lawfulness, fairness, transparency, purpose limitation, data minimization, accuracy, retention limitations, integrity, and confidentiality.

- ATT: App Tracking Transparency (ATT) is Apple's new privacy settings that requires ios developers to use the ATT framework to request users' permission to track them or to access their IDFA (advertising identifier) if the app collects end-user data or shares it with other companies for tracking purposes.

The goals of ATT looks very similar to GDPR, but the purpose of Appel is clear, ATT is intended to make the privacy process more intuitive for the end-user, "Apps must respect the user's permission settings and not attempt to manipulate, trick, or force people to consent to unnecessary data access.".

  • The IDFE is the standard adopted by Apple that allows mobile ad networks to track users and display targeted ads to them.

Comparison table between gdPr & att

There you can find un small comparison between both ATT and GDPR requirements.


++table style="border-collapse: collapse; table-layout: fixed; border: 1px solid #99acc2; height: 832.309px; margin: 1px auto 0px; width: 613px;">++tbody>++tr style="height: 125px;">++td style="border: 1pt solid windowtext; width: 60.1562px; height: 125px; padding: 2px;">


++/td>++td style="border: 1pt solid windowtext; width: 120.33px; height: 125px; padding: 2px;">

Concerned case

++/td>++td style="border: 1pt solid windowtext; width: 156.424px; height: 125px; padding: 2px;">


++/td>++td style="border: 1pt solid windowtext; width: 143.368px; height: 125px; padding: 2px;">

Technical solution

++/td>++td style="border: 1pt solid windowtext; width: 131.389px; padding: 2px; height: 125px;">


++/td>++/tr>++tr style="height: 375.486px;">++td style="border: 1px solid windowtext; width: 60.1562px; height: 375px; padding: 2px; vertical-align: middle;">


++/td>++td style="width: 120.33px; height: 375px; padding: 2px; border-width: 1px; border-style: solid;">

- Exploit any user or device level identifier such as IDFE, email, session ID?  For advertising or ad measurement purposes.

++/td>++td style="width: 156.424px; height: 375px; padding: 2px; border-width: 1px; border-style: solid;">

- Any data collected from ios Users starting from version 14.5.

- includes any third-party SDK or website integrated into a web view that collects data.

++/td>++td style="width: 143.368px; height: 375px; padding: 2px; border-width: 1px; border-style: solid;">

- should use the ATT framework.

- can't change its graphical interface.

- Can Use an interface to explain why asking for permission to track before showing ATT pop-in.

++/td>++td style="width: 131.389px; padding: 2px; height: 375px; border-width: 1px; border-style: solid;">

- Should be shown à the launch time.

++/td>++/tr>++tr style="height: 358.993px;">++td style="border: 1pt solid windowtext; width: 60.1562px; height: 359px; padding: 2px;">


++/td>++td style="width: 120.33px; height: 359px; padding: 2px; border-width: 1px; border-style: solid;">

-Any business that collects, transfers or processes personal data.

++/td>++td style="width: 156.424px; height: 359px; padding: 2px; border-width: 1px; border-style: solid;">

- All user interfaces (mobile apps, website, ...) of a company established on the territory of the European Union, or its activity directly targets European residents.


++/td>++td style="width: 143.368px; height: 359px; padding: 2px; border-width: 1px; border-style: solid;">

- Custom tool or third-party Consent Management SDK.

- Should be freely given, specific, informed, and unambiguous.

++/td>++td style="width: 131.389px; padding: 2px; height: 359px; border-width: 1px; border-style: solid;">

- Should be shown at the time the app collects the data (most cases at a launch time too). - Should allow the user to modify his consent at any time.



conclusion: which framework to use to ask for user consent

In the case of android, the only constraint that exists is the GDPR rules. In the case of Apple, if you have any doubt about whether to use ATT Framework or use a customized consent collection solution, it is recommended to ask for the user permission through both the two solutions, so the user will be prompted to give his consent two times at the app launching. this user path may be slow for the user, but at least you are sure not to get rejected from the Apple store, or to disregard the rules of the GDPR, and that's what we did on my current working project.

Note: if your consent-request options include all ATT request options, apple allows you to hide ATT pop-in only in the case the user didn't give his consent, but the contrary is false.


One solution is to develop your solution using a customized pop-in. be aware that your ATT pop-in should be displayed conditionally to whether the user gave consent through the GDPR tool.

This is a logical script of how to manage user consent :

After collecting the user consent, we use the react-native-async-storage to save this consent during each app launch.

React-Native-Async-Storage is a key-value storage system that is global to the app, it works the same way as the local Storage on the web, so it's persistent for the whole life of your application, that allows us to ask for the user consent only in the first opening of the app after installation.

The implementation is made in several steps :

- Initialize the context: When the user opens the application, you should disable any tools that require the user consent, because we don't have the information on whether the user gave his consent or not. 

- Check if there is a consent configuration saved in the local storage:

- If no consent is configured, we show the pop-in to ask the user for his consent, and then we save it in the async-storage, this operation will be done only the very first time the user opens the app.

- If there is already a consent saved, we go to the next step.

- If at least one consent option is given by the user, call the ATT interface. 

React-native provide a complete react-native node module (react-native-tracking-transparency) that allow you to implement the ATT framework, follow this link for more implementation details:

Process the consent response: when we have the user's consent response, we can iterate for each consent-request option, if the user agrees we activate the tool, otherwise, we keep it deactivated. This is an example of the function onSaveConsent where we disable the Google analytics tool :

++pre>++code>++code data-line-start="1" data-line-end="5">const onConsent = async (storedConsent: ConsentParameters) => {

where storedConsent type has those params (boolean for each tool):

++pre>++code>++code data-line-start="1" data-line-end="5">type ConsentParameters = {
 ContentSquare?: boolean;
 Eulerian?: boolean;
 GMP_FL?: boolean;
 google_analytics?: boolean;


Don't forget to give the user the possibility to change his consent, this can be done by adding a configuration section in your app to show the consent pop-in again based on stored consent.

It should follow exactly the same logic then as above, but you should not display the ATT framework whatever the user response is.

you can find all the details of the implementation of the project in my Github repo:

case of displaying web content through a web-view

If you open a web application using a web-view, you should treat this web app the same way as native functionality, unless you are enabling the user to navigate the open web.

For example, if this web app requires the same consent as your native app, you should manage it at the app launching by sharing the consent that the user has configured in the beginning to your web view. You should also avoid that the web app asks a second time for this same consent as it does it by default, because this behavior is not user-friendly, and It may seem like an attempt to influence the user to give consent, which can be refused by the google or apple stores.

shared the consent configuration from the react-native to this WebView

React-native-webview library allows you to share data from react-native to a web-view via the parameter injectedJavaScriptBeforeContentLoaded, thus when you open the WebView, we can provide it with a JavaScript that will be injected into the web page after the document element is created, but before other sub-resources finish loading.

So if your web app uses cookies to save the consent, you can inject cookies directly in the DOM, you can also inject a callback function script that will set cookies param with the user value, or you can directly inject the consent value in the DOM, and in the web-app side, manage your consent depending on this values as in the example below :++code data-line-start="1" data-line-end="44">++/code>

++pre>++code>const NativeToWeb = (props) => {

 // ------------- consent configuration received from the user ----------
 const consentConfig = {
   ContentSquare: true,
   Eulerian: true,
   GMP_FL: true,
   google_analytics: false,

 }; // ------------- data to send to the web view ----------
 const data = `const consentConfig = {
   ContentSquare: ${consentConfig.ContentSquare},
   Eulerian: ${consentConfig.Eulerian},
   GMP_FL: ${consentConfig.GMP_FL},
   google_analytics: ${consentConfig.google_analytics}}`;

 return (
<SafeAreaView style={styles.flexContainer}>
           html: `<body style="display:flex;justify-content:center;">
<h2>React native webview</h2>
<button style="color:red; height:100;width:300;"
onclick="showConsent()">show consent params</button>
<p id="demo"></p>
function showConsent() {
if (consentConfig) {
window.alert('consentConfig.ContentSquare : '
                            +  consentConfig.ContentSquare)
window.alert('no consentConfig setted');

++pre>++code data-line-start="1" data-line-end="44">++/code>++/pre>

After the DOM finishes loading, you can then use the consent configuration If it's set. In the example below, we just displayed it as an alert, but you can set your cookies, or set your consent through a consent-management-SDK ...

Result :
CUSTOM solution Limitations

Development & Maintenance cost: in total, you have to develop for your custom pop-in, the store & retrieve consent system, the shared consent between react-native and your web view, which can cost you a lot of time and effort. And if we need to change any element of your consent pop-in, such as adding a new option or changing the style, we are obliged to publish a new version of your application and go through the whole development, testing, and publishing processes that make production launches slower and expensive.

Other solution: Use an external SDK 

There are a lot of external SDKs that manage all the process of collecting the user consent, and that offer more or fewer functionalities as user statistics, design templates ...

Basically, they offer to process the same at least this following stack :

  • For each user, check if we should be compliant with the GDPR, using this geolocation, IP address, or timezone.
  • manage the collection and storage of consent
  • Interact with the user via a user-friendly interface that you customize in their back-office.
  • allows you to implement on multiple apps
  • Provides detailed usage statistics.


The advantages of using these tools are that you have more flexibility when you need to change your consent pop-in interface, or to update the content of your consent form, so you don't need any more go-throw development processes. 


Conclusion : 

- The requirements of ATT are very similar to the GDPR and can be confused.
- The primary objective of Apple through the ATT is to make the consent collection process more intuitive for the user.
- It is necessary to make a study of the need to comply with the RGPD and the ATT according to the scope of each before starting the implementation of its solution.
- it is possible to develop its own solution to collect the consent of the user, but it has limits, so it is necessary to consider the use of a third-party SDK.
- Be aware that if you implement a web view, you have to treat it as another functionality in the application.

Développeur Mobile ?

Rejoins nos équipes