A Native iOS SDK does not exist for Unity Analytics, however the Unity Analytics REST API can be used to send Analytics events from your native game client to Unity Analytics. This will require you implement your own REST API wrapper in your game client, taking into account offline caching, back-off & retry and session management etc..

The Unity Gaming Services Remote Config and Game Overrides service can be used to replicate much of the functionality of deltaDNA Engage. REST API calls can be made to Remote Config to retrieve remote JSON configuration for predefined keys, based on audience targeting or runtime parameters.

Alternatively, the source code for the existing deltaDNA iOS SDK is publically available on the deltaDNA GitHub repository if you would prefer to download or fork, modify and maintain it yourself. It can be patched to send event data to Unity Analytics instead of the deltaDNA endpoint and to use Game Overrides to replicate some decision point campaigns.

Regardless of whether you intend to implement UGS Services or modify the deltaDNA SDK to work with them, you will need to follow the DELTADNA TO UNITY DASHBOARD MAPPING FLOW before 3rd March 2024 and pay attention to the player’s userID, to ensure you have a contiguous data record for each player that migrates from deltaDNA to Unity Analytics.

Analytics REST API Migration

The native iOS SDK can be replaced with the Unity Analytics REST API, but there are a few things you will need to take into consideration when implementing this approach:

  • Privacy : You will need to implement player consent and data privacy checks to comply with the store and territory legislation relevant for your game.
  • userID consistency : To ensure a contiguous data record for the player as they move to Unity Analytics, you will need to use the same userID that the native iOS SDK previously used. You can retrieve the userID from the SDK by reading the userID property from it
  • Session management : The deltaDNA iOS SDK generates a new sessionID parameter that it uses on each event for the duration of the current gameplay session. A new sessionID is generated on each App launch or when it returns from being backgrounded for more than 5 minutes. The sessionID is just a string that is unique to that user session, you will need to generate this yourself.
  • eventUUID : Each event can contain an optional eventUUID parameter, if this parameter is present the Unity Analytics ingestion pipeline will use it to de-duplicate events. It is just a string that is unique to this user event. It is particularly important if you are using event caching and retries.
  • eventTimestamp : Each event should contain an eventTimestamp parameter representing the UTC timestamp when the player performed a particular action. If this is omitted a timestamp will be applied on the server when the event is received, causing batched or cached events to look incorrect in the dataset.
  • Offline event caching : The Unity Analytics REST API will respond with a 204 status code if your event POST is received successfully. If you don’t get this response you should consider caching the event(s) and retrying later when connectivity is restored. Be sure to use the eventUUID to avoid duplicate events from retries on bad connections.
  • Back off and retry and Timeouts : If you implement event caching you should also implement your own backoff and retry mechanism.
  • Standard event and parameter consistency : The iOS SDK sends several standard events that are used to populate the Analytics dashboards, you will be required to record these, populating all the relevant parameters correctly, yourself. You can view the event definitions in the Event Manager tool in the deltaDNA dashboard, or in the same tool in the Unity Dashboard after successfully mapping your deltaDNA game to Unity Analytics. Take a look at the iOS SDK source code to see how each of the parameter values is populated, searching the repository for the specific event name or parameter name will help you find them.

Additional documentation

We recommend using a network proxy tool like Fiddler or Charles to check event posts during development and the Event Browser dashboard tool to check that they are passing event validation.

Remote Config and Game Override Migration

deltaDNA Engage Decision Point campaigns can be replicated to a large extent using UGS Remote Config and Game Overrides

  • deltaDNA Decision Point campaigns make a request at time of your choosing and respond with a JSON payload containing parameter keys and values. The content response can be targeted to individual players based on Analytics segmentation and values sent in the request at runtime.
  • UGS Remote Config makes a request at game launch by default, but can be refreshed later at a time of your choosing. It retrieves all predefined keys and values for the game
  • UGS Game Overrides change the response of a Remote Config requestt at game launch by default, but can be refreshed later at a time of your choosing. It retrieves all predefined keys including any that have been modified based on Analytics Audience or JEXL runtime parameter evaluation criteria.

There are some differences that should be noted though.

deltaDNA Decision Point Campaigns

Remote Config / Game Overrides

