Mobile App Consents are a new product from Cookie Information, giving you the ability to collect consents on mobile applications for both Android and iOS.

This allows you to make sure that you are respecting user consents in regards to things like newsletters, product updates, advertising, analytics, or any Personal Identifiable Information (PII) you collect via your application.

Why you need to collect Mobile App Consents

Just like you currently do with our solution for your own websites, it's important to remain compliant with DPA and GDPR.

This way you can ensure that you're only sending and storing data that your user has consented to (whether it is their own data, or for analytics and advertising purposes).

Currently as the product is in the first iteration, there are a few prerequisites in order to be able to use it. If you are interested in enabling Mobile App Consent on your account, please email

Once we're sure that the prerequisites are met, we'll be able to activate Mobile App Consents as an option for you that you'll find next to the "Consent Solutions" tab within the Cookie Information platform.

Please be aware that due to the differences between setting up a Mobile App Consent Solution and a standard Consent Solution for your website (which are explained in more detail later on in this article), you will need the help of a developer if you are not maintaining the mobile application yourself.

Just like a Consent Solution contains your domains that you have pop-ups on, a Consent Solution in the case of Mobile App Consents contains different "agreements" - otherwise known as Consent Items.

"Agreements" are anything that a user can agree or decline to when they are using your application. Because not all applications will collect the same kind of information or use Advertising (as an example), you are free to create as few or as many as you need to cover every use case for your own rather than having to edit a list of given agreements.

It's important to note that agreements do not have to specifically be GDPR related - they can be for any purpose related to privacy and data protection. This includes how data is stored, used, and processed.

Data Flow Overview of the Mobile App Consent Solution

The above picture gives a visual overview of the steps and process for correctly implementing a Mobile App Consent - which starts in the Cookie Information platform by creating your first solution and adding your agreements.

This Mobile App Consent and contained agreements are delivered (as JSON) via our CDN to your mobile application.

The consent request is then sent from your application to your server where it is validated.

The authorised and newly validated consent request is then communicated from your server to Cookie Information's server, where it finally goes back to the platform. All of this is made easier by using our SDK, which provides an easy way to integrate with both Android and iOS apps.

Once Mobile App Consent has been enabled on your account you will be able to create your consent solution in the platform, similar to how you already do with Consent Solutions for domains.

You are able to:

  • Give your Mobile App Consent Solution a name
  • Specify which mobile application it is for
  • Specify whether the Mobile App Consent is for Android or iOS (or both)
  • Give a short description of what your mobile application is about

Once this is done, you will then be ready to add your first Consent Item ("agreement"). Remember that there's no limit to the number of Consent Items your Mobile Consent Solution can contain.

To create your first Consent Item, click on the orange button as shown:

You will then be presented with the following options:

  • Fill in the name of your Consent Item (e.g. Terms of Service, Use of Advertising, Newsletter etc)
  • Select the language(s) that you would like the Consent Item to be available in
  • Click Next

You'll then be able to give a short and long description of each item (both of which can be displayed to the user if you wish).

Implementing the Mobile App Consent SDK Into Your Mobile Application

Once your Consent Solution and Consent Items have been created, you'll be presented with the SDK for your chosen operating system(s).

To properly integrate the SDK, you'll need the help of a mobile application developer if you are not the one who is building and maintaining the application.

To get started with integrating the SDK, you'll need to add a dependency so that it is included in your project.


For Android you need to add the dependecy in the file called:


If you're using Groovy DSL, then the line you'll need to add is:

implementation "com.cookieinformation:mobileconsents:<latest_release>"

If you're using Kotlin DSL, then the line you'll need to add is:


For instructions on how to initialise the SDK, sending consent to a server, as well as retrieving locally saved consent data, please see:


For iOS, the MobileConsentsSDK is available through CocoaPods.

To install the SDK, add the following line to your Podfile:

pod 'MobileConsentsSDK'

Once that's done, run the command:

pod install

For instructions on how to initialise the SDK, retrieve a Consent Solution, sending consent to a server, and retrieving locally saved consents data, please see:

Your server is one of the last steps in the process, and only used for ensuring authentication before the authorised consent request is sent to us.

Your server will receive the Consent Request from your mobile application in the format of JSON.

Because it must be ensured that a consent is legitimate when querying our API (so no one is able to pretend that it came from your application) the request can't be sent directly from your mobile application.

In order to achieve (and allow) secure authentication, Consent Requests are communicated server-to-server.

The server's role is to work as a proxy between your mobile application and the Cookie Information Consent API.

In most cases there won't be any need to specifically set up a new server for the purpose of implementing Mobile App Consent - as you can always use the existing backend that your mobile application already possesses.

However, there are a few general requirements:

  • Your server must allow secure authentication
  • Your server must be http and able to talk to an endpoint
  • Your server must support oauth

How you would like to place and format your Consent Items is entirely up to you - you have free reign. By default, we do not add any styling or formatting (though they could be tickboxes, checkboxes, or toggles) because we're only providing the data.

However, it could look something like below:

Currently at this time, there isn't any automation around updating consent from a user as we do not have information on how particular Consent Items relate to specific parts of your application.

For this reason, data saved in local storage will be able to show you which consent items a user agreed to (or didn't). You can use this to then allow or restrict certain features of your application that require these consents.

Checklist for Mobile App Consent Implementation

  1. Create a Consent Solution in the platform and add at least one Consent Item
  2. Create an endpoint on your server that will accept Consent Requests, authorise them with Cookie Information and pass the Request
  3. Install the SDK in your application
  4. Using the SDK, download the Consent Solution data and display the agreements in your application
  5. Using the SDK, gather agreements from users and send them to the endpoint on your server
  6. Your server should pass on the Consent Request to Cookie Information to be saved

Limitations of the current Mobile App Consent Implementation

At this stage, Mobile App Consents are a more manual process, both in terms of general setup, as well as what's needed in order to be able to respect user choices.

Scans are not performed on Mobile App Consent Solutions (like domains are scanned for regular solutions). There is also no form of dashboard or reporting functionality.

These are some of the things we would like to address in future versions of the Mobile App Consents feature.

Did this answer your question?