Analytics Audience Segmentation AND Runtime request parameters can be used to target the response to the player EITHER Analytics Audience OR Runtime Request parameters can be used to target the response to the player.

This may be a sufficient difference to prevent the migration of some DDNA decision point campaign without reworking their player selection criteria.
Only the parameter keys and values for a specific decision point are returned with each request. All parameter keys and values for the game are returned with each request.
Decision Point requests are made whenever you make them in your game client. It is not uncommon for a game to make multiple decision point requests at different points in the game.  Remote Config requests are typically only made when the game is launched, but they can be made at other points in the game if you explicitly make them.

Decision Point campaign endpoint, parameters and response format are different to Remote Config

It should also be noted that Event Triggered Campaigns and Image Message Popups rely on significant client side code and JSON response payloads, it would be a major undertaking to try and replicate their functionality with UGS.

deltaDNA Engage Decision Point Request and Response example.

Request Endpoint
https://engage16056nwdmf.deltadna.net Request Body

Response Body


UGS Remote Config / Game Override Request and Response example.

Request Endpoint
https://config.unity3d.com/api/v1/settings Request Body

Response Body

deltaDNA SDK Modification

The existing deltaDNA iOS SDK is simply a wrapper for the deltaDNA Analytics and Engage REST APIs.

The specifications for the deltaDNA and Unity Analytics REST APIs are very similar. The format of the JSON analytics events is identical, it is just the REST API endpoint that differs. There are bigger differences between the deltaDNA decision point campaign and UGS Remote Config APIs, but they are functionally close enough that it is possible to replicate a lot of deltaDNA decision point campaign functionality with UGS Remote Config and Game Overrides.

The following details show how to modify deltaDNA SDK v5.0.2 for IOS to make it send events to the Unity Analytics REST API endpoint instead of deltaDNA, and how to make Engage decision point like requests to Remote Config. These modifications may save you the effort of implementing your own REST API wrappers from scratch.

A version of iOS SDK v5.0.2 that has already been modified can also be downloaded from here

ios-sdk-5.0.2 – Modified for UGS Analytics and Remote Config.zip

SDK Integration & Modifications

The deltaDNA iOS SDK can be downloaded from the deltaDNA repository on GitHub, you will find source code and Framework files there. There have been numerous versions of the SDK over the years and a few different ways of integrating it (source files, XC Framework, CocoaPods..). This guide has been written using v5.0.2 of the deltaDNA iOS SDK, there may be some differences with earlier versions, but the theory is the same. In order to patch the SDK you are going to need to modify a few source files, so you may need to re-install the SDK using the Source Files method.

  1. Download and unzip the iOS SDK Source code.zip from the repository releases page
  2. Drag the DeltaDNA.xcodeproj file in to your Xcode project
  3. Select the build target on your main project and add the DeltaDNA.framework to it.
  4. You should now be able to see the deltaDNA source files inside the DeltaDNA folder in your Xcode project structure. Validate that you can build and run your project.
  5. There are two methods for starting the deltaDNA SDK, they must be changed to accept the URL endpoint and environment values expected by the Unity Analytics and Remote Config SDKs. Open the DeltaDNA/DDNASDK.h file and add two new property declarations (around Ln 104 in SDK v5.0.2)
  6. Now update the two Start method declarations to accept the new parameters (around Ln 137 in SDKv5.0.2)
  7. Open the DeltaDNA/DDNASDK.m file and add the two new properties to it (around Ln 37 in SDK v5.0.2)
  8. Then modify the two start methods to the following (around Ln 75 in SDK v5.0.2). We will call these new methods to start the SDK. The Unity Analytics and Remote Config APIs use slightly different URL parameters than the deltaDNA one did.
  9. Open the DeltaDNA/Extensions/NSURL+DeltaDNA.h file and modify the two Collect method definitions to accept the new parameters.
  10. Open the DeltaDNA/Extensions/NSUrl+DeltaDNA.m and modify the URLWithCollectEndpoint methods to the following (around line 40 in SDK v5.0.2)
    This removes the payload hashing and bulk endpoint that aren’t supported on Unity Analytics REST API. Don’t worry though, the endpoint we will use does accept posts containing multi-event arrays.

    It also modifies the URL builder to add the environment name to the end.
    You can remove the NSLog line when you are satisfied that the SDK modification is performing as expected.

  11. Also comment out the HashComponent portion of the URLWithEngageEndpoint method as follows and modify the url builder. (around Line 27 in SDK v5.0.2)


  12. The Collect Analytics Service interface needs to be updated to use the new projectId and environmentName values. Open the DeltaDNA\Impl\Collect\DDNACollectService.h file and update the initWithEnvironmentKey method to initWithEnvironmentName(around Line 44 in SDK v5.0.2)


  13. The DeltaDNA\Impl\Collect\DDNACollectService.m file also needs to be modified to accommodate the change to the Interface. (around Line 97 in SDK v5.0.2)


  14. The initWithEnvironmentName method also needs to be updated (around Line 108 in SDK v5.0.2)


  15. The way the url parameter is built also needs to be updated (around Line 131 in SDK v5.0.2)


  16. The EngageService also needs to be updated. The projectId parameter needs to be added to the initWithEnvironmentKey method definition in DeltaDNA\Impl\Engage\DDNAEngageService.h (around Line 43 in SDK v5.0.2)


  17. There are a few changes to make to the DeltaDNA\Impl\Engage\DDNAEngageService.m file too. Add the projectId property (around Line 83 in SDK 5.02)


  18. Modify the initWithEnvironmentKey method, adding the projectId as an input parameter and applying it to the EngageService.(around Line 102 in SDK 5.02)


  19. The parameters sent in the Remote Config request are slightly different to those expected by the deltaDNA Engage service, so change the request Dictionary (around Line 144 in SDK v5.0.2)

    A couple of changes need to be made to the requestGameParametersForDecisionPoint method. A decisionPoint parameter will be passed in the parameter payload so it can be used by JEXL targeting to trigger the decision point configuration. Modify the DeltaDNA\Engage\DDNAEngageFactory.m file replace the request method with the one below (around Line 46 in SDK v5.0.2)


  20. Two changes need to be made to the DeltaDNA\Impl\Helpers\DDNAInstanceFactory.m file. The engageService initialization needs to have the projectId added to it (around Line 52 in SDK v5.0.2)


  21. And the collectService initialization needs to be updated to match the new method definition (around Line 74 in SDK v5.0.2)


  22. There are a couple of housekeeping modifications to finish off with. Open the DeltaDNA/Impl/Helpers/DDNASettings.m file and modify the DDNA_SDK_VERSION constant to make it obvious in your Analytics data that events are originating from the modified iOS SDK


  23. To prevent the SDK reaching out to Engage to retrieve event and campaign info on launch, you can comment out or remove the contents of the requestSessionConfiguration method in the DeltaDNA/Impl/DDNATrackingSdk.m file. Replace the contents of it with the following to ensure that the automated gameStarted and clientDevice events continue to be sent on launch.


  24. Now find the code in your game that you use to Start the deltaDNA SDK and replace it with the new startWithProjectId method.You will need to provide your projectID and Environment Name, the ones below belong to an internal Unity Demo Game. Check the REST API Migration Guide for more information on the URL formatting and where to find your projectId

    That’s it, your deltaDNA SDK should now be sending events directly to Unity Analytics. And using Remote Config to fulfill Engage Decision Point Requests


Use a network proxy like Charles or Fiddler to check that your analytics events are sending as expected and that you are getting a 204 response indicating that they have been received.

You should also check the Unity Analytics > Event Browser tool to confirm that they are arriving and validating correctly.

deltaDNA Engage Decision Point Campaigns can be tested with the deltaDNA > Setup > Engage Trace Tool. It lets you see the Engage request and response for a given decision point campaign.

A network traffic proxy like Charles or Fiddler should be used to check the requests and responses from UGS Remote Config / Game Overrides.

Game Override campaign setup.

The sdk modifications above rely on the decisionPoint campaign name (decisionPoint) being sent to the Remote Config API as a user parameter that can then be evaluated at runtime as JEXL audience targeting criteria.

This does impose a limitation, that Analytics audience selection criteria cannot be used at the same time. But additional parameters can be put into the JEXL targeting criteria to mitigate this.